As per Relevance of the word procedure, we have this rfc below:
Network Working Group Annette L.
Request for Comments: 971
January 1986
A SURVEY OF DATA REPRESENTATION
Status of This
This RFC discusses data representation conventions in
ARPA-Internet and suggests possible resolutions. No proposals
this document are intended as standards for the ARPA-Internet at
time. Rather, it is hoped that a general consensus will emerge as
the appropriate approach to these issues, leading eventually to
adoption of ARPA-Internet standards. Distribution of this memo
unlimited
1.
This report is a comparison of several data representation
that are currently in use. The standards, or system
definitions, that will be discussed are the CCITT X.409
recommendation, the NBS Computer Based Message System (CBMS
standard, DARPA Multimedia Mail system, the Courier remote
call protocol, and the SUN Remote Procedure Call package
One purpose of this report is to determine how the CCITT standard
which is gaining wide acceptance internationally, compares with
of the other standards that have been developed in the areas
electronic mail, distributed interprocess communication, and
procedure call. The CCITT X.409 recommendation, which is
"Presentation Transfer Syntax and Notation" is an
standard which is a part of the X.400 series Message Handling
(MHS) specifications [1]. It has been adopted by both the NBS
the ISO standards organizations. In addition, some
organizations have announced intentions to support a CCITT
for electronic mail. The NBS Computer Based Message System (CBMS
standard was developed previously and was published as a
Information Processing Standard (FIPS Publication 98) in 1983 [3].
The DARPA Multimedia Mail system is an experimental electronic
system which is in use in the DARPA Internet [2,4,5]. It is used
create and distribute messages that incorporate text, graphics
stored speech, and images and has been implemented on on several
different machines. Courier is the XEROX network systems
procedure call protocol [7]. The SUN Remote Procedure Call
implements "network pipes" between UNIX machines [6].
DeSchon [Page 1]
RFC 971 January 1986
A Survey of Data Representation
2.
This section presents a brief overview of the basic terminology
approach of each data representation standard
2.1. Interprocess Communication
The standards that are oriented towards distributed
communication or remote procedure call, between like machines
generally favor the use of types that map easily into the
defined in the programming language in use on the system.
example, the types defined for the XEROX Courier system
the types found in the Mesa programming language. Similarly,
SUN Remote Procedure Call system types resemble the types found
the C programming language. An advantage of a system
using like machines is that the external data representation
be defined in such a way that the conversion to and from the
format is minimal
2.1.1.
The Courier standard data types are used to define the
objects which are transported bi-directionally between
elements that are running the Courier remote procedure
protocol. The "standard representation" of a type is
encoding of the data which is transmitted. The "
notation" refers to the conventions for the interpretation
the data by higher-level applications. The
representation of a data object encodes the value of
object, but the type of the object is determined by
software that generates or interprets the representation
2.1.2. SUN Remote Procedure Call
The SUN Remote Procedure Call package includes routines
allow a process on one UNIX machine to consume data produced
a process on another UNIX machine. This is called a "
pipe" and is an extension of the standard UNIX pipe.
"eXternal Data Representation (XDR)" standard defines
routines that are used to encode or "serialize" data
transmission, or to decode or "deserialize" data for
interpretation. The syntax suggests that perhaps it should
called "remote interprocess communication" rather than "
procedure call".
DeSchon [Page 2]
RFC 971 January 1986
A Survey of Data Representation
2.2. Message
The message oriented standards, including DARPA Multimedia Mail
NBS CBMS, and the CCITT X.409 standards, seem to favor
general, highly extensible type definitions. This may
something to do with the expectation that a system will
many different machines, programmed using many
programming languages
2.2.1. DARPA Multimedia
The DARPA Multimedia Mail system was developed for use in
Internet community. The set of data elements used in
Multimedia Message Handling Facility (MMHF) is referred to
its "presentation transfer syntax". The encoding of these
elements varies with the data type being represented.
begins with a one-octet "element-code". Some data elements
of a pre-determined length. For example, the INTEGER
element occupies five octets, one for the element-code,
four which contain the "value component". Other data elements
however, may vary in length. For example, the TEXT
element, is made up of a one-octet element-code, a three-
count of the characters to follow, and a variable number
octets, each containing one right-justified seven bit
character. The element-code and the length constitute the "
component".
A "base data element" is self contained, while a "
data element" is formed using other data elements. The
data element is used to create structures composed of
elements. The tag component of a LIST is made up of
one-octet element-code, a three-octet count of the number
octets to follow, and a two-octet count of the number
elements that follow. The PROPLIST data element is used
create a structure that consists of a set of
name-value pairs. The tag component of a PROPLIST is made
of a one-octet element-code, a three-octet count of the
of octets to follow, and a one-octet count of the number
name-value pairs in the PROPLIST. Both the LIST and
PROPLIST elements are followed by an ENDLIST data element
2.2.2. NBS Computer Based Message
The NBS Computer Based Message System (CBMS) standard
developed to specify the format of a message at the
between different computer-based message systems. Each
element consists of a series of "components". The
DeSchon [Page 3]
RFC 971 January 1986
A Survey of Data Representation
possible types of component are the "identifier octet",
"length code", the "qualifier", the "property-list" component
and the "data element contents". Every data element
an identifier octet and a length code. The identifier
contains a one-bit flag that signifies whether the data
contains a property-list, and a code identifying the
element and signifying whether it contains a qualifier. In
NBS standard, the property-list is associated with a
element and contains properties such as a "printing-name" or
"comment". The meaning of the qualifier depends on the
element code. The length code indicates the number of
following, and is between one and three octets in length
Each data element is inherently a "primitive data element",
which contains a basic item of information, or a "
data element", which contains one or more data elements.
"field" data element (itself a constructor) uses a
component, which contains a "field identifier" to
which specific field is being represented within a message
2.2.3. CCITT Recommendation X.409
The CCITT recommendation X.409 defines the notation and
representational technique used to specify and to encode
Message Handling System (MHS) protocols. The following is
description of the CCITT approach to encoding type definitions
A data element consists of three components, the "identifier
(type), the "length", and the "contents". An element and
components consist of a sequence of an integral number
octets. An identifier consists of a "class" ("universal",
"application-wide", "context-specific", or "private-use"),
"form" ("primitive" or "constructor"), and the "id code".
There is a convention defined for both single-octet
multi-octet identifiers. The length specifies the length
the contents in octets, and is itself variable in length
There is also an "indefinite" value defined for the length
this means that no length for the contents is specified,
the contents is terminated with the the "end-of-contents" (EOC
element. In X.409 it is possible to determine whether a
element is a primitive or a constructor from the form part
the identifier. In addition it is possible to "tag" the
by attaching meaning to an id code within the context of
specific application
DeSchon [Page 4]
RFC 971 January 1986
A Survey of Data Representation
3. Implicit Versus Explicit
In both the SUN Remote Procedure Call system and the XEROX
system the type definitions of external data are implicit.
means that for a given type of call, or message, the type
which is to be used to interpret the data, are agreed upon by
sender and the receiver in advance. In other words, parameters (
message fields) are assumed to be in a predefined order.
parameter is assumed to be of a predefined type. This means the
cannot be reformated into the local form until it reaches a
that knows about the types of specific parameters. At this point
the conversion can be accomplished using system routines that
how to convert from the external format to the local format. If
system is homogeneous there may be very little conversion required
In addition, no extra overhead of sending the type definitions
the data is incurred
In the DARPA Multimedia Mail system, the NBS CBMS standard, and
CCITT X.409 recommendation, type definitions are explicit. In
case the type definitions are encoded into the message. There
several advantages to this approach. One advantage is that it
a low level receiver process in the destination host to convert
data from the standard form to a form appropriate for the local host
as it received. This can increase efficiency if it allows
destination host to avoid passing around data that does not
to the local word boundaries. Another advantage is that it
flexibility for future expansion. Since the overall length is a
of the type definition, it allows a host to deal with or ignore
of types that it does not necessarily understand. Since
interpretation of the data is not dependent on its position,
fields (or parameters) can be reordered, or optionally omitted.
disadvantages of this approach are as follows. Assuming that
field could be omitted, the external representation of the
may be longer than it would have been if an implicit
had been used. In addition, extra time may be consumed by
conversion between external format and local format, since
external format almost certainly will not match the local format
any of the participants
DeSchon [Page 5]
RFC 971 January 1986
A Survey of Data Representation
4. Data Representation Standards
The following table is a comparison of the data elements defined
the various standards being discussed. It is provided in order
give a general idea of the types defined for each standard, but
should be noted that the grouping of these types does not
one type corresponds exactly to any other. Where it is applicable
the identifier code appears in parantheses following the name of
data element. Under "NUMBER", "S" stands for signed, "U" stands
unsigned, "V" stands for variable, and the number represents
number of bits. For example, "Integer S16" means a "signed 16-
integer".
Type CCITT MMM NBS XEROX
-----------------------------------------------------------------------
END | End-of- | ENDLIST | End-of- | -- | --
| Contents | (11) | Constructor| |
| (0) | | (1) | |
| | | | |
PAD | Null (5) | NOP (0) | No-Op (0) | -- | --
| | PAD (1) | Padding | |
| | | (33) | |
| | | | |
RECORD | Set (17) | PROPLIST | Set (11) | -- | --
| | (14) | | |
| Sequence | LIST (9) | Sequence | Sequence |
| (16) | | (10) | |
| | | | Record |
| | | Message | |
| | | (77) | |
| -- | -- | -- | Array | Fixed
| | | | | Counted
| "Choice" | -- | -- | Choice |Discriminated
| "Any" | | | |
| | | | |
| "Tagged" | "name" | Field (76) | -- | --
| | |Unique-ID(9)| |
| -- | SHARE-TAG | -- | -- | --
| | (12) | | |
| | SHARE-REF | | |
| | (13) | | |
| | | | |
| -- | -- | Compressed | -- | --
| | | (70) | |
| -- | ENCRYPT | Encrypted | -- | --
| | (14) | (71) | |
DeSchon [Page 6]
RFC 971 January 1986
A Survey of Data Representation
Type CCITT MMM NBS XEROX
-----------------------------------------------------------------------
BOOLEAN| Boolean(1)| BOOLEAN(2)| Boolean(8) | Boolean |
| | | | |
NUMBER | Integer(2)| EPI (5) | Integer(32)| Integer |
| SV | SV | SV | S16 | S32
| | INDEX (3) | | Cardinal | Unsigned
| | U16 | | U16 | U32
| | INTEGER(4)| |Unspecified|
| | S32 | | 16 | 32
| | | | Long Int |Hyper
| | | | S32 | S64
| | | | Long Card |Uns Hyper
| | | | U32 | U64
| | | | | Double
| | | | | 64
| -- | FLOAT (15)| -- | -- | Float
| | 64 | | | 32
| | | | |
BIT- | Bit String| BITSTR(6) | Bit-String | -- | --
STRING| (3) | | (67) | |
| Octet- | -- | -- | -- |
| String(4)| | | |
| | | | |
STRING | IA5 (22) | TEXT (8) | ASCII- | String | Counted
| | | String (2)| | Byte
| | NAME (7) | | |
| Numeric | | | |
| (18) | | | |
| Printable | | | |
| (19) | | | |
| T.61 (20) | | | |
| Videotex | | | |
| (21) | | | |
DeSchon [Page 7]
RFC 971 January 1986
A Survey of Data Representation
Type CCITT MMM NBS XEROX
-----------------------------------------------------------------------
OTHER | UTC Time | -- | Date (40) | -- | --
| (23) | | | |
| Gen Time | | | |
| (24) | | | |
| -- | -- | Property- | -- | --
| | | List (36)| |
| -- | -- |Property(69)| -- | --
| | | | |
| -- | -- | -- | Procedure | --
| | | | |
| -- | -- | Vendor- | -- | --
| | | Defined | |
| | | (127) | |
| | | Extension | |
| | | (126) | |
5.
Of the standards discussed in this survey, the CCITT approach (X.409)
has already gained wide acceptance. For a system that will include
number of dissimilar hosts, as might be the case for an
application, a standard that employs explicit representation, such
the CCITT X.409, would probably work well. Using the CCITT X.409
standard it is possible to construct most of the data elements
are specified for the other standards, with the possible exception
the "floating point" type. However, some of the flexibility that
been built into this standard, such as the "private-use class"
lead to ambiguity and a lack of coordination between implementors
different sites. If a standard such as the CCITT were to be used
an Internet experiment a fully defined (but large) subset
probably have to be selected
DeSchon [Page 8]
RFC 971 January 1986
A Survey of Data Representation
6.
[1] "Message Handling Systems: Presentation Transfer Syntax
Notation", Recommendation X.409, Document AP VIII-66-E
International Telegraph and Telephone Consultative
(CCITT), Malaga-Torremolinos, June, 1984.
[2] J. Garcia-Luna, A. Poggio, and D. Elliot, "Research
Multimedia Message System Architecture", SRI International
February, 1984.
[3] "Specification for Message Format for Computer Based
Systems", FIPS Pub 98 (also published as RFC 841),
Bureau of Standards, January, 1983.
[4] J. Postel, "Internet Multimedia Mail Transfer Protocol",
Information Sciences Institute, MMM-11 (RFC-759 revised), March
1982.
[5] J. Postel, "Internet Multimedia Mail Document Format",
Information Sciences Institute, MMM-12 (RFC-767 revised), March
1982.
[6] "Extended Data Representation Reference Manual",
Microsystems, September, 1984.
[7] "Courier: The Remote Procedure Call Protocol", XSIS-038112,
XEROX Corporation, December, 1981.
DeSchon [Page 9]
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
