idnits 2.17.1 draft-legg-ldap-gser-abnf-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 4, 2003) is 7630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '9' is defined on line 509, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2252 (ref. '4') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (ref. '5') (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) -- No information found for draft-legg-ldap-gser-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. '9') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 3377 (ref. '10') (Obsoleted by RFC 4510) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg 3 draft-legg-ldap-gser-abnf-07.txt Adacel Technologies 4 Intended Category: Informational June 4, 2003 6 Common Elements of GSER Encodings 8 Copyright (C) The Internet Society (2003). All Rights Reserved. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Comments should be sent 32 to the LDAPEXT working group mailing list 33 or to the author. 35 This Internet-Draft expires on 4 December 2003. 37 Abstract 39 The Generic String Encoding Rules (GSER) describe a human readable 40 text encoding for an Abstract Syntax Notation One (ASN.1) value of 41 any ASN.1 type. Specifications making use of GSER may wish to 42 provide an equivalent Augmented Backus-Naur Form (ABNF) description 43 of the GSER encoding for a particular ASN.1 type as a convenience for 44 implementors. This document supports such specifications by 45 providing equivalent ABNF for the GSER encodings for ASN.1 types 46 commonly occuring in Lightweight Directory Access Protocol (LDAP) 47 syntaxes. 49 1. Table of Contents 51 1. Table of Contents ............................................. 2 52 2. Introduction .................................................. 2 53 3. Conventions ................................................... 2 54 4. Separators .................................................... 2 55 5. ASN.1 Built-in Types .......................................... 3 56 6. ASN.1 Restricted String Types ................................. 7 57 7. Directory ASN.1 Types ......................................... 9 58 8. Security Considerations ....................................... 10 59 9. Normative References .......................................... 11 60 10. Informative References ....................................... 11 61 11. Intellectual Property Notice ................................. 12 62 12. Copyright Notice ............................................. 12 63 13. Author's Address ............................................. 13 65 2. Introduction 67 The Generic String Encoding Rules (GSER) [7] define a human readable 68 text encoding, based on ASN.1 [8] value notation, for an ASN.1 value 69 of any ASN.1 type. Specifications making use of GSER may wish to 70 provide a non-normative equivalent ABNF [3] description of the GSER 71 encoding for a particular ASN.1 type as a convenience for 72 implementors unfamiliar with ASN.1. This document supports such 73 specifications by providing equivalent ABNF for the GSER encodings 74 for ASN.1 types commonly occuring in LDAP [10] or X.500 [11] 75 attribute and assertion syntaxes, as well as equivalent ABNF for the 76 GSER encodings for the ASN.1 built-in types. 78 The ABNF given in this document does not replace or alter GSER in any 79 way. If there is a discrepancy between the ABNF specified here and 80 the encoding defined by GSER [7] then GSER is to be taken as 81 definitive. 83 3. Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 87 to be interpreted as described in RFC 2119 [1]. The key word 88 "OPTIONAL" is exclusively used with its ASN.1 meaning. 90 4. Separators 91 Certain separators are commonly used in constructing equivalent ABNF 92 for SET and SEQUENCE types. 94 sp = *%x20 ; zero, one or more space characters 95 msp = 1*%x20 ; one or more space characters 97 sep = [ "," ] 99 The rule is used in the ABNF description of the encoding for 100 ASN.1 SET or SEQUENCE types where all the components are either 101 OPTIONAL or DEFAULT. It encodes to an empty string if and only if 102 the immediately preceding character in the encoding is "{", i.e. it 103 is only empty for the first optional component actually present in 104 the SET or SEQUENCE value being encoded. 106 5. ASN.1 Built-in Types 108 This section describes the GSER encoding of values of the ASN.1 109 built-in types, except for the restricted character string types. 111 The rule describes the GSER encoding of values of the 112 BIT STRING type without a named bit list. 114 BIT-STRING = bstring / hstring 116 If the number of bits in a BIT STRING value is a multiple of four the 117 form of MAY be used. The form of 118 is used otherwise. The rule encodes each bit 119 as the character "0" or "1" in order from the first bit to the last 120 bit. The rule encodes each group of four bits as a 121 hexadecimal number where the first bit is the most significant. An 122 odd number of hexadecimal digits is permitted. 124 hstring = squote *hexadecimal-digit squote %x48 ; '...'H 125 hexadecimal-digit = %x30-39 / ; "0" to "9" 126 %x41-46 ; "A" to "F" 128 bstring = squote *binary-digit squote %x42 ; '...'B 129 binary-digit = "0" / "1" 131 squote = %x27 ; ' (single quote) 133 The rule describes the GSER encoding of values of the 134 BOOLEAN type. 136 BOOLEAN = %x54.52.55.45 / ; "TRUE" 137 %x46.41.4C.53.45 ; "FALSE" 139 The rule describes the GSER encoding of values of 140 the associated type for the unrestricted CHARACTER STRING type. 142 CHARACTER-STRING = "{" sp id-identification msp Identification "," 143 sp id-data-value msp OCTET-STRING 144 sp "}" 146 id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E 147 ; "identification" 148 id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value" 150 Identification = ( id-syntaxes ":" Syntaxes ) / 151 ( id-syntax ":" OBJECT-IDENTIFIER ) / 152 ( id-presentation-context-id ":" INTEGER ) / 153 ( id-context-negotiation ":" 154 ContextNegotiation ) / 155 ( id-transfer-syntax ":" OBJECT-IDENTIFIER ) / 156 ( id-fixed ":" NULL ) 158 id-syntaxes = %x73.79.6E.74.61.78.65.73 159 ; "syntaxes" 160 id-syntax = %x73.79.6E.74.61.78 ; "syntax" 161 id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E 162 %x2D.63.6F.6E.74.65.78.74.2D.69.64 163 ; "presentation-context-id" 164 id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F 165 %x74.69.61.74.69.6F.6E 166 ; "context-negotiation" 167 id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E 168 %x74.61.78 ; "transfer-syntax" 169 id-fixed = %x66.69.78.65.64 ; "fixed" 171 Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER "," 172 sp id-transfer msp OBJECT-IDENTIFIER 173 sp "}" 174 id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract" 175 id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer" 177 ContextNegotiation = "{" sp id-presentation-context-id msp 178 INTEGER "," 179 sp id-transfer-syntax msp 180 OBJECT-IDENTIFIER 181 sp "}" 183 The rule describes the GSER encoding of values of the 184 INTEGER type without a named number list. The rule 185 describes the GSER encoding of values of the constrained type INTEGER 186 (0..MAX). The rule describes the GSER encoding of 187 values of the constrained type INTEGER (1..MAX). 189 INTEGER = "0" / positive-number / ("-" positive-number) 190 INTEGER-0-MAX = "0" / positive-number 191 INTEGER-1-MAX = positive-number 192 positive-number = non-zero-digit *decimal-digit 193 decimal-digit = %x30-39 ; "0" to "9" 194 non-zero-digit = %x31-39 ; "1" to "9" 196 The rule describes the GSER encoding of values of the 197 associated type for the EMBEDDED PDV type. 199 EMBEDDED-PDV = "{" sp id-identification msp Identification "," 200 sp id-data-value msp OCTET-STRING 201 sp "}" 203 The rule describes the GSER encoding of values of the 204 associated type for the EXTERNAL type. 206 EXTERNAL = "{" [ sp id-direct-reference msp 207 OBJECT-IDENTIFIER "," ] 208 [ sp id-indirect-reference msp INTEGER "," ] 209 [ sp id-data-value-descriptor msp 210 ObjectDescriptor "," ] 211 sp id-encoding msp Encoding 212 sp "}" 214 id-direct-reference = %x64.69.72.65.63.74.2D.72.65.66.65.72 215 %x65.6E.63.65 216 ; "direct-reference" 217 id-indirect-reference = %x69.6E.64.69.72.65.63.74.2D.72.65.66 218 %x65.72.65.6E.63.65 219 ; "indirect-reference" 220 id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64 221 %x65.73.63.72.69.70.74.6F.72 222 ; "data-value-descriptor" 223 id-encoding = %x65.6E.63.6F.64.69.6E.67 224 ; "encoding" 226 Encoding = ( id-single-ASN1-type ":" Value ) / 227 ( id-octet-aligned ":" OCTET-STRING ) / 228 ( id-arbitrary ":" BIT-STRING ) 230 id-single-ASN1-type = %x73.69.6E.67.6C.65.2D.41.53.4E.31.2D.74.79 231 %x70.65 232 ; "single-ASN1-type" 233 id-octet-aligned = %x6F.63.74.65.74.2D.61.6C.69.67.6E.65.64 234 ; "octet-aligned" 236 id-arbitrary = %x61.72.62.69.74.72.61.72.79 237 ; "arbitrary" 239 The rule is defined by GSER [7]. It represents the GSER 240 encoding of a single value of the ASN.1 type identified by the 241 direct-reference and/or indirect-reference components. 243 The rule describes the GSER encoding of values of the NULL 244 type. 246 NULL = %x4E.55.4C.4C ; "NULL" 248 The rule describes the GSER encoding of values of 249 the OBJECT IDENTIFIER type. 251 OBJECT-IDENTIFIER = numeric-oid / descr 252 numeric-oid = oid-component 1*( "." oid-component ) 253 oid-component = "0" / positive-number 255 An OBJECT IDENTIFIER value is encoded using either the dotted decimal 256 representation or an object descriptor name, i.e. . The 257 rule is described in RFC 2252 [4]. An object descriptor name 258 is potentially ambiguous and should be used with care. 260 The rule describes the GSER encoding of values of the 261 OCTET STRING type. 263 OCTET-STRING = hstring 265 The octets are encoded in order from the first octet to the last 266 octet. Each octet is encoded as a pair of hexadecimal digits where 267 the first digit corresponds to the four most significant bits of the 268 octet. If the hexadecimal string does not have an even number of 269 digits the four least significant bits in the last octet are assumed 270 to be zero. 272 The rule describes the GSER encoding of values of the REAL 273 type. 275 REAL = "0" ; zero 276 / PLUS-INFINITY ; positive infinity 277 / MINUS-INFINITY ; negative infinity 278 / realnumber ; positive base 10 REAL value 279 / ( "-" realnumber ) ; negative base 10 REAL value 280 / real-sequence-value ; non-zero base 2 or 10 REAL value 282 PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 283 ; "PLUS-INFINITY" 285 MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59 286 ; "MINUS-INFINITY" 288 realnumber = mantissa exponent 289 mantissa = (positive-number [ "." *decimal-digit ]) 290 / ( "0." *("0") positive-number ) 291 exponent = "E" ( "0" / ([ "-" ] positive-number)) 293 real-sequence-value = "{" sp id-mantissa msp INTEGER "," 294 sp id-base msp ( "2" / "10" ) "," 295 sp id-exponent msp INTEGER sp "}" 296 id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa" 297 id-base = %x62.61.73.65 ; "base" 298 id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent" 300 A value of the REAL type MUST be encoded as "0" if it is zero. 302 The rule describes the GSER encoding of values of the 303 RELATIVE-OID type. 305 RELATIVE-OID = oid-component *( "." oid-component ) 307 6. ASN.1 Restricted String Types 309 This section describes the GSER encoding of values of the ASN.1 310 restricted character string types. The characters of a value of a 311 restricted character string type are always encoded as a UTF-8 312 character string between double quotes. For some of the ASN.1 string 313 types this requires a translation to or from the UTF-8 encoding. 314 Some of the ASN.1 string types permit only a subset of the characters 315 representable in UTF-8. Any double quote characters in the character 316 string, where allowed by the character set, are escaped by being 317 repeated. 319 The rule describes the GSER encoding of values of the 320 UTF8String type. The characters of this string type do not require 321 any translation before being encoded. 323 UTF8String = StringValue 324 StringValue = dquote *SafeUTF8Character dquote 326 dquote = %x22 ; " (double quote) 328 SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote 329 dquote dquote / ; escaped double quote 330 %xC0-DF %x80-BF / ; 2 byte UTF-8 character 331 %xE0-EF 2(%x80-BF) / ; 3 byte UTF-8 character 332 %xF0-F7 3(%x80-BF) ; 4 byte UTF-8 character 334 The , , , 335 , , and rules 336 describe the GSER encoding of values of the correspondingly named 337 ASN.1 types. The characters of these string types are compatible 338 with UTF-8 and do not require any translation before being encoded. 339 The GeneralizedTime and UTCTime types use the VisibleString character 340 set, but have a strictly defined format. 342 NumericString = dquote *(decimal-digit / space) dquote 343 space = %x20 345 PrintableString = dquote *PrintableCharacter dquote 346 PrintableCharacter = decimal-digit / space 347 / %x41-5A ; A to Z 348 / %x61-7A ; a to z 349 / %x27-29 ; ' ( ) 350 / %x2B-2F ; + , - . / 351 / %x3A ; : 352 / %x3D ; = 353 / %x3F ; ? 355 ISO646String = VisibleString 356 VisibleString = dquote *SafeVisibleCharacter dquote 357 SafeVisibleCharacter = %x20-21 358 / %x23-7E ; printable ASCII minus dquote 359 / dquote dquote ; escaped double quote 361 IA5String = dquote *SafeIA5Character dquote 362 SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote 363 / dquote dquote ; escaped double quote 365 century = 2(%x30-39) ; "00" to "99" 366 year = 2(%x30-39) ; "00" to "99" 367 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 368 / ( %x31 %x30-32 ) ; "10" to "12" 369 day = ( %x30 %x31-39 ) ; "01" to "09" 370 / ( %x31-32 %x30-39 ) ; "10" to "29" 371 / ( %x32 %x30-31 ) ; "30" to "31" 372 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 373 minute = %x30-35 %x30-39 ; "00" to "59" 374 second = ( %x30-35 %x30-39 ) ; "00" to "59" 375 / ( %x36 %x30 ) ; "60" (a leap second) 377 UTCTime = dquote year month day hour minute [ second ] 378 [ %x5A / u-differential ] dquote 379 u-differential = ( "-" / "+" ) hour minute 380 GeneralizedTime = dquote century year month day hour 381 [ minute [ second ] ] [ fraction ] 382 [ %x5A / g-differential ] dquote 383 fraction = ( "." / "," ) 1*(%x30-39) 384 g-differential = ( "-" / "+" ) hour [ minute ] 386 The and rules describe the GSER 387 encoding of values of the BMPString and UniversalString types 388 respectively. BMPString (UCS-2) and UniversalString (UCS-4) values 389 are translated into UTF-8 [6] character strings before being encoded 390 according to . 392 BMPString = StringValue 393 UniversalString = StringValue 395 The , , , , 396 and rules describe the GSER 397 encoding of values of the correspondingly named ASN.1 types. Values 398 of these string types are translated into UTF-8 character strings 399 before being encoded according to . The 400 ObjectDescriptor type uses the GraphicString character set. 402 TeletexString = StringValue 403 T61String = StringValue 404 VideotexString = StringValue 405 GraphicString = StringValue 406 GeneralString = StringValue 407 ObjectDescriptor = GraphicString 409 7. Directory ASN.1 Types 411 This section describes the GSER encoding of values of selected ASN.1 412 types defined for LDAP and X.500. The ABNF rule names beginning with 413 uppercase letters describe the GSER encoding of values of the ASN.1 414 type with the same name. 416 AttributeType = OBJECT-IDENTIFIER 418 The characters of a DirectoryString are translated into UTF-8 419 characters as required before being encoded between double quotes 420 with any embedded double quotes escaped by being repeated. 422 DirectoryString = StringValue / 423 ( id-teletexString ":" TeletexString ) / 424 ( id-printableString ":" PrintableString ) / 425 ( id-bmpString ":" BMPString ) / 426 ( id-universalString ":" UniversalString ) / 427 ( id-uTF8String ":" UTF8String ) 429 id-teletexString = %x74.65.6C.65.74.65.78.53.74.72.69.6E.67 430 ; "teletexString" 431 id-printableString = %x70.72.69.6E.74.61.62.6C.65 432 %x53.74.72.69.6E.67 ; "printableString" 433 id-bmpString = %x62.6D.70.53.74.72.69.6E.67 ; "bmpString" 434 id-universalString = %x75.6E.69.76.65.72.73.61.6C 435 %x53.74.72.69.6E.67 ; "universalString" 436 id-uTF8String = %x75.54.46.38.53.74.72.69.6E.67 437 ; "uTF8String" 439 The rule describes the GSER encoding of values of the 440 RDNSequence type, which is syntactically equivalent to the 441 DistinguishedName and LocalName types. The rule 442 encodes a name as an LDAPDN character string between double quotes. 443 The character string is first derived according to the 444 rule in Section 3 of RFC 2253 [5], and then it is 445 encoded between double quotes with any embedded double quotes escaped 446 by being repeated. 448 DistinguishedName = RDNSequence 449 LocalName = RDNSequence 450 RDNSequence = dquote *SafeUTF8Character dquote 452 The rule describes the GSER encoding of 453 values of the RelativeDistinguishedName type that are not part of an 454 RDNSequence value. The rule encodes an 455 RDN as a double quoted string containing the RDN as it would appear 456 in an LDAPDN character string. The character string is first derived 457 according to the rule in Section 3 of RFC 2253 [5], 458 and then any embedded double quote characters are escaped by being 459 repeated. This resulting string is output between double quotes. 461 RelativeDistinguishedName = dquote *SafeUTF8Character dquote 463 The rule encodes an X.400 address as an IA5 character 464 string between double quotes. The character string is first derived 465 according to Section 4.1 of RFC 2156 [2], and then any embedded 466 double quotes are escaped by being repeated. This resulting string 467 is output between double quotes. 469 ORAddress = dquote *SafeIA5Character dquote 471 8. Security Considerations 473 This document contains an alternative description of parts of the 474 Generic String Encoding Rules, but does not replace or alter GSER in 475 any way. For the full security implications of using GSER see the 476 Security Considerations section for GSER [7]. 478 9. Normative References 480 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 481 Levels", BCP 14, RFC 2119, March 1997. 483 [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 484 between X.400 and RFC 822/MIME", RFC 2156, January 1998. 486 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 487 Specifications: ABNF", RFC 2234, November 1997. 489 [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight 490 Directory Access Protocol (v3): Attribute Syntax Definitions", 491 RFC 2252, December 1997. 493 [5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access 494 Protocol (v3): UTF-8 String Representation of Distinguished 495 Names", RFC 2253, December 1997. 497 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 498 2279, January 1998. 500 [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types", 501 draft-legg-ldap-gser-xx.txt, a work in progress, June 2003. 503 [8] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1 Information 504 technology - Abstract Syntax Notation One (ASN.1): 505 Specification of basic notation 507 10. Informative References 509 [9] Hovey, R. and S. Bradner, "The Organizations Involved in the 510 IETF Standards Process", BCP 11, RFC 2028, October 1996. 512 [10] Hodges, J. and R. Morgan, "Lightweight Directory Access 513 Protocol (v3): Technical Specification", RFC 3377, September 514 2002. 516 [11] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 517 Information Technology - Open Systems Interconnection - The 518 Directory: Overview of concepts, models and services 520 11. Intellectual Property Notice 522 The IETF takes no position regarding the validity or scope of any 523 intellectual property or other rights that might be claimed to 524 pertain to the implementation or use of the technology described in 525 this document or the extent to which any license under such rights 526 might or might not be available; neither does it represent that it 527 has made any effort to identify any such rights. Information on the 528 IETF's procedures with respect to rights in standards-track and 529 standards-related documentation can be found in BCP-11. [9] Copies of 530 claims of rights made available for publication and any assurances of 531 licenses to be made available, or the result of an attempt made to 532 obtain a general license or permission for the use of such 533 proprietary rights by implementors or users of this specification can 534 be obtained from the IETF Secretariat. 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights which may cover technology that may be required to practice 539 this standard. Please address the information to the IETF Executive 540 Director. 542 12. Copyright Notice 544 Copyright (C) The Internet Society (2003). All Rights Reserved. 546 This document and translations of it may be copied and furnished to 547 others, and derivative works that comment on or otherwise explain it 548 or assist in its implementation may be prepared, copied, published 549 and distributed, in whole or in part, without restriction of any 550 kind, provided that the above copyright notice and this paragraph are 551 included on all such copies and derivative works. However, this 552 document itself may not be modified in any way, such as by removing 553 the copyright notice or references to the Internet Society or other 554 Internet organizations, except as needed for the purpose of 555 developing Internet standards in which case the procedures for 556 copyrights defined in the Internet Standards process must be 557 followed, or as required to translate it into languages other than 558 English. 560 The limited permissions granted above are perpetual and will not be 561 revoked by the Internet Society or its successors or assigns. 563 This document and the information contained herein is provided on an 564 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 565 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 566 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 567 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 568 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 13. Author's Address 572 Steven Legg 573 Adacel Technologies Ltd. 574 250 Bay Street 575 Brighton, Victoria 3186 576 AUSTRALIA 578 Phone: +61 3 8530 7710 579 Fax: +61 3 8530 7888 580 EMail: steven.legg@adacel.com.au