rfc713.txt

RFC 的详细文档！

items.

In all cases, a data object begins with a single byte,
which will be termed the TYPE-BYTE, a field of which
contains the type code of the object.  The following bytes,
if any, are interpreted according to the type involved.


VI.1 -- Presentation Conventations


In discussing formats of bytes, the following
conventions will be employed.  The individual bits of a byte
will be referenced by using capital letters from A to H,
where A signifies the highest order bit, and H the lowest.
The entire eight bit value, for example, could be referred
to as ABCDEFGH.  Similarly, subfields of the byte will be
identified by such sequences.  The CDEF field specifies the
middle four bits of a byte.

In referring to values of fields, binary format will be
used, and small letters near the end of the alphabet will be
used to identify particular bits for discussion.  For
example, we might say that the BCD field of a byte contains
a specifier for some type, and define its value to be
BCD=11z.  In discussions of the specifier usage, we could
refer to the cases where z=l and where z=0, as shorthand
notation to identify BCD=111 and BCD=110, respectively.


V1.2 -- Type-Byte Bit Assignment


To assist in understanding the assignment of the
various type-byte values, the table and graph below are
included, showing representations of the eight bits.




                               -8-

OXXXXXXX -- CHAR7 (CHARacter, 7 bit)
10XXXXXX -- SINTEGER (Small INTEGER)
l10XXXXX -- NON-ATOM (NON-ATOMic objects)
11100XXX -- LINTEGER (Large INTEGER)
11101XXX -- reserved
11110XXX -- SBITSTR (Short BIT STReam)
111110XX -- XTRA (eXTRA single-byte objects)
1111110X -- BOOL (BOOLean)
11111110 -- EMPTY (EMPTY data item)
11111111 -- PADDING (unused byte)


In each case, the bits identified by X's are used to
contain information specific to the type involved.  These
are explained when each type is defined.

An equivalent tree representation follows, for those
who prefer it.
start with high order bit
 |
 |
 |
 0-----0-----0-----0-----0-----0-----0-----0-----X
 |     |     |     |     |     |     |     |   PADDING
0|    0|    0|    0|    0|    0|    0|    0|
 |     |     |     |     |     |     |     |
 X     |     X     |     X     |     X     X
CHAR7  | NON-ATOM  |    BITS   |   BOOL   EMPTY
 (7)   |   (5)     |    (3)    |   (1)
       |        0| |           |
   SINTEGER        |          XTRA
      (6)          |           (2)
               LINTEGER
                  (3)

        Type-Byte Bit Assignment Scheme




This picture is interpreted by entering at the top, and
taking the appropriate branch at each node to correspond to
the next bit of the type-byte, as it is scanned from left to
right.  When a type is assigned, the branch terminates with
an "X' and the name of the type of the object, with the
number of remaining bits in parentheses.  The individual
object definitions specify how these bits are used for that
particular type.


V1.3 -- Atomic Objects


Atomic objects are identified by specific patterns in a
type-byte.  Receiving servers must be capable of recognizing


                               -9-

and handling all atomic types, since the size of the object
is not explicitly present in a uniform fashion.


================================
| Atomic Object: B-CHAR7       |
================================


The b-CHAR7 (CHARacter 7 bit) object is introduced to
handle transmission of characters, in 7-bit ASCII format.
Since the vast majority of message-related data involves
such objects, they are designed to be very efficient in
transmission.  Other formats, such as eight bit values, can
be introduced as non-atomic objects.  The format of a b-CHAR7
follows:

A=0 identifying the b-CHAR7 data type
BCDEFGH=tuvwxyz containing the character
code

The tuvwxyz objects contain the ASCII code of the
character.  For example, transmission of a "space' (ASCII
code 32, 40 octal) would be accomplished by the following
byte.

00100000
ABCDEFGH

A=0 to identify this byte as a b-CHAR7.  The remaining
bits contain the 7 bit code, octal 40, for space.

A b-CHAR7 standing alone is presented as a p-CHAR.
Such occurrences will probably be rare if they are used at
all.  The most common use of b-CHAR7's is as elements of
b-USTRUCs used to transmit p-STRINGS, as explained later.


=============================
| Atomic Object: B-SINTEGER |
=============================

The b-SINTEGER (Small INTEGER) object is used to
transmit very small positive integers, of values up to 64.
It always translates to an p-INT, and any p-INT between 0
and 63 may be encoded as a b-SINTEGER for transmission.  The
format of an b-SINTEGER follows.

AB=10 identifying the object as a b-SINTEGER
CDEFGH=uvwxyz containing the actual number

For example, to transmit the integer 10 (12 octal), the
following byte would be transmitted:

10001010
ABCDEFGH

                               -10-

AB=10 to specify a b-SINTEGER.  The remaining six bits
contain the number 10 expressed in binary.

=============================
| Atomic Object: B-SINTEGER |
=============================

The b-SINTEGER (Large INTEGER) object is used to
transmit p-INTs to any precision up to 64 bits.  It is
always translated as a p-INT.  Sending servers are permitted
to choose either b-SINTEGER or b-SINTEGER format for
transmission of numbers, as appropriate.  When possible,
b-SINTEGERs can be used for better channel efficiency.  The
format of a b-SINTEGER follows:

ABCDE=11100 specifying that this is a b-SINTEGER.
FGH=xyz containing a count of number of bytes to follow.

The xyz bits are interpreted as a number of bytes to
follow which contain the actual binary code of the the
integer in 2's complement format.  Since a zero-byte integer
is disallowed, the pattern xyz=000 is interpreted as 1000,
specifying that 8 bytes follow.  The number is transmitted
with high-order bits first.  This format permits
transmission of integers as large as 64 bits in magnitude.

For example, if the number 4096 (10000 octal) is to be
transmitted, the following sequence of bytes would be sent:

11100010 00010000 00000000
ABCDEFGH ---actual data---

ABCDE=11100, identifying this as a b-LINTEGER, E=0,
specifying a positive number, and FGH=010, specifying that 2
bytes follow, containing the actual binary number.

============================
| Atomic Object: B-SBITSTR |
============================

The b-SBITSTR (Short BIT STReam) object is used to
transmit a p-BITS of length 63 or less.  For longer bit
streams, the non-atomic object b-LBITSTR may be used.  The
format of a b-SBITSTR follows.

ABCDE=11110 specifying the type as b-SBITSTR
FGH=xyz specifying the number of bytes
following.







                               -11-
The xyz value specifies the number of additional bytes
to be read to obtain the bit stream values.  As in the case
of b-SINTEGER, the value xyz=000 is interpreted as 1000,
specifying that 8 bytes follow.

To avoid requiring specification of exactly the number
of bits contained, the following convention is used.  The
first data byte is scanned from left to right until the
first 1 bit is encountered.  The bit stream is defined to
begin with the immediately following bit, and run through
the last bit of the last byte read.  In other words, the bit
stream is 'right-adjusted' in the collected bytes, with its
left end delimited by the first "on' bit.

For example, to send the bit stream *001010011* (9
bits), the following bytes are transmitted.

11110010 00000010 01010011
ABCDEhij klmnopqr stuvwxyz

The hij=010 value specifies that two bytes follow.  The
q bit, which is the first 1 bit encountered, identifies the
start of the bit stream as being the r bit.  The rstuvwxyz
bits are the bit stream being handled.

=========================
| Atomic Object: b-BOOL |
=========================

The b-BOOL (BOOLean) object is used to transmit
p-BOOLs.  The format of b-BOOL objects follows.

ABCDEFG=1111110 specifying the type as
b-BOOL
H=z specifying the value

The two possible translations of a b-BOOL are *FALSE*
and *TRUE*.

11111100 represents *FALSE*
11111101 represents *TRUE*
ABCDEFGz

if z=0, the value is FALSE, otherwise TRUE.



========================================
| Atomic Object: B-EMPTY |
========================================

The b-EMPTY object type is used to transmit a 'null'
object, i.e. an *EMPTY*.  The format of an b-EMPTY follows.

ABCDEFGH=11111110 specifying *EMPTY*

                                -12-
=========================
| Atomic Object: B-XTRA |
=========================

The b-XTRA objects are used to carry the four possible
p-XTRA items, i.e., *XTRA0*, *XTRA1*, *XTRA2*, and *XTRA3*.
These four items correspond to the binary coding of the
remaining two bits after the b-XTRA type code bits.  The
format of a b-XTRA follows.

ABCDEF=111110 to specify the type b-XTRA
GH=yz to identify the particular p-XTRA item
carried

The GH bits of the byte are decoded to produce a
particular p-XTRA item, as follows.

GH=00 -- *XTRA0*
GH=01 -- *XTRA1*
GH=10 -- *XTRA2*
GH=11 -- *XTRA3*

The b-XTRA object is included to provide the use of
several single-byte data items to higher levels.  These
items may be assigned by individual applications to improve
the efficiency of transmission of several very frequent data
items.  For example, the message services protocols will use
these items to convey positive and negative acknowledgments,
two very common items in every interaction.

========================================
| Atomic Object: B-PADDING
========================================

This object is anomalous, since it represents really no
data at all.  Whenever it is encountered in a byte stream in
a position where a type-byte is expected, it is completely
ignored, and the succeeding byte examined instead.  Its
purpose is to serve as a filler in byte streams, providing
servers with an aid in handling internal problems related to
their specific word lengths, etc.  The encoders may freely
use this object to serve as padding when necessary.

All b-PADDING data objects exist only within an encoded
byte stream.  They never cause any data item whatsoever to
be presented externally to the coder module.  The format of a
b-PADDING follows.

ABCDEFGH=11111111

Note that this does not imply that all such 'null'
bytes in a stream are to be ignored, since they could be
encountered as a byte within some other type, such as
b-LINTEGER.  Only bytes of this format which, by their
position in the stream, appear as a 'type' byte are to be
ignored.

                                -13-
VI.4 -- Non-Atomic Objects


Non-atomic objects are are always transmitted preceded
by both a single type byte and some small number of size
byte(s).  The type byte identifies that the data object
concerned is of a non-atomic type, as well as uniquely
specifying the particular type involved.  All non-atomic
objects have type byte values of the following form.

ABC=110 specifying that the object is
non-atomic
DEFGH=vwxyz specifying the particular type
of object

The vwxyz value is used to specify one of 31 possible
non-atomic types.  The value vwxyz=00000 is reserved for use
in future expansion.

In all non-atomic data objects, the byte(s) following
the type-byte specify the number of bytes to follow which
contain the data object.  In all cases, if the number of
bytes specified are processed, the next byte to be seen
should be another type-byte, the beginning of the next
object in the stream.

The number of bytes containing the object size
information is variable.  These bytes will be termed the
SIZE-BYTES.  The first byte encountered has the following
format.

A=s specifying the manner in which the size
information is encoded
BCDEFGH=tuvwxyz specifying the size, or
number of bytes containing the size

The tuvwxyz values supply a positive binary number.  If
the s value is a one, the tuvwxyz value specifies the number
of bytes to follow which should be read and concatenated as
a binary number, which will then specify the size of the
object.  These bytes will appear with high order bits first.
Thus, if s=1, up to 128 bytes may follow, containing the
count of the succeeding data bytes, which should certainly
be sufficient.

Since many non-atomic objects will be fairly short, the
s=0 condition is used to indicate that the 7 bits contained
in tuvwxyz specify the actual data byte count.  This permits

objects of sizes up to 128 bytes to be specified using one
size-information byte.  The case tuvwxyz=0000000 is
interpreted as specifying 128 bytes.

For example, a data object of some non-atomic type
which requires 100 (144 octal) bytes to be transmitted would
be sent as follows.

                                -14-

110XXXXX -- identifying a specific
non-atomic object
01100100 -- specifying that 100 bytes follow
.
.
data -- the 100 data bytes
.
.

Note that the size count does not include the
size-specifier byte(s) themselves, but does include all
succeeding bytes in the stream used to encode the object.

A data object requiring 20000 (47040 octal) bytes would
appear in the stream as follows.

110XXXXX -- identifying a specific
non-atomic object
10000010 -- specifying that the next 2 bytes
contain the stream length
01001110 -- first byte of number 20000
00100000 -- second byte
.
.
data -- 20,000 bytes
.
.

Interpretation of the contents of the 20000 bytes in
the stream can be performed by a module which knows the
specific format of the non-atomic type specified by DEFGH in
the type-byte.

The remainder of this section defines an initial set of
non-atomic types, the format of their encoding, and the
semantics of their interpretation.