idnits 2.17.1 draft-ietf-nfsv4-rfc1832bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1225. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 613 has weird spacing: '... eggbox fresh...' == Line 803 has weird spacing: '...onsider the ...' == Line 812 has weird spacing: '...old and rainy...' == Line 813 has weird spacing: '...old and rainy...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6919 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '-2147483648' is mentioned on line 158, but not defined -- Looks like a reference, but probably isn't: '2147483647' on line 158 -- Looks like a reference, but probably isn't: '0' on line 173 -- Looks like a reference, but probably isn't: '4294967295' on line 173 == Missing Reference: 'DOZEN' is mentioned on line 613, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Eisler 2 Internet-Draft Editor 3 Document: draft-ietf-nfsv4-rfc1832bis-06.txt Network Appliance, Inc. 4 May 2005 6 XDR: External Data Representation Standard 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 ABSTRACT 33 This document describes the External Data Representation Standard 34 (XDR) protocol as it is currently deployed and accepted. 36 TABLE OF CONTENTS 38 1. Changes from RFC1832 . . . . . . . . . . . . . . . . . . . . . 2 39 2. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 3. BASIC BLOCK SIZE . . . . . . . . . . . . . . . . . . . . . . . 3 41 4. XDR DATA TYPES . . . . . . . . . . . . . . . . . . . . . . . . 3 42 4.1. Integer . . . . . . . . . . . . . . . . . . . . . . . . . . 4 43 4.2. Unsigned Integer . . . . . . . . . . . . . . . . . . . . . . 4 44 4.3. Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 4 45 4.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 5 46 4.5. Hyper Integer and Unsigned Hyper Integer . . . . . . . . . . 5 47 4.6. Floating-point . . . . . . . . . . . . . . . . . . . . . . . 5 48 4.7. Double-precision Floating-point . . . . . . . . . . . . . . 6 49 4.8. Quadruple-precision Floating-point . . . . . . . . . . . . . 7 50 4.9. Fixed-length Opaque Data . . . . . . . . . . . . . . . . . . 8 51 4.10. Variable-length Opaque Data . . . . . . . . . . . . . . . . 9 52 4.11. String . . . . . . . . . . . . . . . . . . . . . . . . . 10 53 4.12. Fixed-length Array . . . . . . . . . . . . . . . . . . . 10 54 4.13. Variable-length Array . . . . . . . . . . . . . . . . . . 11 55 4.14. Structure . . . . . . . . . . . . . . . . . . . . . . . . 11 56 4.15. Discriminated Union . . . . . . . . . . . . . . . . . . . 12 57 4.16. Void . . . . . . . . . . . . . . . . . . . . . . . . . . 12 58 4.17. Constant . . . . . . . . . . . . . . . . . . . . . . . . 13 59 4.18. Typedef . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 4.19. Optional-data . . . . . . . . . . . . . . . . . . . . . . 14 61 4.20. Areas for Future Enhancement . . . . . . . . . . . . . . 15 62 5. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 6. THE XDR LANGUAGE SPECIFICATION . . . . . . . . . . . . . . . 17 64 6.1. Notational Conventions . . . . . . . . . . . . . . . . . . 17 65 6.2. Lexical Notes . . . . . . . . . . . . . . . . . . . . . . 18 66 6.3. Syntax Information . . . . . . . . . . . . . . . . . . . . 18 67 6.4. Syntax Notes . . . . . . . . . . . . . . . . . . . . . . . 20 68 7. AN EXAMPLE OF AN XDR DATA DESCRIPTION . . . . . . . . . . . 20 69 8. Security Considerations . . . . . . . . . . . . . . . . . . 21 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 71 10. TRADEMARKS AND OWNERS . . . . . . . . . . . . . . . . . . . 23 72 11. ANSI/IEEE Standard 754-1985 . . . . . . . . . . . . . . . . 23 73 12. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 25 74 13. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . 25 75 14. Editor's Address . . . . . . . . . . . . . . . . . . . . . 25 76 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 25 77 16. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 26 78 17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 26 80 1. Changes from RFC1832 82 This document makes no technical changes to RFC1832 and is published 83 for the purpose of noting IANA considerations, augmenting security 84 considerations, and distinguishing normative from informative 85 references. 87 2. INTRODUCTION 89 XDR is a standard for the description and encoding of data. It is 90 useful for transferring data between different computer 91 architectures, and has been used to communicate data between such 92 diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*. 93 XDR fits into the ISO presentation layer, and is roughly analogous in 94 purpose to X.409, ISO Abstract Syntax Notation. The major difference 95 between these two is that XDR uses implicit typing, while X.409 uses 96 explicit typing. 98 XDR uses a language to describe data formats. The language can only 99 be used only to describe data; it is not a programming language. 100 This language allows one to describe intricate data formats in a 101 concise manner. The alternative of using graphical representations 102 (itself an informal language) quickly becomes incomprehensible when 103 faced with complexity. The XDR language itself is similar to the C 104 language [KERN], just as Courier [COUR] is similar to Mesa. Protocols 105 such as ONC RPC (Remote Procedure Call) and the NFS* (Network File 106 System) use XDR to describe the format of their data. 108 The XDR standard makes the following assumption: that bytes (or 109 octets) are portable, where a byte is defined to be 8 bits of data. 110 A given hardware device should encode the bytes onto the various 111 media in such a way that other hardware devices may decode the bytes 112 without loss of meaning. For example, the Ethernet* standard 113 suggests that bytes be encoded in "little-endian" style [COHE], or 114 least significant bit first. 116 3. BASIC BLOCK SIZE 118 The representation of all items requires a multiple of four bytes (or 119 32 bits) of data. The bytes are numbered 0 through n-1. The bytes 120 are read or written to some byte stream such that byte m always 121 precedes byte m+1. If the n bytes needed to contain the data are not 122 a multiple of four, then the n bytes are followed by enough (0 to 3) 123 residual zero bytes, r, to make the total byte count a multiple of 4. 125 We include the familiar graphic box notation for illustration and 126 comparison. In most illustrations, each box (delimited by a plus 127 sign at the 4 corners and vertical bars and dashes) depicts a byte. 128 Ellipses (...) between boxes show zero or more additional bytes where 129 required. 131 +--------+--------+...+--------+--------+...+--------+ 132 | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | BLOCK 133 +--------+--------+...+--------+--------+...+--------+ 134 |<-----------n bytes---------->|<------r bytes------>| 135 |<-----------n+r (where (n+r) mod 4 = 0)>----------->| 137 4. XDR DATA TYPES 139 Each of the sections that follow describes a data type defined in the 140 XDR standard, shows how it is declared in the language, and includes 141 a graphic illustration of its encoding. 143 For each data type in the language we show a general paradigm 144 declaration. Note that angle brackets (< and >) denote 145 variable length sequences of data and square brackets ([ and ]) 146 denote fixed-length sequences of data. "n", "m" and "r" denote 147 integers. For the full language specification and more formal 148 definitions of terms such as "identifier" and "declaration", refer 149 to section 6: "The XDR Language Specification". 151 For some data types, more specific examples are included. A more 152 extensive example of a data description is in section 7: "An Example 153 of an XDR Data Description". 155 4.1. Integer 157 An XDR signed integer is a 32-bit datum that encodes an integer in 158 the range [-2147483648,2147483647]. The integer is represented in 159 two's complement notation. The most and least significant bytes are 160 0 and 3, respectively. Integers are declared as follows: 162 int identifier; 164 (MSB) (LSB) 165 +-------+-------+-------+-------+ 166 |byte 0 |byte 1 |byte 2 |byte 3 | INTEGER 167 +-------+-------+-------+-------+ 168 <------------32 bits------------> 170 4.2. Unsigned Integer 172 An XDR unsigned integer is a 32-bit datum that encodes a nonnegative 173 integer in the range [0,4294967295]. It is represented by an 174 unsigned binary number whose most and least significant bytes are 0 175 and 3, respectively. An unsigned integer is declared as follows: 177 unsigned int identifier; 179 (MSB) (LSB) 180 +-------+-------+-------+-------+ 181 |byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED INTEGER 182 +-------+-------+-------+-------+ 183 <------------32 bits------------> 185 4.3. Enumeration 187 Enumerations have the same representation as signed integers. 188 Enumerations are handy for describing subsets of the integers. 189 Enumerated data is declared as follows: 191 enum { name-identifier = constant, ... } identifier; 193 For example, the three colors red, yellow, and blue could be 194 described by an enumerated type: 196 enum { RED = 2, YELLOW = 3, BLUE = 5 } colors; 198 It is an error to encode as an enum any other integer than those that 199 have been given assignments in the enum declaration. 201 4.4. Boolean 203 Booleans are important enough and occur frequently enough to warrant 204 their own explicit type in the standard. Booleans are declared as 205 follows: 207 bool identifier; 209 This is equivalent to: 211 enum { FALSE = 0, TRUE = 1 } identifier; 213 4.5. Hyper Integer and Unsigned Hyper Integer 215 The standard also defines 64-bit (8-byte) numbers called hyper 216 integer and unsigned hyper integer. Their representations are the 217 obvious extensions of integer and unsigned integer defined above. 218 They are represented in two's complement notation. The most and 219 least significant bytes are 0 and 7, respectively. Their 220 declarations: 222 hyper identifier; unsigned hyper identifier; 224 (MSB) (LSB) 225 +-------+-------+-------+-------+-------+-------+-------+-------+ 226 |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 | 227 +-------+-------+-------+-------+-------+-------+-------+-------+ 228 <----------------------------64 bits----------------------------> 229 HYPER INTEGER 230 UNSIGNED HYPER INTEGER 232 4.6. Floating-point 234 The standard defines the floating-point data type "float" (32 bits or 235 4 bytes). The encoding used is the IEEE standard for normalized 236 single-precision floating-point numbers [IEEE]. The following three 237 fields describe the single-precision floating-point number: 239 S: The sign of the number. Values 0 and 1 represent positive and 240 negative, respectively. One bit. 242 E: The exponent of the number, base 2. 8 bits are devoted to this 243 field. The exponent is biased by 127. 245 F: The fractional part of the number's mantissa, base 2. 23 bits 246 are devoted to this field. 248 Therefore, the floating-point number is described by: 250 (-1)**S * 2**(E-Bias) * 1.F 252 It is declared as follows: 254 float identifier; 256 +-------+-------+-------+-------+ 257 |byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-PRECISION 258 S| E | F | FLOATING-POINT NUMBER 259 +-------+-------+-------+-------+ 260 1|<- 8 ->|<-------23 bits------>| 261 <------------32 bits------------> 263 Just as the most and least significant bytes of a number are 0 and 3, 264 the most and least significant bits of a single-precision floating- 265 point number are 0 and 31. The beginning bit (and most significant 266 bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note that 267 these numbers refer to the mathematical positions of the bits, and 268 NOT to their actual physical locations (which vary from medium to 269 medium). 271 The IEEE specifications should be consulted concerning the encoding 272 for signed zero, signed infinity (overflow), and denormalized numbers 273 (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not 274 a number) is system dependent and should not be interpreted within 275 XDR as anything other than "NaN". 277 4.7. Double-precision Floating-point 279 The standard defines the encoding for the double-precision floating- 280 point data type "double" (64 bits or 8 bytes). The encoding used is 281 the IEEE standard for normalized double-precision floating-point 282 numbers [IEEE]. The standard encodes the following three fields, 283 which describe the double-precision floating-point number: 285 S: The sign of the number. Values 0 and 1 represent positive and 286 negative, respectively. One bit. 288 E: The exponent of the number, base 2. 11 bits are devoted to 289 this field. The exponent is biased by 1023. 291 F: The fractional part of the number's mantissa, base 2. 52 bits 292 are devoted to this field. 294 Therefore, the floating-point number is described by: 296 (-1)**S * 2**(E-Bias) * 1.F 298 It is declared as follows: 300 double identifier; 302 +------+------+------+------+------+------+------+------+ 303 |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7| 304 S| E | F | 305 +------+------+------+------+------+------+------+------+ 306 1|<--11-->|<-----------------52 bits------------------->| 307 <-----------------------64 bits-------------------------> 308 DOUBLE-PRECISION FLOATING-POINT 310 Just as the most and least significant bytes of a number are 0 and 3, 311 the most and least significant bits of a double-precision floating- 312 point number are 0 and 63. The beginning bit (and most significant 313 bit) offsets of S, E , and F are 0, 1, and 12, respectively. Note 314 that these numbers refer to the mathematical positions of the bits, 315 and NOT to their actual physical locations (which vary from medium to 316 medium). 318 The IEEE specifications should be consulted concerning the encoding 319 for signed zero, signed infinity (overflow), and denormalized numbers 320 (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not 321 a number) is system dependent and should not be interpreted within 322 XDR as anything other than "NaN". 324 4.8. Quadruple-precision Floating-point 326 The standard defines the encoding for the quadruple-precision 327 floating-point data type "quadruple" (128 bits or 16 bytes). The 328 encoding used is designed to be a simple analog of of the encoding 329 used for single and double-precision floating-point numbers using one 330 form of IEEE double extended precision. The standard encodes the 331 following three fields, which describe the quadruple-precision 332 floating-point number: 334 S: The sign of the number. Values 0 and 1 represent positive and 335 negative, respectively. One bit. 337 E: The exponent of the number, base 2. 15 bits are devoted to 338 this field. The exponent is biased by 16383. 340 F: The fractional part of the number's mantissa, base 2. 112 bits 341 are devoted to this field. 343 Therefore, the floating-point number is described by: 345 (-1)**S * 2**(E-Bias) * 1.F 347 It is declared as follows: 349 quadruple identifier; 351 +------+------+------+------+------+------+-...--+------+ 352 |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ... |byte15| 353 S| E | F | 354 +------+------+------+------+------+------+-...--+------+ 355 1|<----15---->|<-------------112 bits------------------>| 356 <-----------------------128 bits------------------------> 357 QUADRUPLE-PRECISION FLOATING-POINT 359 Just as the most and least significant bytes of a number are 0 and 3, 360 the most and least significant bits of a quadruple-precision 361 floating-point number are 0 and 127. The beginning bit (and most 362 significant bit) offsets of S, E , and F are 0, 1, and 16, 363 respectively. Note that these numbers refer to the mathematical 364 positions of the bits, and NOT to their actual physical locations 365 (which vary from medium to medium). 367 The encoding for signed zero, signed infinity (overflow), and 368 denormalized numbers are analogs of the corresponding encodings for 369 single and double-precision floating-point numbers [SPAR], [HPRE]. 370 The "NaN" encoding as it applies to quadruple-precision 371 floating-point numbers is system dependent and should not be 372 interpreted within XDR as anything other than "NaN". 374 4.9. Fixed-length Opaque Data 376 At times, fixed-length uninterpreted data needs to be passed among 377 machines. This data is called "opaque" and is declared as follows: 379 opaque identifier[n]; 381 where the constant n is the (static) number of bytes necessary to 382 contain the opaque data. If n is not a multiple of four, then the n 383 bytes are followed by enough (0 to 3) residual zero bytes, r, to make 384 the total byte count of the opaque object a multiple of four. 386 0 1 ... 387 +--------+--------+...+--------+--------+...+--------+ 388 | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | 389 +--------+--------+...+--------+--------+...+--------+ 390 |<-----------n bytes---------->|<------r bytes------>| 391 |<-----------n+r (where (n+r) mod 4 = 0)------------>| 392 FIXED-LENGTH OPAQUE 394 4.10. Variable-length Opaque Data 396 The standard also provides for variable-length (counted) opaque data, 397 defined as a sequence of n (numbered 0 through n-1) arbitrary bytes 398 to be the number n encoded as an unsigned integer (as described 399 below), and followed by the n bytes of the sequence. 401 Byte m of the sequence always precedes byte m+1 of the sequence, and 402 byte 0 of the sequence always follows the sequence's length (count). 403 If n is not a multiple of four, then the n bytes are followed by 404 enough (0 to 3) residual zero bytes, r, to make the total byte count 405 a multiple of four. Variable-length opaque data is declared in the 406 following way: 408 opaque identifier; 409 or 410 opaque identifier<>; 412 The constant m denotes an upper bound of the number of bytes that the 413 sequence may contain. If m is not specified, as in the second 414 declaration, it is assumed to be (2**32) - 1, the maximum length. 415 The constant m would normally be found in a protocol specification. 416 For example, a filing protocol may state that the maximum data 417 transfer size is 8192 bytes, as follows: 419 opaque filedata<8192>; 421 0 1 2 3 4 5 ... 422 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ 423 | length n |byte0|byte1|...| n-1 | 0 |...| 0 | 424 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ 425 |<-------4 bytes------->|<------n bytes------>|<---r bytes--->| 426 |<----n+r (where (n+r) mod 4 = 0)---->| 427 VARIABLE-LENGTH OPAQUE 429 It is an error to encode a length greater than the maximum described 430 in the specification. 432 4.11. String 434 The standard defines a string of n (numbered 0 through n-1) ASCII 435 bytes to be the number n encoded as an unsigned integer (as described 436 above), and followed by the n bytes of the string. Byte m of the 437 string always precedes byte m+1 of the string, and byte 0 of the 438 string always follows the string's length. If n is not a multiple of 439 four, then the n bytes are followed by enough (0 to 3) residual zero 440 bytes, r, to make the total byte count a multiple of four. Counted 441 byte strings are declared as follows: 443 string object; 444 or 445 string object<>; 447 The constant m denotes an upper bound of the number of bytes that a 448 string may contain. If m is not specified, as in the second 449 declaration, it is assumed to be (2**32) - 1, the maximum length. 450 The constant m would normally be found in a protocol specification. 451 For example, a filing protocol may state that a file name can be no 452 longer than 255 bytes, as follows: 454 string filename<255>; 456 0 1 2 3 4 5 ... 457 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ 458 | length n |byte0|byte1|...| n-1 | 0 |...| 0 | 459 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ 460 |<-------4 bytes------->|<------n bytes------>|<---r bytes--->| 461 |<----n+r (where (n+r) mod 4 = 0)---->| 462 STRING 464 It is an error to encode a length greater than the maximum described 465 in the specification. 467 4.12. Fixed-length Array 469 Declarations for fixed-length arrays of homogeneous elements are in 470 the following form: 472 type-name identifier[n]; 474 Fixed-length arrays of elements numbered 0 through n-1 are encoded by 475 individually encoding the elements of the array in their natural 476 order, 0 through n-1. Each element's size is a multiple of four 477 bytes. Though all elements are of the same type, the elements may 478 have different sizes. For example, in a fixed-length array of 479 strings, all elements are of type "string", yet each element will 480 vary in its length. 482 +---+---+---+---+---+---+---+---+...+---+---+---+---+ 483 | element 0 | element 1 |...| element n-1 | 484 +---+---+---+---+---+---+---+---+...+---+---+---+---+ 485 |<--------------------n elements------------------->| 487 FIXED-LENGTH ARRAY 489 4.13. Variable-length Array 491 Counted arrays provide the ability to encode variable-length arrays 492 of homogeneous elements. The array is encoded as the element count n 493 (an unsigned integer) followed by the encoding of each of the array's 494 elements, starting with element 0 and progressing through element n- 495 1. The declaration for variable-length arrays follows this form: 497 type-name identifier; 498 or 499 type-name identifier<>; 501 The constant m specifies the maximum acceptable element count of an 502 array; if m is not specified, as in the second declaration, it is 503 assumed to be (2**32) - 1. 505 0 1 2 3 506 +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+ 507 | n | element 0 | element 1 |...|element n-1| 508 +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+ 509 |<-4 bytes->|<--------------n elements------------->| 510 COUNTED ARRAY 512 It is an error to encode a value of n that is greater than the 513 maximum described in the specification. 515 4.14. Structure 517 Structures are declared as follows: 519 struct { 520 component-declaration-A; 521 component-declaration-B; 522 ... 523 } identifier; 525 The components of the structure are encoded in the order of their 526 declaration in the structure. Each component's size is a multiple of 527 four bytes, though the components may be different sizes. 529 +-------------+-------------+... 530 | component A | component B |... STRUCTURE 531 +-------------+-------------+... 533 4.15. Discriminated Union 535 A discriminated union is a type composed of a discriminant followed 536 by a type selected from a set of prearranged types according to the 537 value of the discriminant. The type of discriminant is either "int", 538 "unsigned int", or an enumerated type, such as "bool". The component 539 types are called "arms" of the union, and are preceded by the value 540 of the discriminant which implies their encoding. Discriminated 541 unions are declared as follows: 543 union switch (discriminant-declaration) { 544 case discriminant-value-A: 545 arm-declaration-A; 546 case discriminant-value-B: 547 arm-declaration-B; 548 ... 549 default: default-declaration; 550 } identifier; 552 Each "case" keyword is followed by a legal value of the discriminant. 553 The default arm is optional. If it is not specified, then a valid 554 encoding of the union cannot take on unspecified discriminant values. 555 The size of the implied arm is always a multiple of four bytes. 557 The discriminated union is encoded as its discriminant followed by 558 the encoding of the implied arm. 560 0 1 2 3 561 +---+---+---+---+---+---+---+---+ 562 | discriminant | implied arm | DISCRIMINATED UNION 563 +---+---+---+---+---+---+---+---+ 564 |<---4 bytes--->| 566 4.16. Void 568 An XDR void is a 0-byte quantity. Voids are useful for describing 569 operations that take no data as input or no data as output. They are 570 also useful in unions, where some arms may contain data and others do 571 not. The declaration is simply as follows: 573 void; 575 Voids are illustrated as follows: 577 ++ 578 || VOID 579 ++ 580 --><-- 0 bytes 582 4.17. Constant 584 The data declaration for a constant follows this form: 586 const name-identifier = n; 588 "const" is used to define a symbolic name for a constant; it does not 589 declare any data. The symbolic constant may be used anywhere a 590 regular constant may be used. For example, the following defines a 591 symbolic constant DOZEN, equal to 12. 593 const DOZEN = 12; 595 4.18. Typedef 597 "typedef" does not declare any data either, but serves to define new 598 identifiers for declaring data. The syntax is: 600 typedef declaration; 602 The new type name is actually the variable name in the declaration 603 part of the typedef. For example, the following defines a new type 604 called "eggbox" using an existing type called "egg": 606 typedef egg eggbox[DOZEN]; 608 Variables declared using the new type name have the same type as the 609 new type name would have in the typedef, if it was considered a 610 variable. For example, the following two declarations are equivalent 611 in declaring the variable "fresheggs": 613 eggbox fresheggs; egg fresheggs[DOZEN]; 615 When a typedef involves a struct, enum, or union definition, there is 616 another (preferred) syntax that may be used to define the same type. 617 In general, a typedef of the following form: 619 typedef <> identifier; 621 may be converted to the alternative form by removing the "typedef" 622 part and placing the identifier after the "struct", "union", or 623 "enum" keyword, instead of at the end. For example, here are the two 624 ways to define the type "bool": 626 typedef enum { /* using typedef */ 627 FALSE = 0, 628 TRUE = 1 629 } bool; 631 enum bool { /* preferred alternative */ 632 FALSE = 0, 633 TRUE = 1 634 }; 636 The reason this syntax is preferred is one does not have to wait 637 until the end of a declaration to figure out the name of the new 638 type. 640 4.19. Optional-data 642 Optional-data is one kind of union that occurs so frequently that we 643 give it a special syntax of its own for declaring it. It is declared 644 as follows: 646 type-name *identifier; 648 This is equivalent to the following union: 650 union switch (bool opted) { 651 case TRUE: 652 type-name element; 653 case FALSE: 654 void; 655 } identifier; 657 It is also equivalent to the following variable-length array 658 declaration, since the boolean "opted" can be interpreted as the 659 length of the array: 661 type-name identifier<1>; 663 Optional-data is not so interesting in itself, but it is very useful 664 for describing recursive data-structures such as linked-lists and 665 trees. For example, the following defines a type "stringlist" that 666 that encodes lists of zero or more arbitrary length strings: 668 struct stringentry { 669 string item<>; 670 stringentry *next; 671 }; 673 typedef stringentry *stringlist; 675 It could have been equivalently declared as the following union: 677 union stringlist switch (bool opted) { 678 case TRUE: 679 struct { 680 string item<>; 681 stringlist next; 682 } element; 683 case FALSE: 684 void; 685 }; 687 or as a variable-length array: 689 struct stringentry { 690 string item<>; 691 stringentry next<1>; 692 }; 694 typedef stringentry stringlist<1>; 696 Both of these declarations obscure the intention of the stringlist 697 type, so the optional-data declaration is preferred over both of 698 them. The optional-data type also has a close correlation to how 699 recursive data structures are represented in high-level languages 700 such as Pascal or C by use of pointers. In fact, the syntax is the 701 same as that of the C language for pointers. 703 4.20. Areas for Future Enhancement 705 The XDR standard lacks representations for bit fields and bitmaps, 706 since the standard is based on bytes. Also missing are packed (or 707 binary-coded) decimals. 709 The intent of the XDR standard was not to describe every kind of data 710 that people have ever sent or will ever want to send from machine to 711 machine. Rather, it only describes the most commonly used data-types 712 of high-level languages such as Pascal or C so that applications 713 written in these languages will be able to communicate easily over 714 some medium. 716 One could imagine extensions to XDR that would let it describe almost 717 any existing protocol, such as TCP. The minimum necessary for this 718 are support for different block sizes and byte-orders. The XDR 719 discussed here could then be considered the 4-byte big-endian member 720 of a larger XDR family. 722 5. DISCUSSION 724 (1) Why use a language for describing data? What's wrong with 725 diagrams? 727 There are many advantages in using a data-description language such 728 as XDR versus using diagrams. Languages are more formal than 729 diagrams and lead to less ambiguous descriptions of data. Languages 730 are also easier to understand and allow one to think of other issues 731 instead of the low-level details of bit-encoding. Also, there is a 732 close analogy between the types of XDR and a high-level language such 733 as C or Pascal. This makes the implementation of XDR encoding and 734 decoding modules an easier task. Finally, the language specification 735 itself is an ASCII string that can be passed from machine to machine 736 to perform on-the-fly data interpretation. 738 (2) Why is there only one byte-order for an XDR unit? 740 Supporting two byte-orderings requires a higher level protocol for 741 determining in which byte-order the data is encoded. Since XDR is 742 not a protocol, this can't be done. The advantage of this, though, 743 is that data in XDR format can be written to a magnetic tape, for 744 example, and any machine will be able to interpret it, since no 745 higher level protocol is necessary for determining the byte-order. 747 (3) Why is the XDR byte-order big-endian instead of little-endian? 748 Isn't this unfair to little-endian machines such as the VAX(r), which 749 has to convert from one form to the other? 751 Yes, it is unfair, but having only one byte-order means you have to 752 be unfair to somebody. Many architectures, such as the Motorola 753 68000* and IBM 370*, support the big-endian byte-order. 755 (4) Why is the XDR unit four bytes wide? 757 There is a tradeoff in choosing the XDR unit size. Choosing a small 758 size such as two makes the encoded data small, but causes alignment 759 problems for machines that aren't aligned on these boundaries. A 760 large size such as eight means the data will be aligned on virtually 761 every machine, but causes the encoded data to grow too big. We chose 762 four as a compromise. Four is big enough to support most 763 architectures efficiently, except for rare machines such as the 764 eight-byte aligned Cray*. Four is also small enough to keep the 765 encoded data restricted to a reasonable size. 767 (5) Why must variable-length data be padded with zeros? 769 It is desirable that the same data encode into the same thing on all 770 machines, so that encoded data can be meaningfully compared or 771 checksummed. Forcing the padded bytes to be zero ensures this. 773 (6) Why is there no explicit data-typing? 775 Data-typing has a relatively high cost for what small advantages it 776 may have. One cost is the expansion of data due to the inserted type 777 fields. Another is the added cost of interpreting these type fields 778 and acting accordingly. And most protocols already know what type 779 they expect, so data-typing supplies only redundant information. 780 However, one can still get the benefits of data-typing using XDR. One 781 way is to encode two things: first a string which is the XDR data 782 description of the encoded data, and then the encoded data itself. 783 Another way is to assign a value to all the types in XDR, and then 784 define a universal type which takes this value as its discriminant 785 and for each value, describes the corresponding data type. 787 6. THE XDR LANGUAGE SPECIFICATION 789 6.1. Notational Conventions 791 This specification uses an extended Back-Naur Form notation for 792 describing the XDR language. Here is a brief description of the 793 notation: 795 (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special. 796 (2) Terminal symbols are strings of any characters surrounded by 797 double quotes. (3) Non-terminal symbols are strings of non-special 798 characters. (4) Alternative items are separated by a vertical bar 799 ("|"). (5) Optional items are enclosed in brackets. (6) Items are 800 grouped together by enclosing them in parentheses. (7) A '*' 801 following an item means 0 or more occurrences of that item. 803 For example, consider the following pattern: 805 "a " "very" (", " "very")* [" cold " "and "] " rainy " 806 ("day" | "night") 808 An infinite number of strings match this pattern. A few of them are: 810 "a very rainy day" 811 "a very, very rainy day" 812 "a very cold and rainy day" 813 "a very, very, very cold and rainy night" 815 6.2. Lexical Notes 817 (1) Comments begin with '/*' and terminate with '*/'. (2) White 818 space serves to separate items and is otherwise ignored. (3) An 819 identifier is a letter followed by an optional sequence of letters, 820 digits or underbar ('_'). The case of identifiers is not ignored. 821 (4) A decimal constant expresses a number in base 10, and is a 822 sequence of one or more decimal digits, where the first digit is not 823 a zero, and is optionally preceded by a minus-sign ('-'). (5) A 824 hexadecimal constant expresses a number in base 16, and must be 825 preceded by '0x', followed by one or hexadecimal digits ('A', 'B', 826 'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3', 827 '4', '5', '6', '7', '8', '9'). (6) An octal constant expresses a 828 number in base 8, always leads with digit 0, and is a sequence of 829 one or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7'). 831 6.3. Syntax Information 833 declaration: 834 type-specifier identifier 835 | type-specifier identifier "[" value "]" 836 | type-specifier identifier "<" [ value ] ">" 837 | "opaque" identifier "[" value "]" 838 | "opaque" identifier "<" [ value ] ">" 839 | "string" identifier "<" [ value ] ">" 840 | type-specifier "*" identifier 841 | "void" 843 value: 844 constant 845 | identifier 847 constant: 848 decimal-constant | hexadecimal-constant | octal-constant 850 type-specifier: 851 [ "unsigned" ] "int" 852 | [ "unsigned" ] "hyper" 853 | "float" 854 | "double" 855 | "quadruple" 856 | "bool" 857 | enum-type-spec 858 | struct-type-spec 859 | union-type-spec 860 | identifier 862 enum-type-spec: 863 "enum" enum-body 865 enum-body: 866 "{" 867 ( identifier "=" value ) 868 ( "," identifier "=" value )* 869 "}" 871 struct-type-spec: 872 "struct" struct-body 874 struct-body: 875 "{" 876 ( declaration ";" ) 877 ( declaration ";" )* 878 "}" 880 union-type-spec: 881 "union" union-body 883 union-body: 884 "switch" "(" declaration ")" "{" 885 case-spec 886 case-spec * 887 [ "default" ":" declaration ";" ] 888 "}" 890 case-spec: 891 ( "case" value ":") 892 ( "case" value ":") * 893 declaration ";" 895 constant-def: 896 "const" identifier "=" constant ";" 898 type-def: 899 "typedef" declaration ";" 900 | "enum" identifier enum-body ";" 901 | "struct" identifier struct-body ";" 902 | "union" identifier union-body ";" 904 definition: 905 type-def 906 | constant-def 908 specification: 909 definition * 911 6.4. Syntax Notes 913 (1) The following are keywords and cannot be used as identifiers: 914 "bool", "case", "const", "default", "double", "quadruple", "enum", 915 "float", "hyper", "int", "opaque", "string", "struct", "switch", 916 "typedef", "union", "unsigned" and "void". 918 (2) Only unsigned constants may be used as size specifications for 919 arrays. If an identifier is used, it must have been declared 920 previously as an unsigned constant in a "const" definition. 922 (3) Constant and type identifiers within the scope of a specification 923 are in the same name space and must be declared uniquely within this 924 scope. 926 (4) Similarly, variable names must be unique within the scope of 927 struct and union declarations. Nested struct and union declarations 928 create new scopes. 930 (5) The discriminant of a union must be of a type that evaluates to 931 an integer. That is, "int", "unsigned int", "bool", an enumerated 932 type or any typedefed type that evaluates to one of these is legal. 933 Also, the case values must be one of the legal values of the 934 discriminant. Finally, a case value may not be specified more than 935 once within the scope of a union declaration. 937 7. AN EXAMPLE OF AN XDR DATA DESCRIPTION 939 Here is a short XDR data description of a thing called a "file", 940 which might be used to transfer files from one machine to another. 942 const MAXUSERNAME = 32; /* max length of a user name */ 943 const MAXFILELEN = 65535; /* max length of a file */ 944 const MAXNAMELEN = 255; /* max length of a file name */ 946 /* 947 * Types of files: 948 */ 949 enum filekind { 950 TEXT = 0, /* ascii data */ 951 DATA = 1, /* raw data */ 952 EXEC = 2 /* executable */ 953 }; 954 /* 955 * File information, per kind of file: 956 */ 957 union filetype switch (filekind kind) { 958 case TEXT: 959 void; /* no extra information */ 960 case DATA: 961 string creator; /* data creator */ 962 case EXEC: 963 string interpretor; /* program interpretor */ 964 }; 966 /* 967 * A complete file: 968 */ 969 struct file { 970 string filename; /* name of file */ 971 filetype type; /* info about file */ 972 string owner; /* owner of file */ 973 opaque data; /* file data */ 974 }; 976 Suppose now that there is a user named "john" who wants to store his 977 lisp program "sillyprog" that contains just the data "(quit)". His 978 file would be encoded as follows: 980 OFFSET HEX BYTES ASCII COMMENTS 981 ------ --------- ----- -------- 982 0 00 00 00 09 .... -- length of filename = 9 983 4 73 69 6c 6c sill -- filename characters 984 8 79 70 72 6f ypro -- ... and more characters ... 985 12 67 00 00 00 g... -- ... and 3 zero-bytes of fill 986 16 00 00 00 02 .... -- filekind is EXEC = 2 987 20 00 00 00 04 .... -- length of interpretor = 4 988 24 6c 69 73 70 lisp -- interpretor characters 989 28 00 00 00 04 .... -- length of owner = 4 990 32 6a 6f 68 6e john -- owner characters 991 36 00 00 00 06 .... -- length of file data = 6 992 40 28 71 75 69 (qui -- file data bytes ... 993 44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill 995 8. Security Considerations 997 XDR is a data description language, not a protocol, and hence it does 998 not inherently give rise to any particular security considerations. 999 Protocols that carry XDR-formatted data, such as NFSv4, are 1000 responsible for providing any necessary security services to secure 1001 the data they transport. 1003 Care must be take to properly encode and decode data to avoid 1004 attacks. Known and avoidable risks include: 1006 * Buffer overflow attacks. Where feasible, protocols should be 1007 defined with explicit limits (via the "<" [ value ] ">" notation 1008 instead of "<" ">") on elements with variable length data types. 1009 Regardless of the feasibility of an explicit limit on the 1010 variable length of an element of a given protocol, decoders need 1011 to ensure the incoming size does not exceed the length of any 1012 provisioned receiver buffers. 1014 * Nul octets embedded in an encoded value of type string. If the 1015 decoder's native string format uses nul terminated strings, then 1016 the apparent size of the decoded object will be less than the 1017 amount of memory allocated for the string. Some memory 1018 deallocation interfaces take a size argument. The caller of the 1019 deallocation interface would likely determine the size of the 1020 string by counting to the location of the nul octet, and adding 1021 one. This discrepancy can cause memory leakage (because less 1022 memory is actually returned to the free pool than allocated), 1023 leading to system failure and a denial of service attack. 1025 * Decoding of characters in strings that are legal ASCII 1026 characters but nonetheless are illegal for the intended 1027 application. For example some operating systems treat the '/' 1028 character as a component separator in path names. For a protocol 1029 that encodes a string in the argument to a file creation 1030 operation, the decoder needs to ensure sure '/' is not inside 1031 the component name. Otherwise, a file with an illegal '/' in 1032 its name will be created, making it difficult to remove, and is 1033 therefore a denial of service attack. 1035 * Denial of service caused by recursive decoder or encoder 1036 subroutines. A recursive decoder or encoder might process data 1037 that has a structured type with a member of type optional data 1038 that directly or indirectly refers to the structured type (i.e. 1039 a linked list). For example, 1041 struct m { 1042 int x; 1043 struct m *next; 1044 }; 1046 An encoder or decoder subroutine might be written to recursively 1047 call itself each time another element of type "struct m" is 1048 found. An attacker could construct a long linked list of "struct 1049 m" elements in the request or response which then causes a stack 1050 overflow on the decoder or encoder. Decoders and encoders 1051 should be written non-recursively, or impose a limit on list 1052 length. 1054 9. IANA Considerations 1056 It is possible, if not likely, that new data types will be added to 1057 XDR in the future. The process for adding new types is via a 1058 standards track RFC and not registration of new types with IANA. 1059 Standards track RFCs that update or replace this document should be 1060 documented as such in the RFC Editor's database of RFCs. 1062 10. TRADEMARKS AND OWNERS 1064 SUN WORKSTATION Sun Microsystems, Inc. 1065 VAX Hewlett-Packard Company 1066 IBM-PC International Business Machines Corporation 1067 Cray Cray Inc. 1068 NFS Sun Microsystems, Inc. 1069 Ethernet Xerox Corporation. 1070 Motorola 68000 Motorola, Inc. 1071 IBM 370 International Business Machines Corporation 1073 11. ANSI/IEEE Standard 754-1985 1075 The definition of NaNs, signed zero and infinity, and denormalized 1076 numbers from [IEEE] is reproduced here for convenience. The 1077 definitions for quadruple-precision floating point numbers are 1078 analogs of those for single and double-precision floating point 1079 numbers, and are defined in [IEEE]. 1081 In the following, 'S' stands for the sign bit, 'E' for the exponent, 1082 and 'F' for the fractional part. The symbol 'u' stands for an 1083 undefined bit (0 or 1). 1085 For single-precision floating point numbers: 1087 Type S (1 bit) E (8 bits) F (23 bits) 1088 ---- --------- ---------- ----------- 1089 signalling NaN u 255 (max) .0uuuuu---u 1090 (with at least 1091 one 1 bit) 1092 quiet NaN u 255 (max) .1uuuuu---u 1094 negative infinity 1 255 (max) .000000---0 1096 positive infinity 0 255 (max) .000000---0 1098 negative zero 1 0 .000000---0 1099 positive zero 0 0 .000000---0 1101 For double-precision floating point numbers: 1103 Type S (1 bit) E (11 bits) F (52 bits) 1104 ---- --------- ----------- ----------- 1105 signalling NaN u 2047 (max) .0uuuuu---u 1106 (with at least 1107 one 1 bit) 1108 quiet NaN u 2047 (max) .1uuuuu---u 1110 negative infinity 1 2047 (max) .000000---0 1112 positive infinity 0 2047 (max) .000000---0 1114 negative zero 1 0 .000000---0 1116 positive zero 0 0 .000000---0 1118 For quadruple-precision floating point numbers: 1120 Type S (1 bit) E (15 bits) F (112 bits) 1121 ---- --------- ----------- ------------ 1122 signalling NaN u 32767 (max) .0uuuuu---u 1123 (with at least 1124 one 1 bit) 1125 quiet NaN u 32767 (max) .1uuuuu---u 1127 negative infinity 1 32767 (max) .000000---0 1129 positive infinity 0 32767 (max) .000000---0 1131 negative zero 1 0 .000000---0 1133 positive zero 0 0 .000000---0 1135 Subnormal numbers are represented as follows: 1137 Precision Exponent Value 1138 --------- -------- ----- 1139 Single 0 (-1)**S * 2**(-126) * 0.F 1141 Double 0 (-1)**S * 2**(-1022) * 0.F 1143 Quadruple 0 (-1)**S * 2**(-16382) * 0.F 1145 12. NORMATIVE REFERENCES 1147 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 1148 ANSI/IEEE Standard 754-1985, Institute of Electrical and 1149 Electronics Engineers, August 1985. 1151 13. INFORMATIVE REFERENCES 1153 [KERN] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming 1154 Language", Bell Laboratories, Murray Hill, New Jersey, 1978. 1156 [COHE] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE 1157 Computer, October 1981. 1159 [COUR] "Courier: The Remote Procedure Call Protocol", XEROX 1160 Corporation, XSIS 038112, December 1981. 1162 [SPAR] "The SPARC Architecture Manual: Version 8", Prentice Hall, 1163 ISBN 0-13-825001-4. 1165 [HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906. 1167 14. Editor's Address 1169 Mike Eisler 1170 5765 Chase Point Circle 1171 Colorado Springs, CO 80919 1172 USA 1174 Phone: 719-599-9026 1175 EMail: mike.ietf.xdr@eisler.com 1177 Please address comments to: nfsv4@ietf.org 1179 15. Acknowledgements 1181 Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun 1182 Microsystems, Inc. is listed as the author of RFC1014, which RFC1832 1183 was heavily derived from. Raj Srinivasan in turn edited RFC1014 into 1184 RFC1832. Raj and the rest of the old ONC RPC working group produced 1185 RFC1832 from which this document is derived. Mike Eisler and Bill 1186 Janssen submitted the implementation reports for this standard. Kevin 1187 Coffman, Benny Halevy, and Jon Peterson reviewed this document and 1188 gave feedback. Peter Astrand and Bryan Olson pointed out several 1189 errors in RFC1832 which are corrected in this document. 1191 16. IPR Notices 1193 The IETF takes no position regarding the validity or scope of any 1194 intellectual property or other rights that might be claimed to 1195 pertain to the implementation or use of the technology described in 1196 this document or the extent to which any license under such rights 1197 might or might not be available; neither does it represent that it 1198 has made any effort to identify any such rights. Information on the 1199 IETF's procedures with respect to rights in standards-track and 1200 standards-related documentation can be found in BCP-11. Copies of 1201 claims of rights made available for publication and any assurances of 1202 licenses to be made available, or the result of an attempt made to 1203 obtain a general license or permission for the use of such 1204 proprietary rights by implementors or users of this specification can 1205 be obtained from the IETF Secretariat. 1207 The IETF invites any interested party to bring to its attention any 1208 copyrights, patents or patent applications, or other proprietary 1209 rights which may cover technology that may be required to practice 1210 this standard. Please address the information to the IETF Executive 1211 Director. 1213 17. Copyright Notice 1215 Copyright (C) The Internet Society (2005). This document is subject 1216 to the rights, licenses and restrictions contained in BCP 78, and 1217 except as set forth therein, the authors retain all their rights. 1219 This document and the information contained herein are provided on an 1220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1222 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1223 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1224 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.