rfc1014.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   (2) Why is there only one byte-order for an XDR unit?

   Supporting two byte-orderings requires a higher level protocol for
   determining in which byte-order the data is encoded.  Since XDR is
   not a protocol, this can't be done.  The advantage of this, though,
   is that data in XDR format can be written to a magnetic tape, for
   example, and any machine will be able to interpret it, since no
   higher level protocol is necessary for determining the byte-order.

   (3) Why is the XDR byte-order big-endian instead of little-endian?
   Isn't this unfair to little-endian machines such as the VAX(r), which
   has to convert from one form to the other?

   Yes, it is unfair, but having only one byte-order means you have to
   be unfair to somebody.  Many architectures, such as the Motorola
   68000* and IBM 370*, support the big-endian byte-order.

   (4) Why is the XDR unit four bytes wide?

   There is a tradeoff in choosing the XDR unit size.  Choosing a small
   size such as two makes the encoded data small, but causes alignment
   problems for machines that aren't aligned on these boundaries.  A
   large size such as eight means the data will be aligned on virtually
   every machine, but causes the encoded data to grow too big.  We chose
   four as a compromise.  Four is big enough to support most
   architectures efficiently, except for rare machines such as the
   eight-byte aligned Cray*.  Four is also small enough to keep the
   encoded data restricted to a reasonable size.






SUN Microsystems                                               [Page 14]

RFC 1014              External Data Representation             June 1987


   (5) Why must variable-length data be padded with zeros?

   It is desirable that the same data encode into the same thing on all
   machines, so that encoded data can be meaningfully compared or
   checksummed.  Forcing the padded bytes to be zero ensures this.

   (6) Why is there no explicit data-typing?

   Data-typing has a relatively high cost for what small advantages it
   may have.  One cost is the expansion of data due to the inserted type
   fields.  Another is the added cost of interpreting these type fields
   and acting accordingly.  And most protocols already know what type
   they expect, so data-typing supplies only redundant information.
   However, one can still get the benefits of data-typing using XDR. One
   way is to encode two things: first a string which is the XDR data
   description of the encoded data, and then the encoded data itself.
   Another way is to assign a value to all the types in XDR, and then
   define a universal type which takes this value as its discriminant
   and for each value, describes the corresponding data type.


5. THE XDR LANGUAGE SPECIFICATION

   5.1 Notational Conventions

   This specification uses an extended Back-Naur Form notation for
   describing the XDR language.  Here is a brief description of the
   notation:


   (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special.
   (2) Terminal symbols are strings of any characters surrounded by
   double quotes.
   (3) Non-terminal symbols are strings of non-special characters.
   (4) Alternative items are separated by a vertical bar ("|").
   (5) Optional items are enclosed in brackets.
   (6) Items are grouped together by enclosing them in parentheses.
   (7) A '*' following an item means 0 or more occurrences of that item.

   For example,  consider  the  following pattern:

         "a " "very" (", " "very")* [" cold " "and "]  " rainy "
         ("day" | "night")

   An infinite number of strings match this pattern. A few of them are:






SUN Microsystems                                               [Page 15]

RFC 1014              External Data Representation             June 1987


         "a very rainy day"
         "a very, very rainy day"
         "a very cold and  rainy day"
         "a very, very, very cold and  rainy night"

5.2 Lexical Notes

   (1) Comments begin with '/*' and terminate with '*/'.
   (2) White space serves to separate items and is otherwise ignored.
   (3) An identifier is a letter followed by an optional sequence of
   letters, digits or underbar ('_'). The case of identifiers is not
   ignored.
   (4) A constant is a sequence of one or more decimal digits,
   optionally preceded by a minus-sign ('-').

5.3 Syntax Information

      declaration:
           type-specifier identifier
         | type-specifier identifier "[" value "]"
         | type-specifier identifier "<" [ value ] ">"
         | "opaque" identifier "[" value "]"
         | "opaque" identifier "<" [ value ] ">"
         | "string" identifier "<" [ value ] ">"
         | type-specifier "*" identifier
         | "void"

      value:
           constant
         | identifier

      type-specifier:
           [ "unsigned" ] "int"
         | [ "unsigned" ] "hyper"
         | "float"
         | "double"
         | "bool"
         | enum-type-spec
         | struct-type-spec
         | union-type-spec
         | identifier

      enum-type-spec:
         "enum" enum-body

      enum-body:
         "{"
            ( identifier "=" value )



SUN Microsystems                                               [Page 16]

RFC 1014              External Data Representation             June 1987


            ( "," identifier "=" value )*
         "}"

      struct-type-spec:
         "struct" struct-body

      struct-body:
         "{"
            ( declaration ";" )
            ( declaration ";" )*
         "}"

      union-type-spec:
         "union" union-body

      union-body:
         "switch" "(" declaration ")" "{"
            ( "case" value ":" declaration ";" )
            ( "case" value ":" declaration ";" )*
            [ "default" ":" declaration ";" ]
         "}"

      constant-def:
         "const" identifier "=" constant ";"

      type-def:
           "typedef" declaration ";"
         | "enum" identifier enum-body ";"
         | "struct" identifier struct-body ";"
         | "union" identifier union-body ";"

      definition:
           type-def
         | constant-def

      specification:
           definition *

5.4 Syntax Notes

   (1) The following are keywords and cannot be used as identifiers:
   "bool", "case", "const", "default", "double", "enum", "float",
   "hyper", "opaque", "string", "struct", "switch", "typedef", "union",
   "unsigned" and "void".

   (2) Only unsigned constants may be used as size specifications for
   arrays.  If an identifier is used, it must have been declared
   previously as an unsigned constant in a "const" definition.



SUN Microsystems                                               [Page 17]

RFC 1014              External Data Representation             June 1987


   (3) Constant and type identifiers within the scope of a specification
   are in the same name space and must be declared uniquely within this
   scope.

   (4) Similarly, variable names must  be unique within  the scope  of
   struct and union declarations. Nested struct and union declarations
   create new scopes.

   (5) The discriminant of a union must be of a type that evaluates to
   an integer. That is, "int", "unsigned int", "bool", an enumerated
   type or any typedefed type that evaluates to one of these is legal.
   Also, the case values must be one of the legal values of the
   discriminant.  Finally, a case value may not be specified more than
   once within the scope of a union declaration.

6. AN EXAMPLE OF AN XDR DATA DESCRIPTION

   Here is a short XDR data description of a thing called a "file",
   which might be used to transfer files from one machine to another.

         const MAXUSERNAME = 32;     /* max length of a user name */
         const MAXFILELEN = 65535;   /* max length of a file      */
         const MAXNAMELEN = 255;     /* max length of a file name */

         /*
          * Types of files:
          */
         enum filekind {
            TEXT = 0,       /* ascii data */
            DATA = 1,       /* raw data   */
            EXEC = 2        /* executable */
         };

         /*
          * File information, per kind of file:
          */
         union filetype switch (filekind kind) {
         case TEXT:
            void;                           /* no extra information */
         case DATA:
            string creator<MAXNAMELEN>;     /* data creator         */
         case EXEC:
            string interpretor<MAXNAMELEN>; /* program interpretor  */
         };







SUN Microsystems                                               [Page 18]

RFC 1014              External Data Representation             June 1987


         /*
          * A complete file:
          */
         struct file {
            string filename<MAXNAMELEN>; /* name of file    */
            filetype type;               /* info about file */
            string owner<MAXUSERNAME>;   /* owner of file   */
            opaque data<MAXFILELEN>;     /* file data       */
         };

   Suppose now that there is a user named "john" who wants to store his
   lisp program "sillyprog" that contains just the data "(quit)".  His
   file would be encoded as follows:

       OFFSET  HEX BYTES       ASCII    COMMENTS
       ------  ---------       -----    --------
        0      00 00 00 09     ....     -- length of filename = 9
        4      73 69 6c 6c     sill     -- filename characters
        8      79 70 72 6f     ypro     -- ... and more characters ...
       12      67 00 00 00     g...     -- ... and 3 zero-bytes of fill
       16      00 00 00 02     ....     -- filekind is EXEC = 2
       20      00 00 00 04     ....     -- length of interpretor = 4
       24      6c 69 73 70     lisp     -- interpretor characters
       28      00 00 00 04     ....     -- length of owner = 4
       32      6a 6f 68 6e     john     -- owner characters
       36      00 00 00 06     ....     -- length of file data = 6
       40      28 71 75 69     (qui     -- file data bytes ...
       44      74 29 00 00     t)..     -- ... and 2 zero-bytes of fill

7. REFERENCES

   [1]  Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
        Language", Bell Laboratories, Murray Hill, New Jersey, 1978.

   [2]  Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer,
        October 1981.

   [3]  "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
        Standard 754-1985, Institute of Electrical and Electronics
        Engineers, August 1985.

   [4]  "Courier: The Remote Procedure Call Protocol", XEROX
        Corporation, XSIS 038112, December 1981.








SUN Microsystems                                               [Page 19]

RFC 1014              External Data Representation             June 1987


8. TRADEMARKS AND OWNERS

        SUN WORKSTATION  Sun Microsystems, Inc.
        VAX              Digital Equipment Corporation
        IBM-PC           International Business Machines Corporation
        Cray             Cray Research
        NFS              Sun Microsystems, Inc.
        Ethernet         Xerox Corporation.
        Motorola 68000   Motorola, Inc.
        IBM 370          International Business Machines Corporation









































SUN Microsystems                                               [Page 20]