RFC 1832 (rfc1832) - Page 2 of 24

XDR: External Data Representation Standard

RFC 1832       XDR: External Data Representation Standard    August 1995


   5.2 Lexical Notes                                           17
   5.3 Syntax Information                                      18
   5.4 Syntax Notes                                            19
   6. AN EXAMPLE OF AN XDR DATA DESCRIPTION                    20
   7. TRADEMARKS AND OWNERS                                    21
   APPENDIX A: ANSI/IEEE Standard 754-1985                     22
   APPENDIX B: REFERENCES                                      24
   Security Considerations                                     24
   Author's Address                                            24

1. INTRODUCTION

   XDR is a standard for the description and encoding of data.  It is
   useful for transferring data between different computer
   architectures, and has been used to communicate data between such
   diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
   XDR fits into the ISO presentation layer, and is roughly analogous in
   purpose to X.409, ISO Abstract Syntax Notation.  The major difference
   between these two is that XDR uses implicit typing, while X.409 uses
   explicit typing.

   XDR uses a language to describe data formats.  The language can only
   be used only to describe data; it is not a programming language.
   This language allows one to describe intricate data formats in a
   concise manner. The alternative of using graphical representations
   (itself an informal language) quickly becomes incomprehensible when
   faced with complexity.  The XDR language itself is similar to the C
   language [1], just as Courier [4] is similar to Mesa. Protocols such
   as ONC RPC (Remote Procedure Call) and the NFS* (Network File System)
   use XDR to describe the format of their data.

   The XDR standard makes the following assumption: that bytes (or
   octets) are portable, where a byte is defined to be 8 bits of data.
   A given hardware device should encode the bytes onto the various
   media in such a way that other hardware devices may decode the bytes
   without loss of meaning.  For example, the Ethernet* standard
   suggests that bytes be encoded in "little-endian" style [2], or least
   significant bit first.

2. BASIC BLOCK SIZE

   The representation of all items requires a multiple of four bytes (or
   32 bits) of data.  The bytes are numbered 0 through n-1.  The bytes
   are read or written to some byte stream such that byte m always
   precedes byte m+1.  If the n bytes needed to contain the data are not
   a multiple of four, then the n bytes are followed by enough (0 to 3)
   residual zero bytes, r, to make the total byte count a multiple of 4.




Srinivasan                  Standards Track