2ndInstMeasWork: ref OMF_OML-1 rfc4506.txt

File ref OMF_OML-1 rfc4506.txt, 54.2 KB (added by jtaylor@bbn.com, 9 years ago)
Line 
1
2
3
4
5
6
7Network Working Group                                     M. Eisler, Ed.
8Request for Comments: 4506                       Network Appliance, Inc.
9STD: 67                                                         May 2006
10Obsoletes: 1832
11Category: Standards Track
12
13
14               XDR: External Data Representation Standard
15
16Status of This Memo
17
18   This document specifies an Internet standards track protocol for the
19   Internet community, and requests discussion and suggestions for
20   improvements.  Please refer to the current edition of the "Internet
21   Official Protocol Standards" (STD 1) for the standardization state
22   and status of this protocol.  Distribution of this memo is unlimited.
23
24Copyright Notice
25
26   Copyright (C) The Internet Society (2006).
27
28Abstract
29
30   This document describes the External Data Representation Standard
31   (XDR) protocol as it is currently deployed and accepted.  This
32   document obsoletes RFC 1832.
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Eisler                      Standards Track                     [Page 1]
59
60RFC 4506       XDR: External Data Representation Standard       May 2006
61
62
63Table of Contents
64
65   1. Introduction ....................................................3
66   2. Changes from RFC 1832 ...........................................3
67   3. Basic Block Size ................................................3
68   4. XDR Data Types ..................................................4
69      4.1. Integer ....................................................4
70      4.2. Unsigned Integer ...........................................4
71      4.3. Enumeration ................................................5
72      4.4. Boolean ....................................................5
73      4.5. Hyper Integer and Unsigned Hyper Integer ...................5
74      4.6. Floating-Point .............................................6
75      4.7. Double-Precision Floating-Point ............................7
76      4.8. Quadruple-Precision Floating-Point .........................8
77      4.9. Fixed-Length Opaque Data ...................................9
78      4.10. Variable-Length Opaque Data ...............................9
79      4.11. String ...................................................10
80      4.12. Fixed-Length Array .......................................11
81      4.13. Variable-Length Array ....................................11
82      4.14. Structure ................................................12
83      4.15. Discriminated Union ......................................12
84      4.16. Void .....................................................13
85      4.17. Constant .................................................13
86      4.18. Typedef ..................................................13
87      4.19. Optional-Data ............................................14
88      4.20. Areas for Future Enhancement .............................16
89   5. Discussion .....................................................16
90   6. The XDR Language Specification .................................17
91      6.1. Notational Conventions ....................................17
92      6.2. Lexical Notes .............................................18
93      6.3. Syntax Information ........................................18
94      6.4. Syntax Notes ..............................................20
95   7. An Example of an XDR Data Description ..........................21
96   8. Security Considerations ........................................22
97   9. IANA Considerations ............................................23
98   10. Trademarks and Owners .........................................23
99   11. ANSI/IEEE Standard 754-1985 ...................................24
100   12. Normative References ..........................................25
101   13. Informative References ........................................25
102   14. Acknowledgements ..............................................26
103
104
105
106
107
108
109
110
111
112
113
114Eisler                      Standards Track                     [Page 2]
115
116RFC 4506       XDR: External Data Representation Standard       May 2006
117
118
1191.  Introduction
120
121   XDR is a standard for the description and encoding of data.  It is
122   useful for transferring data between different computer
123   architectures, and it has been used to communicate data between such
124   diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
125   XDR fits into the ISO presentation layer and is roughly analogous in
126   purpose to X.409, ISO Abstract Syntax Notation.  The major difference
127   between these two is that XDR uses implicit typing, while X.409 uses
128   explicit typing.
129
130   XDR uses a language to describe data formats.  The language can be
131   used only to describe data; it is not a programming language.  This
132   language allows one to describe intricate data formats in a concise
133   manner.  The alternative of using graphical representations (itself
134   an informal language) quickly becomes incomprehensible when faced
135   with complexity.  The XDR language itself is similar to the C
136   language [KERN], just as Courier [COUR] is similar to Mesa.
137   Protocols such as ONC RPC (Remote Procedure Call) and the NFS*
138   (Network File System) use XDR to describe the format of their data.
139
140   The XDR standard makes the following assumption: that bytes (or
141   octets) are portable, where a byte is defined as 8 bits of data.  A
142   given hardware device should encode the bytes onto the various media
143   in such a way that other hardware devices may decode the bytes
144   without loss of meaning.  For example, the Ethernet* standard
145   suggests that bytes be encoded in "little-endian" style [COHE], or
146   least significant bit first.
147
1482.  Changes from RFC 1832
149
150   This document makes no technical changes to RFC 1832 and is published
151   for the purposes of noting IANA considerations, augmenting security
152   considerations, and distinguishing normative from informative
153   references.
154
1553.  Basic Block Size
156
157   The representation of all items requires a multiple of four bytes (or
158   32 bits) of data.  The bytes are numbered 0 through n-1.  The bytes
159   are read or written to some byte stream such that byte m always
160   precedes byte m+1.  If the n bytes needed to contain the data are not
161   a multiple of four, then the n bytes are followed by enough (0 to 3)
162   residual zero bytes, r, to make the total byte count a multiple of 4.
163
164   We include the familiar graphic box notation for illustration and
165   comparison.  In most illustrations, each box (delimited by a plus
166   sign at the 4 corners and vertical bars and dashes) depicts a byte.
167
168
169
170Eisler                      Standards Track                     [Page 3]
171
172RFC 4506       XDR: External Data Representation Standard       May 2006
173
174
175   Ellipses (...) between boxes show zero or more additional bytes where
176   required.
177
178        +--------+--------+...+--------+--------+...+--------+
179        | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |   BLOCK
180        +--------+--------+...+--------+--------+...+--------+
181        |<-----------n bytes---------->|<------r bytes------>|
182        |<-----------n+r (where (n+r) mod 4 = 0)>----------->|
183
1844.   XDR Data Types
185
186   Each of the sections that follow describes a data type defined in the
187   XDR standard, shows how it is declared in the language, and includes
188   a graphic illustration of its encoding.
189
190   For each data type in the language we show a general paradigm
191   declaration.  Note that angle brackets (< and >) denote variable-
192   length sequences of data and that square brackets ([ and ]) denote
193   fixed-length sequences of data.  "n", "m", and "r" denote integers.
194   For the full language specification and more formal definitions of
195   terms such as "identifier" and "declaration", refer to Section 6,
196   "The XDR Language Specification".
197
198   For some data types, more specific examples are included.  A more
199   extensive example of a data description is in Section 7, "An Example
200   of an XDR Data Description".
201
2024.1.  Integer
203
204   An XDR signed integer is a 32-bit datum that encodes an integer in
205   the range [-2147483648,2147483647].  The integer is represented in
206   two's complement notation.  The most and least significant bytes are
207   0 and 3, respectively.  Integers are declared as follows:
208
209         int identifier;
210
211           (MSB)                   (LSB)
212         +-------+-------+-------+-------+
213         |byte 0 |byte 1 |byte 2 |byte 3 |                      INTEGER
214         +-------+-------+-------+-------+
215         <------------32 bits------------>
216
2174.2.  Unsigned Integer
218
219   An XDR unsigned integer is a 32-bit datum that encodes a non-negative
220   integer in the range [0,4294967295].  It is represented by an
221   unsigned binary number whose most and least significant bytes are 0
222   and 3, respectively.  An unsigned integer is declared as follows:
223
224
225
226Eisler                      Standards Track                     [Page 4]
227
228RFC 4506       XDR: External Data Representation Standard       May 2006
229
230
231         unsigned int identifier;
232
233           (MSB)                   (LSB)
234            +-------+-------+-------+-------+
235            |byte 0 |byte 1 |byte 2 |byte 3 |           UNSIGNED INTEGER
236            +-------+-------+-------+-------+
237            <------------32 bits------------>
238
2394.3.  Enumeration
240
241   Enumerations have the same representation as signed integers.
242   Enumerations are handy for describing subsets of the integers.
243   Enumerated data is declared as follows:
244
245         enum { name-identifier = constant, ... } identifier;
246
247   For example, the three colors red, yellow, and blue could be
248   described by an enumerated type:
249
250         enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
251
252   It is an error to encode as an enum any integer other than those that
253   have been given assignments in the enum declaration.
254
2554.4.  Boolean
256
257   Booleans are important enough and occur frequently enough to warrant
258   their own explicit type in the standard.  Booleans are declared as
259   follows:
260
261         bool identifier;
262
263   This is equivalent to:
264
265         enum { FALSE = 0, TRUE = 1 } identifier;
266
2674.5.  Hyper Integer and Unsigned Hyper Integer
268
269   The standard also defines 64-bit (8-byte) numbers called hyper
270   integers and unsigned hyper integers.  Their representations are the
271   obvious extensions of integer and unsigned integer defined above.
272   They are represented in two's complement notation.  The most and
273   least significant bytes are 0 and 7, respectively.  Their
274   declarations:
275
276   hyper identifier; unsigned hyper identifier;
277
278
279
280
281
282Eisler                      Standards Track                     [Page 5]
283
284RFC 4506       XDR: External Data Representation Standard       May 2006
285
286
287        (MSB)                                                   (LSB)
288      +-------+-------+-------+-------+-------+-------+-------+-------+
289      |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
290      +-------+-------+-------+-------+-------+-------+-------+-------+
291      <----------------------------64 bits---------------------------->
292                                                 HYPER INTEGER
293                                                 UNSIGNED HYPER INTEGER
294
2954.6.  Floating-Point
296
297   The standard defines the floating-point data type "float" (32 bits or
298   4 bytes).  The encoding used is the IEEE standard for normalized
299   single-precision floating-point numbers [IEEE].  The following three
300   fields describe the single-precision floating-point number:
301
302      S: The sign of the number.  Values 0 and 1 represent positive and
303         negative, respectively.  One bit.
304
305      E: The exponent of the number, base 2.  8 bits are devoted to this
306         field.  The exponent is biased by 127.
307
308      F: The fractional part of the number's mantissa, base 2.  23 bits
309         are devoted to this field.
310
311   Therefore, the floating-point number is described by:
312
313         (-1)**S * 2**(E-Bias) * 1.F
314
315   It is declared as follows:
316
317         float identifier;
318
319         +-------+-------+-------+-------+
320         |byte 0 |byte 1 |byte 2 |byte 3 |              SINGLE-PRECISION
321         S|   E   |           F          |         FLOATING-POINT NUMBER
322         +-------+-------+-------+-------+
323         1|<- 8 ->|<-------23 bits------>|
324         <------------32 bits------------>
325
326   Just as the most and least significant bytes of a number are 0 and 3,
327   the most and least significant bits of a single-precision floating-
328   point number are 0 and 31.  The beginning bit (and most significant
329   bit) offsets of S, E, and F are 0, 1, and 9, respectively.  Note that
330   these numbers refer to the mathematical positions of the bits, and
331   NOT to their actual physical locations (which vary from medium to
332   medium).
333
334
335
336
337
338Eisler                      Standards Track                     [Page 6]
339
340RFC 4506       XDR: External Data Representation Standard       May 2006
341
342
343   The IEEE specifications should be consulted concerning the encoding
344   for signed zero, signed infinity (overflow), and denormalized numbers
345   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
346   a number) is system dependent and should not be interpreted within
347   XDR as anything other than "NaN".
348
3494.7.  Double-Precision Floating-Point
350
351   The standard defines the encoding for the double-precision floating-
352   point data type "double" (64 bits or 8 bytes).  The encoding used is
353   the IEEE standard for normalized double-precision floating-point
354   numbers [IEEE].  The standard encodes the following three fields,
355   which describe the double-precision floating-point number:
356
357      S: The sign of the number.  Values 0 and 1 represent positive and
358            negative, respectively.  One bit.
359
360      E: The exponent of the number, base 2.  11 bits are devoted to
361            this field.  The exponent is biased by 1023.
362
363      F: The fractional part of the number's mantissa, base 2.  52 bits
364            are devoted to this field.
365
366   Therefore, the floating-point number is described by:
367
368         (-1)**S * 2**(E-Bias) * 1.F
369
370   It is declared as follows:
371
372         double identifier;
373
374         +------+------+------+------+------+------+------+------+
375         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
376         S|    E   |                    F                        |
377         +------+------+------+------+------+------+------+------+
378         1|<--11-->|<-----------------52 bits------------------->|
379         <-----------------------64 bits------------------------->
380                                        DOUBLE-PRECISION FLOATING-POINT
381
382   Just as the most and least significant bytes of a number are 0 and 3,
383   the most and least significant bits of a double-precision floating-
384   point number are 0 and 63.  The beginning bit (and most significant
385   bit) offsets of S, E, and F are 0, 1, and 12, respectively.  Note
386   that these numbers refer to the mathematical positions of the bits,
387   and NOT to their actual physical locations (which vary from medium to
388   medium).
389
390
391
392
393
394Eisler                      Standards Track                     [Page 7]
395
396RFC 4506       XDR: External Data Representation Standard       May 2006
397
398
399   The IEEE specifications should be consulted concerning the encoding
400   for signed zero, signed infinity (overflow), and denormalized numbers
401   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
402   a number) is system dependent and should not be interpreted within
403   XDR as anything other than "NaN".
404
4054.8.  Quadruple-Precision Floating-Point
406
407   The standard defines the encoding for the quadruple-precision
408   floating-point data type "quadruple" (128 bits or 16 bytes).  The
409   encoding used is designed to be a simple analog of the encoding used
410   for single- and double-precision floating-point numbers using one
411   form of IEEE double extended precision.  The standard encodes the
412   following three fields, which describe the quadruple-precision
413   floating-point number:
414
415      S: The sign of the number.  Values 0 and 1 represent positive and
416         negative, respectively.  One bit.
417
418      E: The exponent of the number, base 2.  15 bits are devoted to
419         this field.  The exponent is biased by 16383.
420
421      F: The fractional part of the number's mantissa, base 2.  112 bits
422         are devoted to this field.
423
424   Therefore, the floating-point number is described by:
425
426         (-1)**S * 2**(E-Bias) * 1.F
427
428   It is declared as follows:
429
430         quadruple identifier;
431
432         +------+------+------+------+------+------+-...--+------+
433         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ...  |byte15|
434         S|    E       |                  F                      |
435         +------+------+------+------+------+------+-...--+------+
436         1|<----15---->|<-------------112 bits------------------>|
437         <-----------------------128 bits------------------------>
438                                      QUADRUPLE-PRECISION FLOATING-POINT
439
440   Just as the most and least significant bytes of a number are 0 and 3,
441   the most and least significant bits of a quadruple-precision
442   floating-point number are 0 and 127.  The beginning bit (and most
443   significant bit) offsets of S, E , and F are 0, 1, and 16,
444   respectively.  Note that these numbers refer to the mathematical
445   positions of the bits, and NOT to their actual physical locations
446   (which vary from medium to medium).
447
448
449
450Eisler                      Standards Track                     [Page 8]
451
452RFC 4506       XDR: External Data Representation Standard       May 2006
453
454
455   The encoding for signed zero, signed infinity (overflow), and
456   denormalized numbers are analogs of the corresponding encodings for
457   single and double-precision floating-point numbers [SPAR], [HPRE].
458   The "NaN" encoding as it applies to quadruple-precision floating-
459   point numbers is system dependent and should not be interpreted
460   within XDR as anything other than "NaN".
461
4624.9.  Fixed-Length Opaque Data
463
464   At times, fixed-length uninterpreted data needs to be passed among
465   machines.  This data is called "opaque" and is declared as follows:
466
467         opaque identifier[n];
468
469   where the constant n is the (static) number of bytes necessary to
470   contain the opaque data.  If n is not a multiple of four, then the n
471   bytes are followed by enough (0 to 3) residual zero bytes, r, to make
472   the total byte count of the opaque object a multiple of four.
473
474          0        1     ...
475      +--------+--------+...+--------+--------+...+--------+
476      | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |
477      +--------+--------+...+--------+--------+...+--------+
478      |<-----------n bytes---------->|<------r bytes------>|
479      |<-----------n+r (where (n+r) mod 4 = 0)------------>|
480                                                   FIXED-LENGTH OPAQUE
481
4824.10.  Variable-Length Opaque Data
483
484   The standard also provides for variable-length (counted) opaque data,
485   defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
486   to be the number n encoded as an unsigned integer (as described
487   below), and followed by the n bytes of the sequence.
488
489   Byte m of the sequence always precedes byte m+1 of the sequence, and
490   byte 0 of the sequence always follows the sequence's length (count).
491   If n is not a multiple of four, then the n bytes are followed by
492   enough (0 to 3) residual zero bytes, r, to make the total byte count
493   a multiple of four.  Variable-length opaque data is declared in the
494   following way:
495
496         opaque identifier<m>;
497      or
498         opaque identifier<>;
499
500   The constant m denotes an upper bound of the number of bytes that the
501   sequence may contain.  If m is not specified, as in the second
502   declaration, it is assumed to be (2**32) - 1, the maximum length.
503
504
505
506Eisler                      Standards Track                     [Page 9]
507
508RFC 4506       XDR: External Data Representation Standard       May 2006
509
510
511   The constant m would normally be found in a protocol specification.
512   For example, a filing protocol may state that the maximum data
513   transfer size is 8192 bytes, as follows:
514
515         opaque filedata<8192>;
516
517            0     1     2     3     4     5   ...
518         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
519         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
520         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
521         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
522                                 |<----n+r (where (n+r) mod 4 = 0)---->|
523                                                  VARIABLE-LENGTH OPAQUE
524
525   It is an error to encode a length greater than the maximum described
526   in the specification.
527
5284.11.  String
529
530   The standard defines a string of n (numbered 0 through n-1) ASCII
531   bytes to be the number n encoded as an unsigned integer (as described
532   above), and followed by the n bytes of the string.  Byte m of the
533   string always precedes byte m+1 of the string, and byte 0 of the
534   string always follows the string's length.  If n is not a multiple of
535   four, then the n bytes are followed by enough (0 to 3) residual zero
536   bytes, r, to make the total byte count a multiple of four.  Counted
537   byte strings are declared as follows:
538
539         string object<m>;
540      or
541         string object<>;
542
543   The constant m denotes an upper bound of the number of bytes that a
544   string may contain.  If m is not specified, as in the second
545   declaration, it is assumed to be (2**32) - 1, the maximum length.
546   The constant m would normally be found in a protocol specification.
547   For example, a filing protocol may state that a file name can be no
548   longer than 255 bytes, as follows:
549
550         string filename<255>;
551
552            0     1     2     3     4     5   ...
553         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
554         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
555         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
556         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
557                                 |<----n+r (where (n+r) mod 4 = 0)---->|
558                                                                  STRING
559
560
561
562Eisler                      Standards Track                    [Page 10]
563
564RFC 4506       XDR: External Data Representation Standard       May 2006
565
566
567   It is an error to encode a length greater than the maximum described
568   in the specification.
569
5704.12.  Fixed-Length Array
571
572   Declarations for fixed-length arrays of homogeneous elements are in
573   the following form:
574
575         type-name identifier[n];
576
577   Fixed-length arrays of elements numbered 0 through n-1 are encoded by
578   individually encoding the elements of the array in their natural
579   order, 0 through n-1.  Each element's size is a multiple of four
580   bytes.  Though all elements are of the same type, the elements may
581   have different sizes.  For example, in a fixed-length array of
582   strings, all elements are of type "string", yet each element will
583   vary in its length.
584
585         +---+---+---+---+---+---+---+---+...+---+---+---+---+
586         |   element 0   |   element 1   |...|  element n-1  |
587         +---+---+---+---+---+---+---+---+...+---+---+---+---+
588         |<--------------------n elements------------------->|
589
590                                               FIXED-LENGTH ARRAY
591
5924.13.  Variable-Length Array
593
594   Counted arrays provide the ability to encode variable-length arrays
595   of homogeneous elements.  The array is encoded as the element count n
596   (an unsigned integer) followed by the encoding of each of the array's
597   elements, starting with element 0 and progressing through element
598   n-1.  The declaration for variable-length arrays follows this form:
599
600         type-name identifier<m>;
601      or
602         type-name identifier<>;
603
604   The constant m specifies the maximum acceptable element count of an
605   array; if m is not specified, as in the second declaration, it is
606   assumed to be (2**32) - 1.
607
608           0  1  2  3
609         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
610         |     n     | element 0 | element 1 |...|element n-1|
611         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
612         |<-4 bytes->|<--------------n elements------------->|
613                                                         COUNTED ARRAY
614
615
616
617
618Eisler                      Standards Track                    [Page 11]
619
620RFC 4506       XDR: External Data Representation Standard       May 2006
621
622
623   It is an error to encode a value of n that is greater than the
624   maximum described in the specification.
625
6264.14.  Structure
627
628   Structures are declared as follows:
629
630         struct {
631            component-declaration-A;
632            component-declaration-B;
633            ...
634         } identifier;
635
636   The components of the structure are encoded in the order of their
637   declaration in the structure.  Each component's size is a multiple of
638   four bytes, though the components may be different sizes.
639
640         +-------------+-------------+...
641         | component A | component B |...                      STRUCTURE
642         +-------------+-------------+...
643
6444.15.  Discriminated Union
645
646   A discriminated union is a type composed of a discriminant followed
647   by a type selected from a set of prearranged types according to the
648   value of the discriminant.  The type of discriminant is either "int",
649   "unsigned int", or an enumerated type, such as "bool".  The component
650   types are called "arms" of the union and are preceded by the value of
651   the discriminant that implies their encoding.  Discriminated unions
652   are declared as follows:
653
654         union switch (discriminant-declaration) {
655         case discriminant-value-A:
656            arm-declaration-A;
657         case discriminant-value-B:
658            arm-declaration-B;
659         ...
660         default: default-declaration;
661         } identifier;
662
663   Each "case" keyword is followed by a legal value of the discriminant.
664   The default arm is optional.  If it is not specified, then a valid
665   encoding of the union cannot take on unspecified discriminant values.
666   The size of the implied arm is always a multiple of four bytes.
667
668   The discriminated union is encoded as its discriminant followed by
669   the encoding of the implied arm.
670
671
672
673
674Eisler                      Standards Track                    [Page 12]
675
676RFC 4506       XDR: External Data Representation Standard       May 2006
677
678
679           0   1   2   3
680         +---+---+---+---+---+---+---+---+
681         |  discriminant |  implied arm  |          DISCRIMINATED UNION
682         +---+---+---+---+---+---+---+---+
683         |<---4 bytes--->|
684
6854.16.  Void
686
687   An XDR void is a 0-byte quantity.  Voids are useful for describing
688   operations that take no data as input or no data as output.  They are
689   also useful in unions, where some arms may contain data and others do
690   not.  The declaration is simply as follows:
691
692         void;
693
694   Voids are illustrated as follows:
695
696           ++
697           ||                                                     VOID
698           ++
699         --><-- 0 bytes
700
7014.17.  Constant
702
703   The data declaration for a constant follows this form:
704
705         const name-identifier = n;
706
707   "const" is used to define a symbolic name for a constant; it does not
708   declare any data.  The symbolic constant may be used anywhere a
709   regular constant may be used.  For example, the following defines a
710   symbolic constant DOZEN, equal to 12.
711
712         const DOZEN = 12;
713
7144.18.  Typedef
715
716   "typedef" does not declare any data either, but serves to define new
717   identifiers for declaring data.  The syntax is:
718
719         typedef declaration;
720
721   The new type name is actually the variable name in the declaration
722   part of the typedef.  For example, the following defines a new type
723   called "eggbox" using an existing type called "egg":
724
725         typedef egg eggbox[DOZEN];
726
727
728
729
730Eisler                      Standards Track                    [Page 13]
731
732RFC 4506       XDR: External Data Representation Standard       May 2006
733
734
735   Variables declared using the new type name have the same type as the
736   new type name would have in the typedef, if it were considered a
737   variable.  For example, the following two declarations are equivalent
738   in declaring the variable "fresheggs":
739
740         eggbox  fresheggs; egg     fresheggs[DOZEN];
741
742   When a typedef involves a struct, enum, or union definition, there is
743   another (preferred) syntax that may be used to define the same type.
744   In general, a typedef of the following form:
745
746         typedef <<struct, union, or enum definition>> identifier;
747
748   may be converted to the alternative form by removing the "typedef"
749   part and placing the identifier after the "struct", "union", or
750   "enum" keyword, instead of at the end.  For example, here are the two
751   ways to define the type "bool":
752
753         typedef enum {    /* using typedef */
754            FALSE = 0,
755            TRUE = 1
756         } bool;
757
758         enum bool {       /* preferred alternative */
759            FALSE = 0,
760            TRUE = 1
761         };
762
763   This syntax is preferred because one does not have to wait until the
764   end of a declaration to figure out the name of the new type.
765
7664.19.  Optional-Data
767
768   Optional-data is one kind of union that occurs so frequently that we
769   give it a special syntax of its own for declaring it.  It is declared
770   as follows:
771
772         type-name *identifier;
773
774   This is equivalent to the following union:
775
776         union switch (bool opted) {
777         case TRUE:
778            type-name element;
779         case FALSE:
780            void;
781         } identifier;
782
783
784
785
786Eisler                      Standards Track                    [Page 14]
787
788RFC 4506       XDR: External Data Representation Standard       May 2006
789
790
791   It is also equivalent to the following variable-length array
792   declaration, since the boolean "opted" can be interpreted as the
793   length of the array:
794
795         type-name identifier<1>;
796
797   Optional-data is not so interesting in itself, but it is very useful
798   for describing recursive data-structures such as linked-lists and
799   trees.  For example, the following defines a type "stringlist" that
800   encodes lists of zero or more arbitrary length strings:
801
802        struct stringentry {
803           string item<>;
804           stringentry *next;
805        };
806
807        typedef stringentry *stringlist;
808
809   It could have been equivalently declared as the following union:
810
811         union stringlist switch (bool opted) {
812         case TRUE:
813            struct {
814               string item<>;
815               stringlist next;
816            } element;
817         case FALSE:
818            void;
819         };
820
821   or as a variable-length array:
822
823        struct stringentry {
824           string item<>;
825           stringentry next<1>;
826        };
827
828        typedef stringentry stringlist<1>;
829
830   Both of these declarations obscure the intention of the stringlist
831   type, so the optional-data declaration is preferred over both of
832   them.  The optional-data type also has a close correlation to how
833   recursive data structures are represented in high-level languages
834   such as Pascal or C by use of pointers.  In fact, the syntax is the
835   same as that of the C language for pointers.
836
837
838
839
840
841
842Eisler                      Standards Track                    [Page 15]
843
844RFC 4506       XDR: External Data Representation Standard       May 2006
845
846
8474.20.  Areas for Future Enhancement
848
849   The XDR standard lacks representations for bit fields and bitmaps,
850   since the standard is based on bytes.  Also missing are packed (or
851   binary-coded) decimals.
852
853   The intent of the XDR standard was not to describe every kind of data
854   that people have ever sent or will ever want to send from machine to
855   machine.  Rather, it only describes the most commonly used data-types
856   of high-level languages such as Pascal or C so that applications
857   written in these languages will be able to communicate easily over
858   some medium.
859
860   One could imagine extensions to XDR that would let it describe almost
861   any existing protocol, such as TCP.  The minimum necessary for this
862   is support for different block sizes and byte-orders.  The XDR
863   discussed here could then be considered the 4-byte big-endian member
864   of a larger XDR family.
865
8665.  Discussion
867
868   (1) Why use a language for describing data?  What's wrong with
869       diagrams?
870
871   There are many advantages in using a data-description language such
872   as XDR versus using diagrams.  Languages are more formal than
873   diagrams and lead to less ambiguous descriptions of data.  Languages
874   are also easier to understand and allow one to think of other issues
875   instead of the low-level details of bit encoding.  Also, there is a
876   close analogy between the types of XDR and a high-level language such
877   as C or Pascal.  This makes the implementation of XDR encoding and
878   decoding modules an easier task.  Finally, the language specification
879   itself is an ASCII string that can be passed from machine to machine
880   to perform on-the-fly data interpretation.
881
882   (2) Why is there only one byte-order for an XDR unit?
883
884   Supporting two byte-orderings requires a higher-level protocol for
885   determining in which byte-order the data is encoded.  Since XDR is
886   not a protocol, this can't be done.  The advantage of this, though,
887   is that data in XDR format can be written to a magnetic tape, for
888   example, and any machine will be able to interpret it, since no
889   higher-level protocol is necessary for determining the byte-order.
890
891   (3) Why is the XDR byte-order big-endian instead of little-endian?
892       Isn't this unfair to little-endian machines such as the VAX(r),
893       which has to convert from one form to the other?
894
895
896
897
898Eisler                      Standards Track                    [Page 16]
899
900RFC 4506       XDR: External Data Representation Standard       May 2006
901
902
903   Yes, it is unfair, but having only one byte-order means you have to
904   be unfair to somebody.  Many architectures, such as the Motorola
905   68000* and IBM 370*, support the big-endian byte-order.
906
907   (4) Why is the XDR unit four bytes wide?
908
909   There is a tradeoff in choosing the XDR unit size.  Choosing a small
910   size, such as two, makes the encoded data small, but causes alignment
911   problems for machines that aren't aligned on these boundaries.  A
912   large size, such as eight, means the data will be aligned on
913   virtually every machine, but causes the encoded data to grow too big.
914   We chose four as a compromise.  Four is big enough to support most
915   architectures efficiently, except for rare machines such as the
916   eight-byte-aligned Cray*.  Four is also small enough to keep the
917   encoded data restricted to a reasonable size.
918
919   (5) Why must variable-length data be padded with zeros?
920
921   It is desirable that the same data encode into the same thing on all
922   machines, so that encoded data can be meaningfully compared or
923   checksummed.  Forcing the padded bytes to be zero ensures this.
924
925   (6) Why is there no explicit data-typing?
926
927   Data-typing has a relatively high cost for what small advantages it
928   may have.  One cost is the expansion of data due to the inserted type
929   fields.  Another is the added cost of interpreting these type fields
930   and acting accordingly.  And most protocols already know what type
931   they expect, so data-typing supplies only redundant information.
932   However, one can still get the benefits of data-typing using XDR.
933   One way is to encode two things: first, a string that is the XDR data
934   description of the encoded data, and then the encoded data itself.
935   Another way is to assign a value to all the types in XDR, and then
936   define a universal type that takes this value as its discriminant and
937   for each value, describes the corresponding data type.
938
9396.  The XDR Language Specification
940
9416.1.  Notational Conventions
942
943   This specification uses an extended Back-Naur Form notation for
944   describing the XDR language.  Here is a brief description of the
945   notation:
946
947   (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special.
948   (2) Terminal symbols are strings of any characters surrounded by
949   double quotes.  (3) Non-terminal symbols are strings of non-special
950   characters.  (4) Alternative items are separated by a vertical bar
951
952
953
954Eisler                      Standards Track                    [Page 17]
955
956RFC 4506       XDR: External Data Representation Standard       May 2006
957
958
959   ("|").  (5) Optional items are enclosed in brackets.  (6) Items are
960   grouped together by enclosing them in parentheses.  (7) A '*'
961   following an item means 0 or more occurrences of that item.
962
963   For example, consider the following pattern:
964
965         "a " "very" (", " "very")* [" cold " "and "]  " rainy "
966         ("day" | "night")
967
968   An infinite number of strings match this pattern.  A few of them are:
969
970         "a very rainy day"
971         "a very, very rainy day"
972         "a very cold and  rainy day"
973         "a very, very, very cold and  rainy night"
974
9756.2.  Lexical Notes
976
977   (1) Comments begin with '/*' and terminate with '*/'.  (2) White
978   space serves to separate items and is otherwise ignored.  (3) An
979   identifier is a letter followed by an optional sequence of letters,
980   digits, or underbar ('_').  The case of identifiers is not ignored.
981   (4) A decimal constant expresses a number in base 10 and is a
982   sequence of one or more decimal digits, where the first digit is not
983   a zero, and is optionally preceded by a minus-sign ('-').  (5) A
984   hexadecimal constant expresses a number in base 16, and must be
985   preceded by '0x', followed by one or hexadecimal digits ('A', 'B',
986   'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3',
987   '4', '5', '6', '7', '8', '9').  (6) An octal constant expresses a
988   number in base 8, always leads with digit 0, and is a sequence of one
989   or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7').
990
9916.3.  Syntax Information
992
993      declaration:
994           type-specifier identifier
995         | type-specifier identifier "[" value "]"
996         | type-specifier identifier "<" [ value ] ">"
997         | "opaque" identifier "[" value "]"
998         | "opaque" identifier "<" [ value ] ">"
999         | "string" identifier "<" [ value ] ">"
1000         | type-specifier "*" identifier
1001         | "void"
1002
1003      value:
1004           constant
1005         | identifier
1006
1007
1008
1009
1010Eisler                      Standards Track                    [Page 18]
1011
1012RFC 4506       XDR: External Data Representation Standard       May 2006
1013
1014
1015      constant:
1016         decimal-constant | hexadecimal-constant | octal-constant
1017
1018      type-specifier:
1019           [ "unsigned" ] "int"
1020         | [ "unsigned" ] "hyper"
1021         | "float"
1022         | "double"
1023         | "quadruple"
1024         | "bool"
1025         | enum-type-spec
1026         | struct-type-spec
1027         | union-type-spec
1028         | identifier
1029
1030      enum-type-spec:
1031         "enum" enum-body
1032
1033      enum-body:
1034         "{"
1035            ( identifier "=" value )
1036            ( "," identifier "=" value )*
1037         "}"
1038
1039      struct-type-spec:
1040         "struct" struct-body
1041
1042      struct-body:
1043         "{"
1044            ( declaration ";" )
1045            ( declaration ";" )*
1046         "}"
1047
1048      union-type-spec:
1049         "union" union-body
1050
1051      union-body:
1052         "switch" "(" declaration ")" "{"
1053            case-spec
1054            case-spec *
1055            [ "default" ":" declaration ";" ]
1056         "}"
1057
1058      case-spec:
1059        ( "case" value ":")
1060        ( "case" value ":") *
1061        declaration ";"
1062
1063
1064
1065
1066Eisler                      Standards Track                    [Page 19]
1067
1068RFC 4506       XDR: External Data Representation Standard       May 2006
1069
1070
1071      constant-def:
1072         "const" identifier "=" constant ";"
1073
1074      type-def:
1075           "typedef" declaration ";"
1076         | "enum" identifier enum-body ";"
1077         | "struct" identifier struct-body ";"
1078         | "union" identifier union-body ";"
1079
1080      definition:
1081           type-def
1082         | constant-def
1083
1084      specification:
1085           definition *
1086
10876.4.  Syntax Notes
1088
1089   (1) The following are keywords and cannot be used as identifiers:
1090   "bool", "case", "const", "default", "double", "quadruple", "enum",
1091   "float", "hyper", "int", "opaque", "string", "struct", "switch",
1092   "typedef", "union", "unsigned", and "void".
1093
1094   (2) Only unsigned constants may be used as size specifications for
1095   arrays.  If an identifier is used, it must have been declared
1096   previously as an unsigned constant in a "const" definition.
1097
1098   (3) Constant and type identifiers within the scope of a specification
1099   are in the same name space and must be declared uniquely within this
1100   scope.
1101
1102   (4) Similarly, variable names must be unique within the scope of
1103   struct and union declarations.  Nested struct and union declarations
1104   create new scopes.
1105
1106   (5) The discriminant of a union must be of a type that evaluates to
1107   an integer.  That is, "int", "unsigned int", "bool", an enumerated
1108   type, or any typedefed type that evaluates to one of these is legal.
1109   Also, the case values must be one of the legal values of the
1110   discriminant.  Finally, a case value may not be specified more than
1111   once within the scope of a union declaration.
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122Eisler                      Standards Track                    [Page 20]
1123
1124RFC 4506       XDR: External Data Representation Standard       May 2006
1125
1126
11277.  An Example of an XDR Data Description
1128
1129   Here is a short XDR data description of a thing called a "file",
1130   which might be used to transfer files from one machine to another.
1131
1132         const MAXUSERNAME = 32;     /* max length of a user name */
1133         const MAXFILELEN = 65535;   /* max length of a file      */
1134         const MAXNAMELEN = 255;     /* max length of a file name */
1135
1136         /*
1137          * Types of files:
1138          */
1139         enum filekind {
1140            TEXT = 0,       /* ascii data */
1141            DATA = 1,       /* raw data   */
1142            EXEC = 2        /* executable */
1143         };
1144
1145         /*
1146          * File information, per kind of file:
1147          */
1148         union filetype switch (filekind kind) {
1149         case TEXT:
1150            void;                           /* no extra information */
1151         case DATA:
1152            string creator<MAXNAMELEN>;     /* data creator         */
1153         case EXEC:
1154            string interpretor<MAXNAMELEN>; /* program interpretor  */
1155         };
1156
1157         /*
1158          * A complete file:
1159          */
1160         struct file {
1161            string filename<MAXNAMELEN>; /* name of file    */
1162            filetype type;               /* info about file */
1163            string owner<MAXUSERNAME>;   /* owner of file   */
1164            opaque data<MAXFILELEN>;     /* file data       */
1165         };
1166
1167   Suppose now that there is a user named "john" who wants to store his
1168   lisp program "sillyprog" that contains just the data "(quit)".  His
1169   file would be encoded as follows:
1170
1171
1172
1173
1174
1175
1176
1177
1178Eisler                      Standards Track                    [Page 21]
1179
1180RFC 4506       XDR: External Data Representation Standard       May 2006
1181
1182
1183       OFFSET  HEX BYTES       ASCII    COMMENTS
1184       ------  ---------       -----    --------
1185        0      00 00 00 09     ....     -- length of filename = 9
1186        4      73 69 6c 6c     sill     -- filename characters
1187        8      79 70 72 6f     ypro     -- ... and more characters ...
1188       12      67 00 00 00     g...     -- ... and 3 zero-bytes of fill
1189       16      00 00 00 02     ....     -- filekind is EXEC = 2
1190       20      00 00 00 04     ....     -- length of interpretor = 4
1191       24      6c 69 73 70     lisp     -- interpretor characters
1192       28      00 00 00 04     ....     -- length of owner = 4
1193       32      6a 6f 68 6e     john     -- owner characters
1194       36      00 00 00 06     ....     -- length of file data = 6
1195       40      28 71 75 69     (qui     -- file data bytes ...
1196       44      74 29 00 00     t)..     -- ... and 2 zero-bytes of fill
1197
11988.  Security Considerations
1199
1200   XDR is a data description language, not a protocol, and hence it does
1201   not inherently give rise to any particular security considerations.
1202   Protocols that carry XDR-formatted data, such as NFSv4, are
1203   responsible for providing any necessary security services to secure
1204   the data they transport.
1205
1206   Care must be take to properly encode and decode data to avoid
1207   attacks.  Known and avoidable risks include:
1208
1209   *    Buffer overflow attacks.  Where feasible, protocols should be
1210        defined with explicit limits (via the "<" [ value ] ">" notation
1211        instead of "<" ">") on elements with variable-length data types.
1212        Regardless of the feasibility of an explicit limit on the
1213        variable length of an element of a given protocol, decoders need
1214        to ensure the incoming size does not exceed the length of any
1215        provisioned receiver buffers.
1216
1217   *    Nul octets embedded in an encoded value of type string.  If the
1218        decoder's native string format uses nul-terminated strings, then
1219        the apparent size of the decoded object will be less than the
1220        amount of memory allocated for the string.  Some memory
1221        deallocation interfaces take a size argument.  The caller of the
1222        deallocation interface would likely determine the size of the
1223        string by counting to the location of the nul octet and adding
1224        one.  This discrepancy can cause memory leakage (because less
1225        memory is actually returned to the free pool than allocated),
1226        leading to system failure and a denial of service attack.
1227
1228   *    Decoding of characters in strings that are legal ASCII
1229        characters but nonetheless are illegal for the intended
1230        application.  For example, some operating systems treat the '/'
1231
1232
1233
1234Eisler                      Standards Track                    [Page 22]
1235
1236RFC 4506       XDR: External Data Representation Standard       May 2006
1237
1238
1239        character as a component separator in path names.  For a
1240        protocol that encodes a string in the argument to a file
1241        creation operation, the decoder needs to ensure that '/' is not
1242        inside the component name.  Otherwise, a file with an illegal
1243        '/' in its name will be created, making it difficult to remove,
1244        and is therefore a denial of service attack.
1245
1246   *    Denial of service caused by recursive decoder or encoder
1247        subroutines.  A recursive decoder or encoder might process data
1248        that has a structured type with a member of type optional data
1249        that directly or indirectly refers to the structured type (i.e.,
1250        a linked list).  For example,
1251
1252              struct m {
1253                int x;
1254                struct m *next;
1255              };
1256
1257        An encoder or decoder subroutine might be written to recursively
1258        call itself each time another element of type "struct m" is
1259        found.  An attacker could construct a long linked list of
1260        "struct m" elements in the request or response, which then
1261        causes a stack overflow on the decoder or encoder.  Decoders and
1262        encoders should be written non-recursively or impose a limit on
1263        list length.
1264
12659.  IANA Considerations
1266
1267   It is possible, if not likely, that new data types will be added to
1268   XDR in the future.  The process for adding new types is via a
1269   standards track RFC and not registration of new types with IANA.
1270   Standards track RFCs that update or replace this document should be
1271   documented as such in the RFC Editor's database of RFCs.
1272
127310.  Trademarks and Owners
1274
1275   SUN WORKSTATION  Sun Microsystems, Inc.
1276   VAX              Hewlett-Packard Company
1277   IBM-PC           International Business Machines Corporation
1278   Cray             Cray Inc.
1279   NFS              Sun Microsystems, Inc.
1280   Ethernet         Xerox Corporation.
1281   Motorola 68000   Motorola, Inc.
1282   IBM 370          International Business Machines Corporation
1283
1284
1285
1286
1287
1288
1289
1290Eisler                      Standards Track                    [Page 23]
1291
1292RFC 4506       XDR: External Data Representation Standard       May 2006
1293
1294
129511.  ANSI/IEEE Standard 754-1985
1296
1297   The definition of NaNs, signed zero and infinity, and denormalized
1298   numbers from [IEEE] is reproduced here for convenience.  The
1299   definitions for quadruple-precision floating point numbers are
1300   analogs of those for single and double-precision floating point
1301   numbers and are defined in [IEEE].
1302
1303   In the following, 'S' stands for the sign bit, 'E' for the exponent,
1304   and 'F' for the fractional part.  The symbol 'u' stands for an
1305   undefined bit (0 or 1).
1306
1307   For single-precision floating point numbers:
1308
1309    Type                  S (1 bit)   E (8 bits)    F (23 bits)
1310    ----                  ---------   ----------    -----------
1311    signalling NaN        u           255 (max)     .0uuuuu---u
1312                                                    (with at least
1313                                                     one 1 bit)
1314    quiet NaN             u           255 (max)     .1uuuuu---u
1315
1316    negative infinity     1           255 (max)     .000000---0
1317
1318    positive infinity     0           255 (max)     .000000---0
1319
1320    negative zero         1           0             .000000---0
1321
1322    positive zero         0           0             .000000---0
1323
1324   For double-precision floating point numbers:
1325
1326    Type                  S (1 bit)   E (11 bits)   F (52 bits)
1327    ----                  ---------   -----------   -----------
1328    signalling NaN        u           2047 (max)    .0uuuuu---u
1329                                                    (with at least
1330                                                     one 1 bit)
1331    quiet NaN             u           2047 (max)    .1uuuuu---u
1332
1333    negative infinity     1           2047 (max)    .000000---0
1334
1335    positive infinity     0           2047 (max)    .000000---0
1336
1337    negative zero         1           0             .000000---0
1338
1339    positive zero         0           0             .000000---0
1340
1341
1342
1343
1344
1345
1346Eisler                      Standards Track                    [Page 24]
1347
1348RFC 4506       XDR: External Data Representation Standard       May 2006
1349
1350
1351   For quadruple-precision floating point numbers:
1352
1353    Type                  S (1 bit)   E (15 bits)   F (112 bits)
1354    ----                  ---------   -----------   ------------
1355    signalling NaN        u           32767 (max)   .0uuuuu---u
1356                                                    (with at least
1357                                                     one 1 bit)
1358    quiet NaN             u           32767 (max)   .1uuuuu---u
1359
1360    negative infinity     1           32767 (max)   .000000---0
1361
1362    positive infinity     0           32767 (max)   .000000---0
1363
1364    negative zero         1           0             .000000---0
1365
1366    positive zero         0           0             .000000---0
1367
1368   Subnormal numbers are represented as follows:
1369
1370    Precision            Exponent       Value
1371    ---------            --------       -----
1372    Single               0              (-1)**S * 2**(-126) * 0.F
1373
1374    Double               0              (-1)**S * 2**(-1022) * 0.F
1375
1376    Quadruple            0              (-1)**S * 2**(-16382) * 0.F
1377
137812.  Normative References
1379
1380   [IEEE]  "IEEE Standard for Binary Floating-Point Arithmetic",
1381           ANSI/IEEE Standard 754-1985, Institute of Electrical and
1382           Electronics Engineers, August 1985.
1383
138413.  Informative References
1385
1386   [KERN]  Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
1387           Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
1388
1389   [COHE]  Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE
1390           Computer, October 1981.
1391
1392   [COUR]  "Courier: The Remote Procedure Call Protocol", XEROX
1393           Corporation, XSIS 038112, December 1981.
1394
1395   [SPAR]  "The SPARC Architecture Manual: Version 8", Prentice Hall,
1396           ISBN 0-13-825001-4.
1397
1398   [HPRE]  "HP Precision Architecture Handbook", June 1987, 5954-9906.
1399
1400
1401
1402Eisler                      Standards Track                    [Page 25]
1403
1404RFC 4506       XDR: External Data Representation Standard       May 2006
1405
1406
140714.  Acknowledgements
1408
1409   Bob Lyon was Sun's visible force behind ONC RPC in the 1980s.  Sun
1410   Microsystems, Inc., is listed as the author of RFC 1014.  Raj
1411   Srinivasan and the rest of the old ONC RPC working group edited RFC
1412   1014 into RFC 1832, from which this document is derived.  Mike Eisler
1413   and Bill Janssen submitted the implementation reports for this
1414   standard.  Kevin Coffman, Benny Halevy, and Jon Peterson reviewed
1415   this document and gave feedback.  Peter Astrand and Bryan Olson
1416   pointed out several errors in RFC 1832 which are corrected in this
1417   document.
1418
1419Editor's Address
1420
1421   Mike Eisler
1422   5765 Chase Point Circle
1423   Colorado Springs, CO 80919
1424   USA
1425
1426   Phone: 719-599-9026
1427   EMail: email2mre-rfc4506@yahoo.com
1428
1429   Please address comments to: nfsv4@ietf.org
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458Eisler                      Standards Track                    [Page 26]
1459
1460RFC 4506       XDR: External Data Representation Standard       May 2006
1461
1462
1463Full Copyright Statement
1464
1465   Copyright (C) The Internet Society (2006).
1466
1467   This document is subject to the rights, licenses and restrictions
1468   contained in BCP 78, and except as set forth therein, the authors
1469   retain all their rights.
1470
1471   This document and the information contained herein are provided on an
1472   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1473   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1474   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1475   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1476   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1477   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1478
1479Intellectual Property
1480
1481   The IETF takes no position regarding the validity or scope of any
1482   Intellectual Property Rights or other rights that might be claimed to
1483   pertain to the implementation or use of the technology described in
1484   this document or the extent to which any license under such rights
1485   might or might not be available; nor does it represent that it has
1486   made any independent effort to identify any such rights.  Information
1487   on the procedures with respect to rights in RFC documents can be
1488   found in BCP 78 and BCP 79.
1489
1490   Copies of IPR disclosures made to the IETF Secretariat and any
1491   assurances of licenses to be made available, or the result of an
1492   attempt made to obtain a general license or permission for the use of
1493   such proprietary rights by implementers or users of this
1494   specification can be obtained from the IETF on-line IPR repository at
1495   http://www.ietf.org/ipr.
1496
1497   The IETF invites any interested party to bring to its attention any
1498   copyrights, patents or patent applications, or other proprietary
1499   rights that may cover technology that may be required to implement
1500   this standard.  Please address the information to the IETF at
1501   ietf-ipr@ietf.org.
1502
1503Acknowledgement
1504
1505   Funding for the RFC Editor function is provided by the IETF
1506   Administrative Support Activity (IASA).
1507
1508
1509
1510
1511
1512
1513
1514Eisler                      Standards Track                    [Page 27]
1515