rfc713.txt

RFC 的详细文档！

Request for Comments: 713                           Jack Haverty  (JFH@MIT-DMS)
NIC #34739                                                             Apr 1976







I. ABSTRACT


A mechanism is defined for use by message servers in
transferring data between hosts.  The mechanism, called the
MSDTP, is defined in terms of a model of the process as a
translation between two sets of items, the abstract entities
such as 'strings' and 'integers', and the formats used to
represent such data as a byte stream.

A proposed organization of a general data transfer
mechanism is described, and the manner in which the MSDTP
would be used in that environment is presented.





































                                -1-

II. REFERENCES


Black, Edward H., "The DMS Message Composer", MIT Project
MAC, Programming Technology Division Document
SYS.16.02.

Burchfiel, Jerry D., Leavitt, Elsie M., Shapiro, Sonya and
Strollo, Theodore R., compilers, "Tenex Users' Guide",
Bolt Beranek and Newman, Cambridge, Mass., May 1971,
revised January 1975, Descriptive sections on the TENEX
subsystems: MAlLER, p. 116-11; MAlLSTAT, p. 118-119;
READMAIL, p. 137; and SNDMSG, p. 165-170.

Haverty, Jack, "Communications System Overview", MIT Project
MAC, Programming Technology Division Document
SYS.16.00.

Haverty, Jack, "Communications System Daemon Manual", MIT
Project MAC, Programming Technology Division Document
SYS.16.01.

ISI Information Automation Project, "Military Message
Processing System Design," Internal Project
Documentation (Out of Print), Jan. 1975

Message Services Committee, "Interim Report", Jan. 28, 1975

Mooers, Charlotte D., "Mailsys Message System: Manual For
Users", Bolt Beranek and Newman, Cambridge, Mass., June
1975 (draft).

Myer, Theodore H., "Notes On The BBN Mail System", Bolt
Beranek and Newman, November 8, 1974.

Myer, Theodore H., and Henderson, D. Austin, "Message
Transmission Protocol", Network Working Group RFC 680,
NIC 32116, April 30, 1975.

Postel, Jon, "The PCPB8 Format", NSW Proposal, June 5, 1975

Tugender, R., and D. R. Oestreicher, "Basic Functional
Capabilities for a Military Message Processing
Service," ISI?RR-74-23., May 1975

Vezza, Al, "Message Services Committee Minority Report",
Jan. 1975










                                   -2-

III. OVERVIEW


This document describes a mechanism developed for use
by message servers communicating over an eight-bit
byte-oriented network connection to move data structures and
associated data-typing information.  It is presented here in
the hope that it may be of use to other projects which need
to transfer data structures between dissimilar hosts.

A set of abstract entities called PRIMITIVE ITEMS is
enumerated.  These are intended to include traditional data
types of general utility, such as integers, strings, and
arrays.

A mechanism is defined for augmenting the set of
abstract data entities handled, to allow the introduction of
application-specific data, whose format and semantics are
understood by the application programs involved, but which
can be transmitted using common coding facilities.  An
example might be a data structure called a 'file
specification', or a 'date'.  Abstract data entities defined
using this mechanism will be termed SEMANTIC ITEMS, since
they are typically used to carry data having semantic
content in the application involved.

Semantic and primitive items are collectively referred
to simply as ITEMS.

The protocol next involves the definition of the format
of the byte stream used to convey items from machine to
machine.  These encodings are described in terms of OBJECTS,
which are the physical byte streams transmitted.

To complete the protocol, the rules for translating
between objects and items are presented as each object is
defined.

An item is transmitted by being translated into an
object which is transmitted over the connection as a stream
of bytes to the receiver, and reconstructed there as an
item.  The protocol mechanism may thus be viewed as a simple
translator.  It enumerates a set of abstract entities, the
items, which are known to programmers, a set of entities in
byte-stream format, the objects, and the translation rules
for conversion between the sets.  A site implementing the
MSDTP would typically provide a facility to convert between
objects and the local representation of the various items
handled.  Applications using the MSDTP define their
interactions using items, without regard to the actual
formats in which such items are represented at various
machines.  This permits programs to handle higher-level
concepts such as a character string, without concern for its
numerous representational formats.  Such detail is handled
by the MSDTP.

                                -3-


Finally, a discussion of a general data transfer
mechanism for communication between programs is presented,
and the manner in which the particular byte-oriented
protocol defined herein would be used in that environment is
discussed.

Terminology, as introduced, is defined and highlighted
by capitalizing.


IV. PRIMITIVE DATA ITEMS

The primitive data items include a variety of
traditional, well-understood types, such as integers and
strings.  Primitive data items will be presented using
mnemonic names preceded by the character pair "p-", to serve
as a reminder that the named object is primitive.

These items may be represented in various computer
systems in whatever fashion their programmers desire.


IV.1 -- Set Of Primitive Items


The set of primitive items defined includes p-INT,
p-STRING, p-STRUC, p-BITS, p-CHAR, p-BOOL, p-EMPTY, and
p-XTRA.

Since the protocol was developed primarily for use in
message services, items such as p-FLOAT are not included
since they were unnecessary.  Additional items may be easily
added as necessary.

A p-INT performs the traditional role of representing
integer numbers.  A p-BITS (BIT Stream) item represents a
bit stream.  The two possible p-BOOL (BOOLean) items are
used to represent the logical values of *TRUE* and *FALSE*.
The single p-EMPTY item is used to, for example, indicate
that a given field of a message is empty.  It is provided to
act as a place-holder, representing 'no data', and appears
as *EMPTY*.

The p-STRUC (STRUCture) item is used to group together
a collection of items as a single value, maintaining the
ordering of the elements, such as a p-STRUC of p-INTs.

A p-CHAR is a single character.  The most common
occurrence of character data, however, will be as p-STRINGs.
A p-STRING should be considered to be a synonym for a
p-STRUC containing only p-CHARs.  This concept is important
for generality and consistency, especially when considering
definitions of permissible operations on structures, such as
extracting subsequences of elements, etc.

                                   -4-

Four p-XTRA items, which can be transmitted in a single
byte, are made available for higher level protocols to use
when a frequently used datum is handled which can be
represented just by its name.  An example would be an
acknowledgment between two servers.  Using p-XTRAs to
represent such data permits them to be handled in a single
byte.  There are four possible p-XTRA items, termed *XTRA0*,
*XTRA1*, *XTRA2*, and *XTRA3*.  These may be assigned
meanings by user protocols as desired.


IV.2 -- Printing Conventions


The following printing conventions are introduced to
facilitate discussion of the primitive items.

When a specific instance of a primitive data item is
presented, it will be shown in a traditional representation
for that kind of data.  For example, p-INTs are shown as
sequences of digits, e.g. 100, p-STRINGs, as sequences of
characters enclosed in double-quote characters, for example
"ABCDEF".

As shown above, the two possible p-BOOL items are shown
as *TRUE* or *FALSE*.  The object p-EMPTY appears as
*EMPTY*.  A bit stream, i.e. p-BITS, appears as a stream of
1s and 0s enclosed in asterisks, for example *100101001*.  A
p-CHAR will be presented as the character enclosed in single
quote characters, e.g., 'A'.

P-STRUCs are printed as the representations of their
elements, enclosed in parentheses, for example (1 2 3 4) or
("XYZ" "ABC" 1 2) or ((1 2 3) "A" "B"). Note that because
p-STRINGs are simply a class of p-STRUCs assigned a special
name and printing format for brevity and convenience, the
items "ABC" and ('A' 'B' 'C') are identical, and the latter
format should not be used.

To present a generic p-STRUC, as in specifying formats
of the contents of something, the items are presented as a
mnemonic name, optionally followed by a colon and the
permissible types of values for that datum.  When one of
several items may appear as the value for some component,
the permissible ones appear separated by vertical-bar
characters.  For example, p-INT|p-STRING represents a single
item, which may be either a p-INT or a p-STRING.

To represent a succession of items, the Kleene star
convention is used.  The specification p-INT[*] represents
any number of p-INTs.  Similarly, p-INT[3,5] represents from
3 to 5 p-INTs, while p-INT[*,5] specifies up to 5 and
p-iNT[5,*] specifies at least 5 p-INTs.



                                   -5-

For example, a p-STRUC which is used to carry names and
numbers might be specified as follows.

(name:p-STRING number:p-INT)

In discussing items in general, when a specific data
value is not intended, the name and types representation may
be used, e.g., offset:p-INT to discuss an 'offset' which has
a numeric value.


V. SEMANTIC ITEM MECHANISM


The semantic item mechanism provides a means for
program designers to use a variety of application-specific
data items.

This mechanism is implemented using a special tagged
structure to carry the data type information as well as the
actual components of the particular semantic item.  For
discussion purposes.  Such a special p-STRUC will be termed a
p-EDT (Extended Data Type).

When p-EDTs are transferred, their identity as a p-EDT
is maintained.  So that an applications program receives the
corresponding semantic item instead of a simple p-STRUC.  A
p-EDT is identical to a p-STRUC in all other respects.


V.1 -- Format of p-EDTs


A prototypical p-EDT follows.  It is printed as if it
were a normal p-STRUC.  Since p-EDTs are converted to
semantic items for presentation to the user, a p-EDT will
never be used except in this protocol definition.

(type:p-INT|p-STRING version:p-INT com1:any
com2:any ...)

The first element, the 'type' is generally a p-INT, and
is used to identify the particular type of semantic item.
Types are assigned numeric codes in a controlled fashion.
The type may alternatively be specified by a p-STRING, to
permit development of new data types for possible later
assignment of codes.  Each type has an equivalent p-STRING
name.  These may be used interchangeably as 'type' elements,
primarily to maintain upward compatibility.

The second element of a p-EDT is always an p-INT, the
'version', and specifies the exact format of the particular
datum.  A semantic item may undergo several revisions of its
internal structure.  Which would be evident through assigning
different versions to each revision.

                                   -6-

Successive components.  The 'com' elements, if any.
carry the actual data of the semantic item.  As each
semantic item is defined, conventions on permissible values
and interpretation of these components are presented.  Such
definitions may use any types of items to specify the format
of the semantic item.  Use of lower level concepts, such as
objects, in these definitions is prohibited.

Semantic items will be printed as the mnemonic for the
type involved, preceded by the character pair "s-", to
signify that the data item is handled by this mechanism.


V.2 -- Printing Conventions


A semantic item is represented as if it were a p-STRUC
containing only the components, if any, but preceded by the
semantic type name and a # character.  The version number is
assumed to be 1 if unspecified.  For later versions, the
version number is attached to the type name, as in, for
example, FILE-2 to represent version 2 of the FILE data
type.

For example, a semantic item called a 'file
specification' might be defined, containing two components,
a host number and pathname.  A specific instance of such an
item might appear as #FILE(69 "DIRECTORY.NAME-OF-FILE"),
while a generic s-FILE might be presented as the following.

#FILE(host:p-INT|p-STRING pathname:p-STRING)


the item, which may be either a p-INT or p-STRING, and
'pathname' is the second component, which must be a
p-STRING.  The full definition would present interpretation
rules for these components.


VI.  ENCODING OBJECTS


This section presents the set of objects which are used
to represent items as byte streams for inter-server
transmission.  Objects will be presented using mnemonic
type-names preceded by the character pair "b-", indicating
their existence only as byte streams.

All servers are required to be capable of decoding the
entire set of objects.  Servers are not required to transmit
certain objects which are available to improve channel
efficiency.




                               -7-

The encodings are designed to facilitate programming
and efficiency of the receiving decoder.  In all cases, the
type and length in bytes of objects is supplied as the first
information sent.  This characteristic is important for ease
of implementation.  The type information permits a decoder to
be constructed in a modular fashion.  The most important
advantage of including size information is that the receiver
always knows how many bytes it must read to discover what to
do next, and knows when each object terminates.  This
requirement avoids many potential problems with timing and
synchronization of processes.

Two varieties of objects are defined.  The first will
be called ATOMIC, and includes objects used to efficiently
encode the most common data.  The second variety is termed
NON-ATOMIC, and is used to encode larger or less common