As per Relevance of the word represent, we have this rfc below:
Request for Comments: 713 Jack Haverty (JFH@MIT-DMS
NIC #34739 Apr 1976
I.
A mechanism is defined for use by message servers
transferring data between hosts. The mechanism, called
MSDTP, is defined in terms of a model of the process as
translation between two sets of items, the abstract
such as 'strings' and 'integers', and the formats used
represent such data as a byte stream
A proposed organization of a general data
mechanism is described, and the manner in which the
would be used in that environment is presented
-1-
II.
Black, Edward H., "The DMS Message Composer", MIT
MAC, Programming Technology Division
SYS.16.02.
Burchfiel, Jerry D., Leavitt, Elsie M., Shapiro, Sonya
Strollo, Theodore R., compilers, "Tenex Users' Guide",
Bolt Beranek and Newman, Cambridge, Mass., May 1971,
revised January 1975, Descriptive sections on the
subsystems: MAlLER, p. 116-11; MAlLSTAT, p. 118-119;
READMAIL, p. 137; and SNDMSG, p. 165-170.
Haverty, Jack, "Communications System Overview", MIT
MAC, Programming Technology Division
SYS.16.00.
Haverty, Jack, "Communications System Daemon Manual",
Project MAC, Programming Technology Division
SYS.16.01.
ISI Information Automation Project, "Military
Processing System Design," Internal
Documentation (Out of Print), Jan. 1975
Message Services Committee, "Interim Report", Jan. 28, 1975
Mooers, Charlotte D., "Mailsys Message System: Manual
Users", Bolt Beranek and Newman, Cambridge, Mass.,
1975 (draft).
Myer, Theodore H., "Notes On The BBN Mail System",
Beranek and Newman, November 8, 1974.
Myer, Theodore H., and Henderson, D. Austin, "
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
Capabilities for a Military Message
Service," ISI?RR-74-23., May 1975
Vezza, Al, "Message Services Committee Minority Report",
Jan. 1975
-2-
III.
This document describes a mechanism developed for
by message servers communicating over an eight-
byte-oriented network connection to move data structures
associated data-typing information. It is presented here
the hope that it may be of use to other projects which
to transfer data structures between dissimilar hosts
A set of abstract entities called PRIMITIVE ITEMS
enumerated. These are intended to include traditional
types of general utility, such as integers, strings,
arrays
A mechanism is defined for augmenting the set
abstract data entities handled, to allow the introduction
application-specific data, whose format and semantics
understood by the application programs involved, but
can be transmitted using common coding facilities.
example might be a data structure called a '
specification', or a 'date'. Abstract data entities
using this mechanism will be termed SEMANTIC ITEMS,
they are typically used to carry data having
content in the application involved
Semantic and primitive items are collectively
to simply as ITEMS
The protocol next involves the definition of the
of the byte stream used to convey items from machine
machine. These encodings are described in terms of OBJECTS
which are the physical byte streams transmitted
To complete the protocol, the rules for
between objects and items are presented as each object
defined
An item is transmitted by being translated into
object which is transmitted over the connection as a
of bytes to the receiver, and reconstructed there as
item. The protocol mechanism may thus be viewed as a
translator. It enumerates a set of abstract entities,
items, which are known to programmers, a set of entities
byte-stream format, the objects, and the translation
for conversion between the sets. A site implementing
MSDTP would typically provide a facility to convert
objects and the local representation of the various
handled. Applications using the MSDTP define
interactions using items, without regard to the
formats in which such items are represented at
machines. This permits programs to handle higher-
concepts such as a character string, without concern for
numerous representational formats. Such detail is
by the MSDTP
-3-
Finally, a discussion of a general data
mechanism for communication between programs is presented
and the manner in which the particular byte-
protocol defined herein would be used in that environment
discussed
Terminology, as introduced, is defined and
by capitalizing
IV. PRIMITIVE DATA
The primitive data items include a variety
traditional, well-understood types, such as integers
strings. Primitive data items will be presented
mnemonic names preceded by the character pair "p-", to
as a reminder that the named object is primitive
These items may be represented in various
systems in whatever fashion their programmers desire
IV.1 -- Set Of Primitive
The set of primitive items defined includes p-INT
p-STRING, p-STRUC, p-BITS, p-CHAR, p-BOOL, p-EMPTY,
p-XTRA
Since the protocol was developed primarily for use
message services, items such as p-FLOAT are not
since they were unnecessary. Additional items may be
added as necessary
A p-INT performs the traditional role of
integer numbers. A p-BITS (BIT Stream) item represents
bit stream. The two possible p-BOOL (BOOLean) items
used to represent the logical values of *TRUE* and *FALSE*.
The single p-EMPTY item is used to, for example,
that a given field of a message is empty. It is provided
act as a place-holder, representing 'no data', and
as *EMPTY*.
The p-STRUC (STRUCture) item is used to group
a collection of items as a single value, maintaining
ordering of the elements, such as a p-STRUC of p-INTs
A p-CHAR is a single character. The most
occurrence of character data, however, will be as p-STRINGs
A p-STRING should be considered to be a synonym for
p-STRUC containing only p-CHARs. This concept is
for generality and consistency, especially when
definitions of permissible operations on structures, such
extracting subsequences of elements, etc
-4-
Four p-XTRA items, which can be transmitted in a
byte, are made available for higher level protocols to
when a frequently used datum is handled which can
represented just by its name. An example would be
acknowledgment between two servers. Using p-XTRAs
represent such data permits them to be handled in a
byte. There are four possible p-XTRA items, termed *XTRA0*,
*XTRA1*, *XTRA2*, and *XTRA3*. These may be
meanings by user protocols as desired
IV.2 -- Printing
The following printing conventions are introduced
facilitate discussion of the primitive items
When a specific instance of a primitive data item
presented, it will be shown in a traditional
for that kind of data. For example, p-INTs are shown
sequences of digits, e.g. 100, p-STRINGs, as sequences
characters enclosed in double-quote characters, for
"ABCDEF".
As shown above, the two possible p-BOOL items are
as *TRUE* or *FALSE*. The object p-EMPTY appears
*EMPTY*. A bit stream, i.e. p-BITS, appears as a stream
1s and 0s enclosed in asterisks, for example *100101001*.
p-CHAR will be presented as the character enclosed in
quote characters, e.g., 'A'.
P-STRUCs are printed as the representations of
elements, enclosed in parentheses, for example (1 2 3 4)
("XYZ" "ABC" 1 2) or ((1 2 3) "A" "B"). Note that
p-STRINGs are simply a class of p-STRUCs assigned a
name and printing format for brevity and convenience,
items "ABC" and ('A' 'B' 'C') are identical, and the
format should not be used
To present a generic p-STRUC, as in specifying
of the contents of something, the items are presented as
mnemonic name, optionally followed by a colon and
permissible types of values for that datum. When one
several items may appear as the value for some component
the permissible ones appear separated by vertical-
characters. For example, p-INT|p-STRING represents a
item, which may be either a p-INT or a p-STRING
To represent a succession of items, the Kleene
convention is used. The specification p-INT[*]
any number of p-INTs. Similarly, p-INT[3,5] represents
3 to 5 p-INTs, while p-INT[*,5] specifies up to 5
p-iNT[5,*] specifies at least 5 p-INTs
-5-
For example, a p-STRUC which is used to carry names
numbers might be specified as follows
(name:p-STRING number:p-INT
In discussing items in general, when a specific
value is not intended, the name and types representation
be used, e.g., offset:p-INT to discuss an 'offset' which
a numeric value
V. SEMANTIC ITEM
The semantic item mechanism provides a means
program designers to use a variety of application-
data items
This mechanism is implemented using a special
structure to carry the data type information as well as
actual components of the particular semantic item.
discussion purposes. Such a special p-STRUC will be termed
p-EDT (Extended Data Type).
When p-EDTs are transferred, their identity as a p-
is maintained. So that an applications program receives
corresponding semantic item instead of a simple p-STRUC.
p-EDT is identical to a p-STRUC in all other respects
V.1 -- Format of p-
A prototypical p-EDT follows. It is printed as if
were a normal p-STRUC. Since p-EDTs are converted
semantic items for presentation to the user, a p-EDT
never be used except in this protocol definition
(type:p-INT|p-STRING version:p-INT com1:
com2:any ...)
The first element, the 'type' is generally a p-INT,
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,
permit development of new data types for possible
assignment of codes. Each type has an equivalent p-
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,
'version', and specifies the exact format of the
datum. A semantic item may undergo several revisions of
internal structure. Which would be evident through
different versions to each revision
-6-
Successive components. The 'com' elements, if any
carry the actual data of the semantic item. As
semantic item is defined, conventions on permissible
and interpretation of these components are presented.
definitions may use any types of items to specify the
of the semantic item. Use of lower level concepts, such
objects, in these definitions is prohibited
Semantic items will be printed as the mnemonic for
type involved, preceded by the character pair "s-",
signify that the data item is handled by this mechanism
V.2 -- Printing
A semantic item is represented as if it were a p-
containing only the components, if any, but preceded by
semantic type name and a # character. The version number
assumed to be 1 if unspecified. For later versions,
version number is attached to the type name, as in,
example, FILE-2 to represent version 2 of the FILE
type
For example, a semantic item called a '
specification' might be defined, containing two components
a host number and pathname. A specific instance of such
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,
'pathname' is the second component, which must be
p-STRING. The full definition would present
rules for these components
VI. ENCODING
This section presents the set of objects which are
to represent items as byte streams for inter-
transmission. Objects will be presented using
type-names preceded by the character pair "b-",
their existence only as byte streams
All servers are required to be capable of decoding
entire set of objects. Servers are not required to
certain objects which are available to improve
efficiency
-7-
The encodings are designed to facilitate
and efficiency of the receiving decoder. In all cases,
type and length in bytes of objects is supplied as the
information sent. This characteristic is important for
of implementation. The type information permits a decoder
be constructed in a modular fashion. The most
advantage of including size information is that the
always knows how many bytes it must read to discover what
do next, and knows when each object terminates.
requirement avoids many potential problems with timing
synchronization of processes
Two varieties of objects are defined. The first
be called ATOMIC, and includes objects used to
encode the most common data. The second variety is
NON-ATOMIC, and is used to encode larger or less
items
In all cases, a data object begins with a single byte
which will be termed the TYPE-BYTE, a field of
contains the type code of the object. The following bytes
if any, are interpreted according to the type involved
VI.1 -- Presentation
In discussing formats of bytes, the
conventions will be employed. The individual bits of a
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
to as ABCDEFGH. Similarly, subfields of the byte will
identified by such sequences. The CDEF field specifies
middle four bits of a byte
In referring to values of fields, binary format will
used, and small letters near the end of the alphabet will
used to identify particular bits for discussion.
example, we might say that the BCD field of a byte
a specifier for some type, and define its value to
BCD=11z. In discussions of the specifier usage, we
refer to the cases where z=l and where z=0, as
notation to identify BCD=111 and BCD=110, respectively
V1.2 -- Type-Byte Bit
To assist in understanding the assignment of
various type-byte values, the table and graph below
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 --
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
contain information specific to the type involved.
are explained when each type is defined
An equivalent tree representation follows, for
who prefer it
start with high order
|
|
|
0-----0-----0-----0-----0-----0-----0-----0-----
| | | | | | | |
0| 0| 0| 0| 0| 0| 0| 0|
| | | | | | | |
X | X | X | X
CHAR7 | NON-ATOM | BITS | BOOL
(7) | (5) | (3) | (1)
| 0| | |
SINTEGER |
(6) | (2)
(3)
Type-Byte Bit Assignment
This picture is interpreted by entering at the top,
taking the appropriate branch at each node to correspond
the next bit of the type-byte, as it is scanned from left
right. When a type is assigned, the branch terminates
an "X' and the name of the type of the object, with
number of remaining bits in parentheses. The
object definitions specify how these bits are used for
particular type
V1.3 -- Atomic
Atomic objects are identified by specific patterns in
type-byte. Receiving servers must be capable of
-9-
and handling all atomic types, since the size of the
is not explicitly present in a uniform fashion
================================
| Atomic Object: B-CHAR7 |
================================
The b-CHAR7 (CHARacter 7 bit) object is introduced
handle transmission of characters, in 7-bit ASCII format
Since the vast majority of message-related data
such objects, they are designed to be very efficient
transmission. Other formats, such as eight bit values,
be introduced as non-atomic objects. The format of a b-CHAR
follows
A=0 identifying the b-CHAR7 data
BCDEFGH=tuvwxyz containing the
The tuvwxyz objects contain the ASCII code of
character. For example, transmission of a "space' (
code 32, 40 octal) would be accomplished by the
byte
00100000
A=0 to identify this byte as a b-CHAR7. The
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
all. The most common use of b-CHAR7's is as elements
b-USTRUCs used to transmit p-STRINGS, as explained later
=============================
| Atomic Object: B-SINTEGER |
=============================
The b-SINTEGER (Small INTEGER) object is used
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.
format of an b-SINTEGER follows
AB=10 identifying the object as a b-
CDEFGH=uvwxyz containing the actual
For example, to transmit the integer 10 (12 octal),
following byte would be transmitted
10001010
-10-
AB=10 to specify a b-SINTEGER. The remaining six
contain the number 10 expressed in binary
=============================
| Atomic Object: B-SINTEGER |
=============================
The b-SINTEGER (Large INTEGER) object is used
transmit p-INTs to any precision up to 64 bits. It
always translated as a p-INT. Sending servers are
to choose either b-SINTEGER or b-SINTEGER format
transmission of numbers, as appropriate. When possible
b-SINTEGERs can be used for better channel efficiency.
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
follow which contain the actual binary code of the
integer in 2's complement format. Since a zero-byte
is disallowed, the pattern xyz=000 is interpreted as 1000,
specifying that 8 bytes follow. The number is
with high-order bits first. This format
transmission of integers as large as 64 bits in magnitude
For example, if the number 4096 (10000 octal) is to
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
transmit a p-BITS of length 63 or less. For longer
streams, the non-atomic object b-LBITSTR may be used.
format of a b-SBITSTR follows
ABCDE=11110 specifying the type as b-
FGH=xyz specifying the number of
following
-11-
The xyz value specifies the number of additional
to be read to obtain the bit stream values. As in the
of b-SINTEGER, the value xyz=000 is interpreted as 1000,
specifying that 8 bytes follow
To avoid requiring specification of exactly the
of bits contained, the following convention is used.
first data byte is scanned from left to right until
first 1 bit is encountered. The bit stream is defined
begin with the immediately following bit, and run
the last bit of the last byte read. In other words, the
stream is 'right-adjusted' in the collected bytes, with
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
The hij=010 value specifies that two bytes follow.
q bit, which is the first 1 bit encountered, identifies
start of the bit stream as being the r bit. The
bits are the bit stream being handled
=========================
| Atomic Object: b-BOOL |
=========================
The b-BOOL (BOOLean) object is used to
p-BOOLs. The format of b-BOOL objects follows
ABCDEFG=1111110 specifying the type
b-
H=z specifying the
The two possible translations of a b-BOOL are *FALSE
and *TRUE*.
11111100 represents *FALSE
11111101 represents *TRUE
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
p-XTRA items, i.e., *XTRA0*, *XTRA1*, *XTRA2*, and *XTRA3*.
These four items correspond to the binary coding of
remaining two bits after the b-XTRA type code bits.
format of a b-XTRA follows
ABCDEF=111110 to specify the type b-
GH=yz to identify the particular p-XTRA
The GH bits of the byte are decoded to produce
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
several single-byte data items to higher levels.
items may be assigned by individual applications to
the efficiency of transmission of several very frequent
items. For example, the message services protocols will
these items to convey positive and negative acknowledgments
two very common items in every interaction
========================================
| Atomic Object: B-
========================================
This object is anomalous, since it represents really
data at all. Whenever it is encountered in a byte stream
a position where a type-byte is expected, it is
ignored, and the succeeding byte examined instead.
purpose is to serve as a filler in byte streams,
servers with an aid in handling internal problems related
their specific word lengths, etc. The encoders may
use this object to serve as padding when necessary
All b-PADDING data objects exist only within an
byte stream. They never cause any data item whatsoever
be presented externally to the coder module. The format of
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
encountered as a byte within some other type, such
b-LINTEGER. Only bytes of this format which, by
position in the stream, appear as a 'type' byte are to
ignored
-13-
VI.4 -- Non-Atomic
Non-atomic objects are are always transmitted
by both a single type byte and some small number of
byte(s). The type byte identifies that the data
concerned is of a non-atomic type, as well as
specifying the particular type involved. All non-
objects have type byte values of the following form
ABC=110 specifying that the object
non-
DEFGH=vwxyz specifying the particular
of
The vwxyz value is used to specify one of 31
non-atomic types. The value vwxyz=00000 is reserved for
in future expansion
In all non-atomic data objects, the byte(s)
the type-byte specify the number of bytes to follow
contain the data object. In all cases, if the number
bytes specified are processed, the next byte to be
should be another type-byte, the beginning of the
object in the stream
The number of bytes containing the object
information is variable. These bytes will be termed
SIZE-BYTES. The first byte encountered has the
format
A=s specifying the manner in which the
information is
BCDEFGH=tuvwxyz specifying the size,
number of bytes containing the
The tuvwxyz values supply a positive binary number.
the s value is a one, the tuvwxyz value specifies the
of bytes to follow which should be read and concatenated
a binary number, which will then specify the size of
object. These bytes will appear with high order bits first
Thus, if s=1, up to 128 bytes may follow, containing
count of the succeeding data bytes, which should
be sufficient
Since many non-atomic objects will be fairly short,
s=0 condition is used to indicate that the 7 bits
in tuvwxyz specify the actual data byte count. This
objects of sizes up to 128 bytes to be specified using
size-information byte. The case tuvwxyz=0000000
interpreted as specifying 128 bytes
For example, a data object of some non-atomic
which requires 100 (144 octal) bytes to be transmitted
be sent as follows
-14-
110XXXXX -- identifying a
non-atomic
01100100 -- specifying that 100 bytes
data -- the 100 data
Note that the size count does not include
size-specifier byte(s) themselves, but does include
succeeding bytes in the stream used to encode the object
A data object requiring 20000 (47040 octal) bytes
appear in the stream as follows
110XXXXX -- identifying a
non-atomic
10000010 -- specifying that the next 2
contain the stream
01001110 -- first byte of number 20000
00100000 -- second
data -- 20,000
Interpretation of the contents of the 20000 bytes
the stream can be performed by a module which knows
specific format of the non-atomic type specified by DEFGH
the type-byte
The remainder of this section defines an initial set
non-atomic types, the format of their encoding, and
semantics of their interpretation
================================
| Non-atomic Object: B-LBITSTR |
================================
The b-LBITSTR (Long BIT Stream) data type is
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-
ABC=110 identifies this as a non-atomic object
DEFGH=00001 specifies that it is a b-LBITSTR. The
sizing information specifies the number of succeeding bytes
Within the data-bytes, the first object encountered
decode to a p-INT. This number conveys the length of
bit stream to follow. The actual bit stream begins with
next byte, and is left-adjusted in the byte stream.
example to encode *101010101010*, the following b-
could be used, although a b-SBITSTR would be more compact
11000001 -- identifies a b-
00000010 -- b-SINTEGER, to specify
10001100 -- size = 2
10101010 -- first 8 data
10100000 -- last 4 data
==============================
| Non-atomic Object: B-STRUC |
==============================
The b-STRUC (STRUCture) data type is used to
any p-STRUC. The translation rules for converting a b-
into a primitive item are presented following the
of b-REPEATs. The b-STRUC format appears as follows
11000010 size-bytes data-
ABC=110 identifies this as a non-atomic type
DEFGH=00010 specifies that the object is a b-STRUC.
the data-bytes stream, objects simply follow in order.
implies that the b-STRUC encoder and decoder modules
simply make use of recursive calls to a
encoder/decoder for processing each element of the b-STRUC
Note that any type of object is permitted as an element of
b-STRUC, but the size information of the b-STRUC
include all bytes used to represent the elements
Containment of b-STRUCs within other b-STRUCs
permitted to any reasonable level. That is, a b-STRUC
contain as an element another b-STRUC, which
another b-STRUC, and so on. All servers are requires
handle such containment to at least a minimum depth
three
Examples of encoded structures appear in a
section
-16-
============================
| Non-atomic Object: B-EDT |
============================
A b-EDT is the object used as the carrier for p-EDTs
transmission of semantic items. It is
identical to a b-STRUC, but has a different type code
permit it to be identified and converted to a semantic
instead of a p-STRUC. The format of a b-EDT follows
11000011 size-bytes data-
As with all non-atomic types, ABC=110 to identify
as such, and DEFGH=00011 to specify a b-EDT. The objects
the data-bytes are decoded as for b-STRUCs. However,
first object must decode to a p-iNT or p-STRING and
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
an item. It is legal only as an component of an
b-STRUC, b-USTRUC, b-EDT, or b-REPEAT. A b-REPEAT is used
concisely specify a set of elements to be treated as if
appeared in the enclosing structure in place of
b-REPEAT. This provides a mechanism for encoding a
of identical data items or patterns efficiently
transmission
A common example of this would be in transmission
text, where line images containing long sequences of spaces
or pages containing multiple carriage-return, line-
pairs, are often encountered. Such sequences could
encoded as an appropriate b-REPEAT to compact the data
transmission. The format of a b-REPEAT is as follows
11000100 -- identifyIng the object as
b-
size-bytes -- the standard non-atomic
size
countspec -- an object which translates to a p-
data -- the objects which define the
The 'countspec' object must translate to an p-INT
specify the number of times that the following data
should be repeated in the object enclosing the b-REPEAT
-17-
The remaining objects in the b-REPEAT constitute
data pattern which is to be repeated. The decoding of
enclosing structure will be continued as if the data
objects appeared 'countspec' times in place of the b-REPEAT
Zero repeat counts are permitted, for generality.
cause no objects to be simulated in the enclosing structure
An encoder does not have to use b-REPEATs at all,
simplicity of coding outweighs the benefits of
compression. In message services, for example, an
might limIt itself to only compressing long text strings.
is important for compatibility, however, to have the
in the decoders to handle b-REPEATs
===============================
| Non-atomic Object: B-USTRUC |
===============================
The b-USTRUC (Uniform Structure) object type
provided to enable servers to convey the fact that a p-
being transferred contains items of only a single type.
most common example would involve a b-USTRUC
translates to a p-STRUC of only p-CHARs, and hence may
considered to be a p-STRING. Servers may use
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
that of a b-STRUC, except for the type-byte. The format of
b-USTRUC follows
11000101 size-bytes data-
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
specification of a structure as a p-STRING.
information will permit receiving servers to process
incoming structure more efficiently. A b-STRING
formatted similarity to a b-USTRUC, except that its type-
identifies the object as a b-STRI/NG. The normal
information is followed by a stream of bytes which
interpreted as b-CHAR7s, Ignoring the high-order bit.
format of a b-STRING follows
11000110 size-bytes data-
ABC=110 to identify a non-atomic object. DEFGH=00110
specifies the object as a b-STRING
-18-
VI.5 -- Structure Translation
A b-STRUC is translated into a p-STRUC. This
performed by translating each object of the b-STRUC Into
corresponding item, and saving it for inclusion In
p-STRUC being generated. A b-USTRUC is handled similarly
but the coding programs may utilize the information that
resultant p-STRUC will contain items of uniform type.
preferred method of coding p-STRINGS is to use b-USTRUCs
If all of the elements of the resultant p-STRUC
p-CHARs, it is presented to the user of the decoder as
p-STRING. A p-STRING should be considered to be a
for a p-STRUC containing only characters. It need
necessarily exist at particular sites which would
p-STRUCs of p-CHARs to their application
The object b-REPEAT is handled in a special
when encountered as an element. When this occurs, the
pattern of the b-REPEAT is translated into a sequence
items, and that sequence is repeated in the next
level as many times as specified in the b-REPEAT
Therefore, b-REPEATS are legal only as elements of
surrounding b-STRUC, b-USTRUC, b-EDT, or b-REPEAT
In encoding a p-STRUC or p-STRING for transmission,
translator may use b-REPEATs as desired to effect
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
carrier for a semantic item. Otherwise, it is
identically to a b-STRUC
VI.6 -- Translation
The following table summarizes the
translations between primitive items and objects
p-INT <--> b-LINTEGER, b-
p-STRING <--> b-STRING, b-STRUC, b-
p-STRUC <--> b-STRING, b-STRUC, b-
p-BITS <--> b=SBITSTR, b-
p-CHAR <--> b-CHAR
p-BOOL <--> b-
p-EMPTY <--> b=
p-XTRA <--> b-
p-EDT <--> b-EDT (all semantic items
-none- <--> b-
-none- <--> b-REPEAT (only within structure
Note that all semantic items are represented as p-
which always exist as b-EDTs in byte-stream format
-19-
V1.7 -- Structure Coding
The following stream transmits a b-STRUC containing 3
b-SINTEGERs, with values 1, 2, and 3, representing a p-
containing three p-INTs, i.e. (1 2 3).
11000010 -- b-
00000011 -- size=3
10000001 -- b-SINTEGER=1
10000010 -- b-SINTEGER=2
10000011 -- b-SINTEGER=3
The next example represents a b-STRUC containing
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
p-STRING
11000010 -- b-
00000100 -- size=4
01011000 -- b-CHAR7 'X
01011001 -- b-CHAR7 'Y
11100001 -- b-
00001010 -- 10
Note that a better way to send this p-STRUC would be
represent the integer as a b-SINTEGER, as shown below
11000010 -- b-
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
the translation of the b-STRING "HELLO".
11000010 -- b-
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-
00000101 -- size=5
01001000 -- 'H
01000101 -- 'E
01001100 -- 'L
01001100 -- 'L
01001111 -- 'O
-20-
To encode a p-STRING containing 20 carriage-
line-feed pairs, the following b-STRUC containing a b-
could be used
11000010 -- b-
00000101 -- size=5
11000100 -- b-
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
contains a sequence of thirty 0's preceded by a single 1,
the following b-STRUC could be used
11000010 -- b-
00000110 -- size=6
10000001 -- b-SINTEGER=1
11000100 -- b-
00000010 -- size=2
10011110 -- count, b-SINTEGER=30
10000000 -- b-SINTEGER=0
VII. A GENERAL DATA TRANSFER
This section considers a possible scheme for
the concept of a data translator into an multi-purpose
transfer mechanism
The proposed environment would provide a set
primitive items, including those enumerated herein
extended as necessary to accommodate a variety
applications. Communication between processes would
defined solely in terms of these items, and
specifically avoid any consideration of the actual
in which the data is transferred
A repertoire of translators would be provided, one
which is the MSDTP machinery, for use in converting items
any of a number of transmission formats. Borrowing
concept from radio terminology, each translator would
analogous to a different type of modulation scheme, to
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
distinguishing features, such as bandwidth, cost, and delay
For each media which a site supports, it would provide
programmers with a module for performing the
required
-21-
Certain media or translators might not handle
items. For example, the MSDTP does not handle items
might be termed p-FLOATs, p-COMPLEXs, p-ARRAY, and so on.
addition, the efficiency of various media for transfer
specific items may differ drastically. MSDTP, for example
transfers data frequently used in message handling
efficiently, but is relatively poor at transfer of
large or deep tree structures
Available at each site as a process or
package wouLd be a module responsible for interfacing
its counterpart at the other end of the media.
modules would use a protocol, not yet defined, to
their capabilities, and choose a particular media
translator, when more than one exists, for transfer of
items
Such a facility could totally insulate
from need to consider encoding formats, machine differences
and so on, as well as eliminate duplication of effort
producing such facilities for every new project
requires them. In addition, as new translators or media
introduced, they would become immediately available
existing users without reprogramming
Implementation of such a protocol should not be
difficult or time-consuming, since it need not be
sophisticated in choosing the most appropriate
mechanism in initial implementations. The system
inherently upward-compatible and easily expandable
-22-
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
