rfc713.txt

RFC 的详细文档！

================================
| Non-atomic Object: B-LBITSTR |
================================

The b-LBITSTR (Long BIT Stream) data type is introduced
to transmit p-BITS which cannot be handled by a b-SBITSTR.
A b-LBITSTR may be used to transmit short p-BITS as well.
Its format follows.










                                -15-

11000001 size-bytes data-bytes
ABCDEFGH

ABC=110 identifies this as a non-atomic object.
DEFGH=00001 specifies that it is a b-LBITSTR.  The standard
sizing information specifies the number of succeeding bytes.
Within the data-bytes, the first object encountered must
decode to a p-INT.  This number conveys the length of the
bit stream to follow.  The actual bit stream begins with the
next byte, and is left-adjusted in the byte stream.  For
example to encode *101010101010*, the following b-LBITSTR
could be used, although a b-SBITSTR would be more compact.

11000001 -- identifies a b-LBITSTR
00000010 -- b-SINTEGER, to specify length
10001100 -- size = 2
10101010 -- first 8 data bits
10100000 -- last 4 data bits



==============================
| Non-atomic Object: B-STRUC |
==============================

The b-STRUC (STRUCture) data type is used to transmit
any p-STRUC.  The translation rules for converting a b-STRUC
into a primitive item are presented following the discussion
of b-REPEATs.  The b-STRUC format appears as follows.

11000010 size-bytes data-bytes
ABCDEFGH

ABC=110 identifies this as a non-atomic type.
DEFGH=00010 specifies that the object is a b-STRUC.  Within
the data-bytes stream, objects simply follow in order.  This
implies that the b-STRUC encoder and decoder modules can
simply make use of recursive calls to a standard
encoder/decoder for processing each element of the b-STRUC.

Note that any type of object is permitted as an element of a
b-STRUC, but the size information of the b-STRUC must
include all bytes used to represent the elements.

Containment of b-STRUCs within other b-STRUCs is
permitted to any reasonable level.  That is, a b-STRUC may
contain as an element another b-STRUC, which contains
another b-STRUC, and so on.  All servers are requires to
handle such containment to at least a minimum depth of
three.

Examples of encoded structures appear in a later
section.


                                -16-
============================
| Non-atomic Object: B-EDT |
============================

A b-EDT is the object used as the carrier for p-EDTs in
transmission of semantic items.  It is functionally
identical to a b-STRUC, but has a different type code to
permit it to be identified and converted to a semantic item
instead of a p-STRUC.  The format of a b-EDT follows.

11000011 size-bytes data-bytes
ABCDEFGH

As with all non-atomic types, ABC=110 to identify this
as such, and DEFGH=00011 to specify a b-EDT.  The objects in
the data-bytes are decoded as for b-STRUCs.  However, the
first object must decode to a p-iNT or p-STRING and the
second to a p-INT, to conform to the format of p-EDTs.



===============================
| Non-atomic Object: b-REPEAT |
===============================


The b-REPEAT object is never translated directly into
an item.  It is legal only as an component of an enclosing
b-STRUC, b-USTRUC, b-EDT, or b-REPEAT.  A b-REPEAT is used to
concisely specify a set of elements to be treated as if they
appeared in the enclosing structure in place of the
b-REPEAT.  This provides a mechanism for encoding a sequence
of identical data items or patterns efficiently for
transmission.

A common example of this would be in transmission of
text, where line images containing long sequences of spaces,
or pages containing multiple carriage-return, line-feed
pairs, are often encountered.  Such sequences could be
encoded as an appropriate b-REPEAT to compact the data for
transmission.  The format of a b-REPEAT is as follows.

11000100   -- identifyIng the object as a
                b-REPEAT
size-bytes -- the standard non-atomic object
                size information
countspec  -- an object which translates to a p-INT
.
.
data -- the objects which define the pattern
.
.

The 'countspec' object must translate to an p-INT to
specify the number of times that the following data pattern
should be repeated in the object enclosing the b-REPEAT.

                                -17-

The remaining objects in the b-REPEAT constitute the
data pattern which is to be repeated.  The decoding of the
enclosing structure will be continued as if the data pattern
objects appeared 'countspec' times in place of the b-REPEAT.
Zero repeat counts are permitted, for generality.  They
cause no objects to be simulated in the enclosing structure.

An encoder does not have to use b-REPEATs at all, if
simplicity of coding outweighs the benefits of data
compression.  In message services, for example, an encoder
might limIt itself to only compressing long text strings.  It
is important for compatibility, however, to have the ability
in the decoders to handle b-REPEATs.

===============================
| Non-atomic Object: B-USTRUC |
===============================

The b-USTRUC (Uniform Structure) object type is
provided to enable servers to convey the fact that a p-STRUC
being transferred contains items of only a single type.  The
most common example would involve a b-USTRUC which
translates to a p-STRUC of only p-CHARs, and hence may be
considered to be a p-STRING.  Servers may use this
information to assist them in decoding objects efficiently.
No server is required to generate b-USTRUCs.

The internal construction of a b-USTRUC is identical to
that of a b-STRUC, except for the type-byte.  The format of a
b-USTRUC follows.

11000101 size-bytes data-bytes
ABCDEFGH

ABC=110 to identify a non-atomic object.  DEFGH=00101
specifies the object as a b-USTRUC.

===============================
| Non-atomic Object: B-STRING |
===============================

The b-STRING object is included to permit explicit
specification of a structure as a p-STRING.  This
information will permit receiving servers to process the
incoming structure more efficiently.  A b-STRING is
formatted similarity to a b-USTRUC, except that its type-byte
identifies the object as a b-STRI/NG.  The normal sizing
information is followed by a stream of bytes which are
interpreted as b-CHAR7s, Ignoring the high-order bit.  The
format of a b-STRING follows.

11000110 size-bytes data-bytes
ABCDEFGH

ABC=110 to identify a non-atomic object.  DEFGH=00110
specifies the object as a b-STRING.

                                -18-

VI.5 -- Structure Translation Rules


A b-STRUC is translated into a p-STRUC.  This is
performed by translating each object of the b-STRUC Into its
corresponding item, and saving it for inclusion In the
p-STRUC being generated.  A b-USTRUC is handled similarly,
but the coding programs may utilize the information that the
resultant p-STRUC will contain items of uniform type.  The
preferred method of coding p-STRINGS is to use b-USTRUCs.

If all of the elements of the resultant p-STRUC are
p-CHARs, it is presented to the user of the decoder as a
p-STRING.  A p-STRING should be considered to be a synonym
for a p-STRUC containing only characters.  It need not
necessarily exist at particular sites which would present
p-STRUCs of p-CHARs to their application programs

The object b-REPEAT is handled in a special fashion
when encountered as an element.  When this occurs, the data
pattern of the b-REPEAT is translated into a sequence of
items, and that sequence is repeated in the next higher
level as many times as specified in the b-REPEAT.
Therefore, b-REPEATS are legal only as elements of a
surrounding b-STRUC, b-USTRUC, b-EDT, or b-REPEAT.

In encoding a p-STRUC or p-STRING for transmission, a
translator may use b-REPEATs as desired to effect data
compression, but their use is not mandatory.  Similarly,
b-STRINGS may be used, but are not mandatory.

A b-EDT is translated into a p-EDT to identify it as a
carrier for a semantic item.  Otherwise, it is treated
identically to a b-STRUC.


VI.6 -- Translation Summary


The following table summarizes the possible
translations between primitive items and objects.

p-INT    <--> b-LINTEGER, b-SINTEGER
p-STRING <--> b-STRING, b-STRUC, b-USTRUC
p-STRUC  <--> b-STRING, b-STRUC, b-USTRUC
p-BITS   <--> b=SBITSTR, b-LBITSTR
p-CHAR   <--> b-CHAR7
p-BOOL   <--> b-BOOL
p-EMPTY  <--> b=EMPTY
p-XTRA   <--> b-XTRA
p-EDT    <--> b-EDT (all semantic items)
-none-   <--> b-PADDING
-none-   <--> b-REPEAT (only within structure)

Note that all semantic items are represented as p-EDTs
which always exist as b-EDTs in byte-stream format.

                                -19-
V1.7 -- Structure Coding Examples


The following stream transmits a b-STRUC containing 3
b-SINTEGERs, with values 1, 2, and 3, representing a p-STRUC
containing three p-INTs, i.e. (1 2 3).

11000010 -- b-STRUC
00000011 -- size=3
10000001 -- b-SINTEGER=1
10000010 -- b-SINTEGER=2
10000011 -- b-SINTEGER=3

The next example represents a b-STRUC containing the
characters X and Y, followed by the b-LINTEGER 10,
representing a p-STRUC of 2 p-CHARs and a p-INT, i.e., ('X'
'Y' 10).  Note that the p-INT prevents considering this a
p-STRING.

11000010 -- b-STRUC
00000100 -- size=4
01011000 -- b-CHAR7 'X'
01011001 -- b-CHAR7 'Y'
11100001 -- b-LINTEGER
00001010 -- 10

Note that a better way to send this p-STRUC would be to
represent the integer as a b-SINTEGER, as shown below.

11000010 -- b-STRUC
00000011 -- size=3
01011000 -- b-CHAR7 'X'
01011001 -- b-CHAR7 'Y'
10001010 -- b-SINTEGER=10

The next example shows a b-STRUC of b-CHAR7s.  It is
the translation of the b-STRING "HELLO".

11000010 -- b-STRUC
00000101 -- size=5
01001000 -- b-CHAR7 'H'
01000101 -- b-CHAR7 'E'
01001100 -- b-CHAR7 'L'
01001100 -- b-CHAR7 'L'
01001111 -- b-CHAR7 'O'

This datum could also be transmitted as a b-STRING.
Note that the character bytes are not necessarily b-CHAR7s,
since the high-order bit is ignored.

11000110 -- b-STRING
00000101 -- size=5
01001000 -- 'H'
01000101 -- 'E'
01001100 -- 'L'
01001100 -- 'L'
01001111 -- 'O'

                                -20-
To encode a p-STRING containing 20 carriage-return
line-feed pairs, the following b-STRUC containing a b-REPEAT
could be used.

11000010 -- b-STRUC
00000101 -- size=5
11000100 -- b-REPEAT
00000011 -- size=3
10010100 -- count, b-SINTEGER=20
00001101 -- b-CHAR7, "CR'
00001010 -- b-CHAR7, 'IF'

To encode a p-STRUC of p-INTs, where the sequence
contains a sequence of thirty 0's preceded by a single 1,
the following b-STRUC could be used.

11000010 -- b-STRUC
00000110 -- size=6
10000001 -- b-SINTEGER=1
11000100 -- b-REPEAT
00000010 -- size=2
10011110 -- count, b-SINTEGER=30
10000000 -- b-SINTEGER=0


VII. A GENERAL DATA TRANSFER SCHEME


This section considers a possible scheme for extending
the concept of a data translator into an multi-purpose data
transfer mechanism.

The proposed environment would provide a set of
primitive items, including those enumerated herein but
extended as necessary to accommodate a variety of
applications.  Communication between processes would be
defined solely in terms of these items, and would
specifically avoid any consideration of the actual formats
in which the data is transferred.

A repertoire of translators would be provided, one of
which is the MSDTP machinery, for use in converting items to
any of a number of transmission formats.  Borrowing a
concept from radio terminology, each translator would be
analogous to a different type of modulation scheme, to be
used to transfer data through some communications medium.
Such media could be an eight-bit byte-oriented connection,
36-bit connection, etc.  and conceivably have other
distinguishing features, such as bandwidth, cost, and delay.
For each media which a site supports, it would provide its
programmers with a module for performing the translations
required.




                                -21-

Certain media or translators might not handle various
items.  For example, the MSDTP does not handle items which
might be termed p-FLOATs, p-COMPLEXs, p-ARRAY, and so on.  In
addition, the efficiency of various media for transfer of
specific items may differ drastically.  MSDTP, for example,
transfers data frequently used in message handling very
efficiently, but is relatively poor at transfer of very
large or deep tree structures.

Available at each site as a process or subroutine
package wouLd be a module responsible for interfacing with
its counterpart at the other end of the media.  These
modules would use a protocol, not yet defined, to match
their capabilities, and choose a particular media and
translator, when more than one exists, for transfer of data
items.

Such a facility could totally insulate applications
from need to consider encoding formats, machine differences,
and so on, as well as eliminate duplication of effort in
producing such facilities for every new project which
requires them.  In addition, as new translators or media are
introduced, they would become immediately available to
existing users without reprogramming.

Implementation of such a protocol should not be very
difficult or time-consuming, since it need not be very
sophisticated in choosing the most appropriate transfer
mechanism in initial implementations.  The system is
inherently upward-compatible and easily expandable.























                                -22-