home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc971.txt < prev    next >
Text File  |  1986-01-07  |  22KB  |  513 lines
  1.  
  2. Network Working Group                                 Annette L. DeSchon
  3. Request for Comments: 971                                            ISI
  4.                                                             January 1986
  5.  
  6.                A SURVEY OF DATA REPRESENTATION STANDARDS
  7.  
  8.  
  9. Status of This Memo
  10.  
  11.    This RFC discusses data representation conventions in the
  12.    ARPA-Internet and suggests possible resolutions.  No proposals in
  13.    this document are intended as standards for the ARPA-Internet at this
  14.    time.  Rather, it is hoped that a general consensus will emerge as to
  15.    the appropriate approach to these issues, leading eventually to the
  16.    adoption of ARPA-Internet standards.  Distribution of this memo is
  17.    unlimited.
  18.  
  19. 1. Introduction
  20.  
  21.    This report is a comparison of several data representation standards
  22.    that are currently in use.  The standards, or system type
  23.    definitions, that will be discussed are the CCITT X.409
  24.    recommendation, the NBS Computer Based Message System (CBMS)
  25.    standard, DARPA Multimedia Mail system, the Courier remote procedure
  26.    call protocol, and the SUN Remote Procedure Call package.
  27.  
  28.    One purpose of this report is to determine how the CCITT standard,
  29.    which is gaining wide acceptance internationally, compares with some
  30.    of the other standards that have been developed in the areas of
  31.    electronic mail, distributed interprocess communication, and remote
  32.    procedure call.  The CCITT X.409 recommendation, which is entitled
  33.    "Presentation Transfer Syntax and Notation" is an international
  34.    standard which is a part of the X.400 series Message Handling Systems
  35.    (MHS) specifications [1].  It has been adopted by both the NBS and
  36.    the ISO standards organizations.  In addition, some commercial
  37.    organizations have announced intentions to support a CCITT interface
  38.    for electronic mail.  The NBS Computer Based Message System (CBMS)
  39.    standard was developed previously and was published as a Federal
  40.    Information Processing Standard (FIPS Publication 98) in 1983 [3].
  41.    The DARPA Multimedia Mail system is an experimental electronic mail
  42.    system which is in use in the DARPA Internet [2,4,5].  It is used to
  43.    create and distribute messages that incorporate text, graphics,
  44.    stored speech, and images and has been implemented on on several very
  45.    different machines.  Courier is the XEROX network systems remote
  46.    procedure call protocol [7].  The SUN Remote Procedure Call package
  47.    implements "network pipes" between UNIX machines [6].
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. DeSchon                                                         [Page 1]
  56.  
  57.  
  58.  
  59. RFC 971                                                     January 1986
  60. A Survey of Data Representation Standards
  61.  
  62.  
  63. 2. Background
  64.  
  65.    This section presents a brief overview of the basic terminology and
  66.    approach of each data representation standard.
  67.  
  68.    2.1. Interprocess Communication Standards
  69.  
  70.       The standards that are oriented towards distributed interprocess
  71.       communication or remote procedure call, between like machines,
  72.       generally favor the use of types that map easily into the types
  73.       defined in the programming language in use on the system.  For
  74.       example, the types defined for the XEROX Courier system resemble
  75.       the types found in the Mesa programming language.  Similarly, the
  76.       SUN Remote Procedure Call system types resemble the types found in
  77.       the C programming language.  An advantage of a system implemented
  78.       using like machines is that the external data representation can
  79.       be defined in such a way that the conversion to and from the local
  80.       format is minimal.
  81.  
  82.       2.1.1. Courier
  83.  
  84.          The Courier standard data types are used to define the data
  85.          objects which are transported bi-directionally between system
  86.          elements that are running the Courier remote procedure call
  87.          protocol.  The "standard representation" of a type is the
  88.          encoding of the data which is transmitted.  The "standard
  89.          notation" refers to the conventions for the interpretation of
  90.          the data by higher-level applications.  The standard
  91.          representation of a data object encodes the value of the
  92.          object, but the type of the object is determined by the
  93.          software that generates or interprets the representation.
  94.  
  95.       2.1.2. SUN Remote Procedure Call Package
  96.  
  97.          The SUN Remote Procedure Call package includes routines which
  98.          allow a process on one UNIX machine to consume data produced by
  99.          a process on another UNIX machine.  This is called a "network
  100.          pipe" and is an extension of the standard UNIX pipe.  The
  101.          "eXternal Data Representation (XDR)" standard defines the
  102.          routines that are used to encode or "serialize" data for
  103.          transmission, or to decode or "deserialize" data for local
  104.          interpretation. The syntax suggests that perhaps it should be
  105.          called "remote interprocess communication" rather than "remote
  106.          procedure call".
  107.  
  108.  
  109.  
  110.  
  111.  
  112. DeSchon                                                         [Page 2]
  113.  
  114.  
  115.  
  116. RFC 971                                                     January 1986
  117. A Survey of Data Representation Standards
  118.  
  119.  
  120.    2.2. Message Standards
  121.  
  122.       The message oriented standards, including DARPA Multimedia Mail,
  123.       NBS CBMS, and the CCITT X.409 standards, seem to favor more
  124.       general, highly extensible type definitions.  This may have
  125.       something to do with the expectation that a system will include
  126.       many different machines, programmed using many different
  127.       programming languages.
  128.  
  129.       2.2.1. DARPA Multimedia Mail
  130.  
  131.          The DARPA Multimedia Mail system was developed for use in DoD
  132.          Internet community.  The set of data elements used in the
  133.          Multimedia Message Handling Facility (MMHF) is referred to as
  134.          its "presentation transfer syntax".  The encoding of these data
  135.          elements varies with the data type being represented. Each
  136.          begins with a one-octet "element-code".  Some data elements are
  137.          of a pre-determined length.  For example, the INTEGER data
  138.          element occupies five octets, one for the element-code, and
  139.          four which contain the "value component".  Other data elements,
  140.          however, may vary in length.  For example, the TEXT data
  141.          element, is made up of a one-octet element-code, a three-octet
  142.          count of the characters to follow, and a variable number of
  143.          octets, each containing one right-justified seven bit ASCII
  144.          character.  The element-code and the length constitute the "tag
  145.          component".
  146.  
  147.          A "base data element" is self contained, while a "structured
  148.          data element" is formed using other data elements.  The LIST
  149.          data element is used to create structures composed of other
  150.          elements.  The tag component of a LIST is made up of a
  151.          one-octet element-code, a three-octet count of the number of
  152.          octets to follow, and a two-octet count of the number of
  153.          elements that follow.  The PROPLIST data element is used to
  154.          create a structure that consists of a set of unordered
  155.          name-value pairs.  The tag component of a PROPLIST is made up
  156.          of a one-octet element-code, a three-octet count of the number
  157.          of octets to follow, and a one-octet count of the number of
  158.          name-value pairs in the PROPLIST.  Both the LIST and the
  159.          PROPLIST elements are followed by an ENDLIST data element.
  160.  
  161.       2.2.2. NBS Computer Based Message System
  162.  
  163.          The NBS Computer Based Message System (CBMS) standard was
  164.          developed to specify the format of a message at the interface
  165.          between different computer-based message systems.  Each data
  166.          element consists of a series of "components".  The five
  167.  
  168.  
  169. DeSchon                                                         [Page 3]
  170.  
  171.  
  172.  
  173. RFC 971                                                     January 1986
  174. A Survey of Data Representation Standards
  175.  
  176.  
  177.          possible types of component are the "identifier octet", the
  178.          "length code", the "qualifier", the "property-list" component,
  179.          and the "data element contents".  Every data element contains
  180.          an identifier octet and a length code.  The identifier octet
  181.          contains a one-bit flag that signifies whether the data element
  182.          contains a property-list, and a code identifying the data
  183.          element and signifying whether it contains a qualifier. In the
  184.          NBS standard, the property-list is associated with a data
  185.          element and contains properties such as a "printing-name" or a
  186.          "comment".  The meaning of the qualifier depends on the data
  187.          element code.  The length code indicates the number of octets
  188.          following, and is between one and three octets in length.
  189.  
  190.          Each data element is inherently a "primitive data element",
  191.          which contains a basic item of information, or a "constructor
  192.          data element", which contains one or more data elements.  The
  193.          "field" data element (itself a constructor) uses a qualifier
  194.          component, which contains a "field identifier" to indicate
  195.          which specific field is being represented within a message.
  196.  
  197.       2.2.3. CCITT Recommendation X.409
  198.  
  199.          The CCITT recommendation X.409 defines the notation and the
  200.          representational technique used to specify and to encode the
  201.          Message Handling System (MHS) protocols.  The following is a
  202.          description of the CCITT approach to encoding type definitions.
  203.          A data element consists of three components, the "identifier"
  204.          (type), the "length", and the "contents".  An element and its
  205.          components consist of a sequence of an integral number of
  206.          octets.  An identifier consists of a "class" ("universal",
  207.          "application-wide", "context-specific", or "private-use"), a
  208.          "form" ("primitive" or "constructor"), and the "id code".
  209.          There is a convention defined for both single-octet and
  210.          multi-octet identifiers.  The length specifies the length of
  211.          the contents in octets, and is itself variable in length.
  212.          There is also an "indefinite" value defined for the length;
  213.          this means that no length for the contents is specified, and
  214.          the contents is terminated with the the "end-of-contents" (EOC)
  215.          element.  In X.409 it is possible to determine whether a data
  216.          element is a primitive or a constructor from the form part of
  217.          the identifier.  In addition it is possible to "tag" the data
  218.          by attaching meaning to an id code within the context of a
  219.          specific application.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. DeSchon                                                         [Page 4]
  227.  
  228.  
  229.  
  230. RFC 971                                                     January 1986
  231. A Survey of Data Representation Standards
  232.  
  233.  
  234. 3. Implicit Versus Explicit Representation
  235.  
  236.    In both the SUN Remote Procedure Call system and the XEROX Courier
  237.    system the type definitions of external data are implicit.  This
  238.    means that for a given type of call, or message, the type definitions
  239.    which is to be used to interpret the data, are agreed upon by the
  240.    sender and the receiver in advance.  In other words, parameters (or
  241.    message fields) are assumed to be in a predefined order.  Each
  242.    parameter is assumed to be of a predefined type.  This means the data
  243.    cannot be reformated into the local form until it reaches a process
  244.    that knows about the types of specific parameters.  At this point,
  245.    the conversion can be accomplished using system routines that know
  246.    how to convert from the external format to the local format.  If the
  247.    system is homogeneous there may be very little conversion required.
  248.    In addition, no extra overhead of sending the type definitions with
  249.    the data is incurred.
  250.  
  251.    In the DARPA Multimedia Mail system, the NBS CBMS standard, and the
  252.    CCITT X.409 recommendation, type definitions are explicit.  In this
  253.    case the type definitions are encoded into the message.  There are
  254.    several advantages to this approach.  One advantage is that it allows
  255.    a low level receiver process in the destination host to convert the
  256.    data from the standard form to a form appropriate for the local host,
  257.    as it received.  This can increase efficiency if it allows the
  258.    destination host to avoid passing around data that does not conform
  259.    to the local word boundaries.  Another advantage is that it provides
  260.    flexibility for future expansion.  Since the overall length is a part
  261.    of the type definition, it allows a host to deal with or ignore data
  262.    of types that it does not necessarily understand.  Since the
  263.    interpretation of the data is not dependent on its position, message
  264.    fields (or parameters) can be reordered, or optionally omitted.  The
  265.    disadvantages of this approach are as follows.  Assuming that no
  266.    field could be omitted, the external representation of the message
  267.    may be longer than it would have been if an implicit representation
  268.    had been used.  In addition, extra time may be consumed by the
  269.    conversion between external format and local format, since the
  270.    external format almost certainly will not match the local format for
  271.    any of the participants.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283. DeSchon                                                         [Page 5]
  284.  
  285.  
  286.  
  287. RFC 971                                                     January 1986
  288. A Survey of Data Representation Standards
  289.  
  290.  
  291. 4. Data Representation Standards Scorecard
  292.  
  293.    The following table is a comparison of the data elements defined for
  294.    the various standards being discussed.  It is provided in order to
  295.    give a general idea of the types defined for each standard, but it
  296.    should be noted that the grouping of these types does not indicate
  297.    one type corresponds exactly to any other.  Where it is applicable,
  298.    the identifier code appears in parantheses following the name of the
  299.    data element.  Under "NUMBER", "S" stands for signed, "U" stands for
  300.    unsigned, "V" stands for variable, and the number represents the
  301.    number of bits.  For example, "Integer S16" means a "signed 16-bit
  302.    integer".
  303.  
  304.    
  305.  Type       CCITT        MMM         NBS         XEROX       Sun
  306.  -----------------------------------------------------------------------
  307.  END    | End-of-   | ENDLIST   | End-of-    |    --     |    --
  308.         |  Contents |   (11)    | Constructor|           |
  309.         |    (0)    |           |    (1)     |           |
  310.         |           |           |            |           |
  311.  PAD    | Null (5)  | NOP (0)   | No-Op (0)  |    --     |    --
  312.         |           | PAD (1)   | Padding    |           |
  313.         |           |           |   (33)     |           |
  314.         |           |           |            |           |
  315.  RECORD | Set (17)  | PROPLIST  | Set (11)   |    --     |    --
  316.         |           |   (14)    |            |           |
  317.         | Sequence  | LIST (9)  | Sequence   | Sequence  | Structure
  318.         |   (16)    |           |   (10)     |           |
  319.         |           |           |            | Record    |
  320.         |           |           | Message    |           |
  321.         |           |           |   (77)     |           |
  322.         |    --     |    --     |     --     | Array     | Fixed Array
  323.         |           |           |            |           | Counted Array
  324.         | "Choice"  |    --     |     --     | Choice    |Discriminated-
  325.         | "Any"     |           |            |           |   Union
  326.         |           |           |            |           |
  327.         | "Tagged"  | "name"    | Field (76) |    --     |    --
  328.         |           |           |Unique-ID(9)|           |
  329.         |    --     | SHARE-TAG |     --     |    --     |    --
  330.         |           |   (12)    |            |           |
  331.         |           | SHARE-REF |            |           |
  332.         |           |   (13)    |            |           |
  333.         |           |           |            |           |
  334.         |    --     |    --     | Compressed |    --     |    --
  335.         |           |           |   (70)     |           |
  336.         |    --     | ENCRYPT   | Encrypted  |    --     |    --
  337.         |           |   (14)    |    (71)    |           |
  338.  
  339.  
  340. DeSchon                                                         [Page 6]
  341.  
  342.  
  343.  
  344. RFC 971                                                     January 1986
  345. A Survey of Data Representation Standards
  346.  
  347.  
  348.  Type       CCITT        MMM         NBS         XEROX       Sun
  349.  -----------------------------------------------------------------------
  350.  BOOLEAN| Boolean(1)| BOOLEAN(2)| Boolean(8) | Boolean   | Boolean
  351.         |           |           |            |           |
  352.  NUMBER | Integer(2)| EPI (5)   | Integer(32)| Integer   | Integer
  353.         |   SV      |   SV      |   SV       |   S16     |  S32
  354.         |           | INDEX (3) |            | Cardinal  | Unsigned Int
  355.         |           |   U16     |            |   U16     |  U32
  356.         |           | INTEGER(4)|            |Unspecified|Enumeration
  357.         |           |   S32     |            |   16      |  32
  358.         |           |           |            | Long Int  |Hyper Integer
  359.         |           |           |            |   S32     |  S64
  360.         |           |           |            | Long Card |Uns Hyper Int
  361.         |           |           |            |   U32     |  U64
  362.         |           |           |            |           | Double Prec
  363.         |           |           |            |           |   64
  364.         |    --     | FLOAT (15)|     --     |    --     | Float Pt
  365.         |           |   64      |            |           |   32
  366.         |           |           |            |           |
  367.  BIT-   | Bit String| BITSTR(6) | Bit-String |    --     |    --
  368.   STRING|   (3)     |           |   (67)     |           |
  369.         | Octet-    |    --     |     --     |    --     | Opaque
  370.         |  String(4)|           |            |           |
  371.         |           |           |            |           |
  372.  STRING | IA5 (22)  | TEXT (8)  | ASCII-     | String    | Counted-
  373.         |           |           |  String (2)|           |  Byte String
  374.         |           | NAME (7)  |            |           |
  375.         | Numeric   |           |            |           |
  376.         |   (18)    |           |            |           |
  377.         | Printable |           |            |           |
  378.         |   (19)    |           |            |           |
  379.         | T.61 (20) |           |            |           |
  380.         | Videotex  |           |            |           |
  381.         |   (21)    |           |            |           |
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397. DeSchon                                                         [Page 7]
  398.  
  399.  
  400.  
  401. RFC 971                                                     January 1986
  402. A Survey of Data Representation Standards
  403.  
  404.  
  405.  Type       CCITT        MMM         NBS         XEROX       Sun
  406.  -----------------------------------------------------------------------
  407.  OTHER  | UTC Time  |    --     | Date (40)  |    --     |    --
  408.         |   (23)    |           |            |           |
  409.         | Gen Time  |           |            |           |
  410.         |   (24)    |           |            |           |
  411.         |    --     |    --     | Property-  |    --     |    --
  412.         |           |           |   List (36)|           |
  413.         |    --     |    --     |Property(69)|    --     |    --
  414.         |           |           |            |           |
  415.         |    --     |    --     |    --      | Procedure |    --
  416.         |           |           |            |           |
  417.         |    --     |    --     | Vendor-    |    --     |    --
  418.         |           |           |  Defined   |           |
  419.         |           |           |   (127)    |           |
  420.         |           |           | Extension  |           |
  421.         |           |           |   (126)    |           |
  422.  
  423.  
  424. 5. Conclusions
  425.  
  426.    Of the standards discussed in this survey, the CCITT approach (X.409)
  427.    has already gained wide acceptance.  For a system that will include a
  428.    number of dissimilar hosts, as might be the case for an Internet
  429.    application, a standard that employs explicit representation, such as
  430.    the CCITT X.409, would probably work well.  Using the CCITT X.409
  431.    standard it is possible to construct most of the data elements that
  432.    are specified for the other standards, with the possible exception of
  433.    the "floating point" type. However, some of the flexibility that has
  434.    been built into this standard, such as the "private-use class" may
  435.    lead to ambiguity and a lack of coordination between implementors at
  436.    different sites.  If a standard such as the CCITT were to be used in
  437.    an Internet experiment a fully defined (but large) subset would
  438.    probably have to be selected.
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454. DeSchon                                                         [Page 8]
  455.  
  456.  
  457.  
  458. RFC 971                                                     January 1986
  459. A Survey of Data Representation Standards
  460.  
  461.  
  462. 6. References
  463.  
  464.    [1]  "Message Handling Systems: Presentation Transfer Syntax and
  465.         Notation", Recommendation X.409, Document AP VIII-66-E,
  466.         International Telegraph and Telephone Consultative Committee
  467.         (CCITT), Malaga-Torremolinos, June, 1984.
  468.  
  469.    [2]  J. Garcia-Luna, A. Poggio, and D. Elliot, "Research into
  470.         Multimedia Message System Architecture", SRI International,
  471.         February, 1984.
  472.  
  473.    [3]  "Specification for Message Format for Computer Based Message
  474.         Systems", FIPS Pub 98 (also published as RFC 841), National
  475.         Bureau of Standards, January, 1983.
  476.  
  477.    [4]  J. Postel, "Internet Multimedia Mail Transfer Protocol", USC
  478.         Information Sciences Institute, MMM-11 (RFC-759 revised), March,
  479.         1982.
  480.  
  481.    [5]  J. Postel, "Internet Multimedia Mail Document Format", USC
  482.         Information Sciences Institute, MMM-12 (RFC-767 revised), March,
  483.         1982.
  484.  
  485.    [6]  "Extended Data Representation Reference Manual", SUN
  486.         Microsystems, September, 1984.
  487.  
  488.    [7]  "Courier: The Remote Procedure Call Protocol", XSIS-038112,
  489.         XEROX Corporation, December, 1981.
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511. DeSchon                                                         [Page 9]
  512.  
  513.