idnits 2.17.1 draft-crocker-abnf-rfc2234bis-00.txt: -(112): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 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 (March 9, 2005) is 6959 days in the past. Is this intentional? 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: 'RFC733' is mentioned on line 519, but not defined ** Obsolete undefined reference: RFC 733 (Obsoleted by RFC 822) == Missing Reference: 'RFC822' is mentioned on line 523, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RULE' is mentioned on line 389, but not defined == Missing Reference: 'RFC2234' is mentioned on line 516, but not defined ** Obsolete undefined reference: RFC 2234 (Obsoleted by RFC 4234) == Unused Reference: 'US-ASCII' is defined on line 509, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Obsoletes: RFC2234 (if approved) P. Overell 5 Expires: September 10, 2005 Demon Internet Ltd. 6 March 9, 2005 8 Augmented BNF for Syntax Specifications: ABNF 9 draft-crocker-abnf-rfc2234bis-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 10, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Internet technical specifications often need to define a format 45 syntax. Over the years a modified version of Backus-Naur Form (BNF), 46 called Augmented BNF (ABNF), has been popular among many Internet 47 specifications. The current specification documents ABNF. It 48 balances compactness and simplicity, with reasonable representational 49 power. The differences between standard BNF and ABNF involve naming 50 rules, repetition, alternatives, order-independence, and value 51 ranges. This specification also supplies additional rule definitions 52 and encoding for a core lexical analyzer of the type common to 53 several Internet specifications. 55 Table of Contents 57 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. RULE DEFINITION . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1 Rule Naming . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2 Rule Form . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3 Terminal Values . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4 External Encodings . . . . . . . . . . . . . . . . . . . . . 6 63 3. OPERATORS . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1 Concatenation: Rule1 Rule2 . . . . . . . . . . . . . . . . 6 65 3.2 Alternatives: Rule1 / Rule2 . . . . . . . . . . . . . . . . 7 66 3.3 Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . . . 7 67 3.4 Value Range Alternatives: %c##-## . . . . . . . . . . . . . 8 68 3.5 Sequence Group: (Rule1 Rule2) . . . . . . . . . . . . . . . 8 69 3.6 Variable Repetition: *Rule . . . . . . . . . . . . . . . . 9 70 3.7 Specific Repetition: nRule . . . . . . . . . . . . . . . . 9 71 3.8 Optional Sequence: [RULE] . . . . . . . . . . . . . . . . . 9 72 3.9 Comment: ; Comment . . . . . . . . . . . . . . . . . . . . 9 73 3.10 Operator Precedence . . . . . . . . . . . . . . . . . . . . 9 74 4. ABNF DEFINITION OF ABNF . . . . . . . . . . . . . . . . . . 10 75 5. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 11 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.2 Descriptive . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 80 A. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 12 81 B. APPENDIX - CORE ABNF OF ABNF . . . . . . . . . . . . . . . . 13 82 B.1 Core Rules . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 B.2 Common Encoding . . . . . . . . . . . . . . . . . . . . . . 14 84 Intellectual Property and Copyright Statements . . . . . . . 15 86 1. INTRODUCTION 88 Internet technical specifications often need to define a format 89 syntax and are free to employ whatever notation their authors deem 90 useful. Over the years, a modified version of Backus-Naur Form 91 (BNF), called Augmented BNF (ABNF), has been popular among many 92 Internet specifications. It balances compactness and simplicity, 93 with reasonable representational power. In the early days of the 94 Arpanet, each specification contained its own definition of ABNF. 95 This included the email specifications, [RFC733] and then [RFC822] 96 which came to be the common citations for defining ABNF. The current 97 document separates out that definition, to permit selective 98 reference. Predictably, it also provides some modifications and 99 enhancements. 101 The differences between standard BNF and ABNF involve naming rules, 102 repetition, alternatives, order-independence, and value ranges. 103 Appendix B supplies rule definitions and encoding for a core lexical 104 analyzer of the type common to several Internet specifications. It 105 is provided as a convenience and is otherwise separate from the meta 106 language defined in the body of this document, and separate from its 107 formal status. 109 Changes in the latest version of this Internet Draft: 111 In Section 3.7 the phrase: "That is, exactly � occurrences of 112 ." was correct to: "That is, exactly � occurrences of 113 ." 115 Some continuation comment lines needed to be corrected to begin 116 with comment character (";"). 118 2. RULE DEFINITION 120 2.1 Rule Naming 122 The name of a rule is simply the name itself; that is, a sequence of 123 characters, beginning with an alphabetic character, and followed by a 124 combination of alphabetics, digits and hyphens (dashes). 126 NOTE: 128 Rule names are case-insensitive 130 The names , , and all refer 131 to the same rule. 133 Unlike original BNF, angle brackets ("<", ">") are not required. 134 However, angle brackets may be used around a rule name whenever their 135 presence will facilitate discerning the use of a rule name. This is 136 typically restricted to rule name references in free-form prose, or 137 to distinguish partial rules that combine into a string not separated 138 by white space, such as shown in the discussion about repetition, 139 below. 141 2.2 Rule Form 143 A rule is defined by the following sequence: 145 name = elements crlf 147 where is the name of the rule, is one or more rule 148 names or terminal specifications and is the end-of- line 149 indicator, carriage return followed by line feed. The equal sign 150 separates the name from the definition of the rule. The elements 151 form a sequence of one or more rule names and/or value definitions, 152 combined according to the various operators, defined in this 153 document, such as alternative and repetition. 155 For visual ease, rule definitions are left aligned. When a rule 156 requires multiple lines, the continuation lines are indented. The 157 left alignment and indentation are relative to the first lines of the 158 ABNF rules and need not match the left margin of the document. 160 2.3 Terminal Values 162 Rules resolve into a string of terminal values, sometimes called 163 characters. In ABNF a character is merely a non-negative integer. 164 In certain contexts a specific mapping (encoding) of values into a 165 character set (such as ASCII) will be specified. 167 Terminals are specified by one or more numeric characters with the 168 base interpretation of those characters indicated explicitly. The 169 following bases are currently defined: 171 b = binary 173 d = decimal 175 x = hexadecimal 177 Hence: 179 CR = %d13 181 CR = %x0D 182 respectively specify the decimal and hexadecimal representation of 183 [US-ASCII] for carriage return. 185 A concatenated string of such values is specified compactly, using a 186 period (".") to indicate separation of characters within that value. 187 Hence: 189 CRLF = %d13.10 191 ABNF permits specifying literal text string directly, enclosed in 192 quotation-marks. Hence: 194 command = "command string" 196 Literal text strings are interpreted as a concatenated set of 197 printable characters. 199 NOTE: 201 ABNF strings are case-insensitive and the character set for these 202 strings is us-ascii. 204 Hence: 206 rulename = "abc" 208 and: 210 rulename = "aBc" 211 will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC". 213 To specify a rule which IS case SENSITIVE, specify the characters 214 individually. 216 For example: 218 rulename = %d97 %d98 %d99 220 or 222 rulename = %d97.98.99 223 will match only the string which comprises only lowercased 224 characters, abc. 226 2.4 External Encodings 228 External representations of terminal value characters will vary 229 according to constraints in the storage or transmission environment. 230 Hence, the same ABNF-based grammar may have multiple external 231 encodings, such as one for a 7-bit US-ASCII environment, another for 232 a binary octet environment and still a different one when 16-bit 233 Unicode is used. Encoding details are beyond the scope of ABNF, 234 although Appendix A (Core) provides definitions for a 7-bit US-ASCII 235 environment as has been common to much of the Internet. 237 By separating external encoding from the syntax, it is intended that 238 alternate encoding environments can be used for the same syntax. 240 3. OPERATORS 242 3.1 Concatenation: Rule1 Rule2 244 A rule can define a simple, ordered string of values -- i.e., a 245 concatenation of contiguous characters -- by listing a sequence of 246 rule names. For example: 248 foo = %x61 ; a 250 bar = %x62 ; b 252 mumble = foo bar foo 254 So that the rule matches the lowercase string "aba". 256 LINEAR WHITE SPACE: Concatenation is at the core of the ABNF 257 parsing model. A string of contiguous characters (values) is 258 parsed according to the rules defined in ABNF. For Internet 259 specifications, there is some history of permitting linear white 260 space (space and horizontal tab) to be freely and implicitly 261 interspersed around major constructs, such as delimiting special 262 characters or atomic strings. 264 NOTE: 266 NOTE: This specification for ABNF does not provide for implicit 267 specification of linear white space. 269 Any grammar which wishes to permit linear white space around 270 delimiters or string segments must specify it explicitly. It is 271 often useful to provide for such white space in "core" rules that are 272 then used variously among higher-level rules. The "core" rules might 273 be formed into a lexical analyzer or simply be part of the main 274 ruleset. 276 3.2 Alternatives: Rule1 / Rule2 278 Elements separated by forward slash ("/") are alternatives. 279 Therefore, 281 foo / bar 282 will accept or . 284 NOTE: 286 A quoted string containing alphabetic characters is special form 287 for specifying alternative characters and is interpreted as a 288 non-terminal representing the set of combinatorial strings with 289 the contained characters, in the specified order but with any 290 mixture of upper and lower case.. 292 3.3 Incremental Alternatives: Rule1 =/ Rule2 294 It is sometimes convenient to specify a list of alternatives in 295 fragments. That is, an initial rule may match one or more 296 alternatives, with later rule definitions adding to the set of 297 alternatives. This is particularly useful for otherwise- independent 298 specifications which derive from the same parent rule set, such as 299 often occurs with parameter lists. ABNF permits this incremental 300 definition through the construct: 302 oldrule =/ additional-alternatives 304 So that the rule set 306 ruleset = alt1 / alt2 308 ruleset =/ alt3 310 ruleset =/ alt4 / alt5 312 is the same as specifying 314 ruleset = alt1 / alt2 / alt3 / alt4 / alt5 316 3.4 Value Range Alternatives: %c##-## 318 A range of alternative numeric values can be specified compactly, 319 using dash ("-") to indicate the range of alternative values. Hence: 321 DIGIT = %x30-39 323 is equivalent to: 325 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 327 "7" / "8" / "9" 329 Concatenated numeric values and numeric value ranges can not be 330 specified in the same string. A numeric value may use the dotted 331 notation for concatenation or it may use the dash notation to specify 332 one value range. Hence, to specify one printable character, between 333 end of line sequences, the specification could be: 335 char-line = %x0D.0A %x20-7E %x0D.0A 337 3.5 Sequence Group: (Rule1 Rule2) 339 Elements enclosed in parentheses are treated as a single element, 340 whose contents are STRICTLY ORDERED. Thus, 342 elem (foo / bar) blat 343 which matches (elem foo blat) or (elem bar blat). 345 elem foo / bar blat 346 matches (elem foo) or (bar blat). 348 NOTE: 350 It is strongly advised to use grouping notation, rather than to 351 rely on proper reading of "bare" alternations, when alternatives 352 consist of multiple rule names or literals. 354 Hence it is recommended that instead of the above form, the form: 356 (elem foo) / (bar blat) 357 be used. It will avoid misinterpretation by casual readers. 359 The sequence group notation is also used within free text to set off 360 an element sequence from the prose. 362 3.6 Variable Repetition: *Rule 364 The operator "*" preceding an element indicates repetition. The full 365 form is: 367 *element 368 where and are optional decimal values, indicating at least 369 and at most occurrences of element. 371 Default values are 0 and infinity so that * allows any 372 number, including zero; 1* requires at least one; 373 3*3 allows exactly 3 and 1*2 allows one or two. 375 3.7 Specific Repetition: nRule 377 A rule of the form: 379 element 381 is equivalent to 383 *element 385 That is, exactly occurrences of . Thus 2DIGIT is a 386 2-digit number, and 3ALPHA is a string of three alphabetic 387 characters. 389 3.8 Optional Sequence: [RULE] 391 Square brackets enclose an optional element sequence: 393 [foo bar] 395 is equivalent to 397 *1(foo bar). 399 3.9 Comment: ; Comment 401 A semi-colon starts a comment that continues to the end of line. 402 This is a simple way of including useful notes in parallel with the 403 specifications. 405 3.10 Operator Precedence 407 The various mechanisms described above have the following precedence, 408 from highest (binding tightest) at the top, to lowest and loosest at 409 the bottom: 411 Strings, Names formation 413 Comment 415 Value range 417 Repetition 419 Grouping, Optional 421 Concatenation 423 Alternative 425 Use of the alternative operator, freely mixed with concatenations can 426 be confusing. 428 Again, it is recommended that the grouping operator be used to 429 make explicit concatenation groups. 431 4. ABNF DEFINITION OF ABNF 433 NOTES: 435 1. This syntax requires formatting of rules that is relatively 436 strict. Hence the version of a ruleset included in a 437 specification might need preprocessing, to ensure that it can 438 be interpreted by an ABNF parser. 440 2. This syntax uses the rules provided in Appendix B (Core). 442 rulelist = 1*( rule / (*c-wsp c-nl) ) 444 rule = rulename defined-as elements c-nl 445 ; continues if next line starts 446 ; with white space 448 rulename = ALPHA *(ALPHA / DIGIT / "-") 450 defined-as = *c-wsp ("=" / "=/") *c-wsp 451 ; basic rules definition and 452 ; incremental alternatives 454 elements = alternation *c-wsp 456 c-wsp = WSP / (c-nl WSP) 457 c-nl = comment / CRLF 458 ; comment or newline 460 comment = ";" *(WSP / VCHAR) CRLF 462 alternation = concatenation 463 *(*c-wsp "/" *c-wsp concatenation) 465 concatenation = repetition *(1*c-wsp repetition) 467 repetition = [repeat] element 469 repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) 471 element = rulename / group / option / 472 char-val / num-val / prose-val 474 group = "(" *c-wsp alternation *c-wsp ")" 476 option = "[" *c-wsp alternation *c-wsp "]" 478 char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 479 ; quoted string of SP and VCHAR 480 ; without DQUOTE 482 num-val = "%" (bin-val / dec-val / hex-val) 484 bin-val = "b" 1*BIT 485 [ 1*("." 1*BIT) / ("-" 1*BIT) ] 486 ; series of concatenated bit values 487 ; or single ONEOF range 489 dec-val = "d" 1*DIGIT 490 [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] 492 hex-val = "x" 1*HEXDIG 493 [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] 495 prose-val = "<" *(%x20-3D / %x3F-7E) ">" 496 ; bracketed string of SP and VCHAR 497 ; without angles 498 ; prose description, to be used as 499 ; last resort 501 5. SECURITY CONSIDERATIONS 503 Security is truly believed to be irrelevant to this document. 505 6. References 507 6.1 Normative 509 [US-ASCII] 510 American National Standards Institute, "Coded Character 511 Set -- 7-bit American Standard Code for Information 512 Interchange", ANSI X3.4, 1986. 514 6.2 Descriptive 516 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 517 Specifications: ABNF", RFC 2234, November 1997. 519 [RFC733] Crocker, D., Vittal, J., Pogran, K. and D. Henderson, 520 "Standard for the format of ARPA network text messages", 521 RFC 733, November 1977. 523 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 524 text messages", STD 11, RFC 822, August 1982. 526 Authors' Addresses 528 Dave Crocker (editor) 529 Brandenburg InternetWorking 530 675 Spruce Dr. 531 Sunnyvale, CA 94086 532 US 534 Phone: +1.408.246.8253 535 Email: dcrocker@bbiw.net 537 Paul Overell 538 Demon Internet Ltd. 539 Dorking Business Park 540 Dorking 541 Surrey, England RH4 1HN 542 UK 544 Email: paulo@turnpike.com 546 Appendix A. ACKNOWLEDGEMENTS 548 The syntax for ABNF was originally specified in RFC 733. Ken L. 549 Harrenstien, of SRI International, was responsible for re-coding the 550 BNF into an augmented BNF that makes the representation smaller and 551 easier to understand. 553 This recent project began as a simple effort to cull out the portion 554 of RFC 822 which has been repeatedly cited by non-email specification 555 writers, namely the description of augmented BNF. Rather than simply 556 and blindly converting the existing text into a separate document, 557 the working group chose to give careful consideration to the 558 deficiencies, as well as benefits, of the existing specification and 559 related specifications available over the last 15 years and therefore 560 to pursue enhancement. This turned the project into something rather 561 more ambitious than first intended. Interestingly the result is not 562 massively different from that original, although decisions such as 563 removing the list notation came as a surprise. 565 This "separated" version of the specification was part of the DRUMS 566 working group, with significant contributions from Jerome Abela , 567 Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom 568 Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman , Pete 569 Resnick and Henning Schulzrinne. 571 Julian Reschke warrants special thanks, for converting the Draft 572 Standard version to XML source form. 574 Appendix B. APPENDIX - CORE ABNF OF ABNF 576 This Appendix is provided as a convenient core for specific grammars. 577 The definitions may be used as a core set of rules. 579 B.1 Core Rules 581 Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT, 582 ALPHA, etc. 584 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 586 BIT = "0" / "1" 588 CHAR = %x01-7F 589 ; any 7-bit US-ASCII character, 590 ; excluding NUL 592 CR = %x0D 593 ; carriage return 595 CRLF = CR LF 596 ; Internet standard newline 598 CTL = %x00-1F / %x7F 599 ; controls 601 DIGIT = %x30-39 602 ; 0-9 604 DQUOTE = %x22 605 ; " (Double Quote) 607 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 609 HTAB = %x09 610 ; horizontal tab 612 LF = %x0A 613 ; linefeed 615 LWSP = *(WSP / CRLF WSP) 616 ; linear white space (past newline) 618 OCTET = %x00-FF 619 ; 8 bits of data 621 SP = %x20 623 VCHAR = %x21-7E 624 ; visible (printing) characters 626 WSP = SP / HTAB 627 ; white space 629 B.2 Common Encoding 631 Externally, data are represented as "network virtual ASCII", namely 632 7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to 633 zero. A string of values is in "network byte order" with the 634 higher-valued bytes represented on the left-hand side and being sent 635 over the network first. 637 Intellectual Property Statement 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org. 661 Disclaimer of Validity 663 This document and the information contained herein are provided on an 664 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 665 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 666 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 667 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 668 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 669 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 671 Copyright Statement 673 Copyright (C) The Internet Society (2005). This document is subject 674 to the rights, licenses and restrictions contained in BCP 78, and 675 except as set forth therein, the authors retain all their rights. 677 Acknowledgment 679 Funding for the RFC Editor function is currently provided by the 680 Internet Society.