idnits 2.17.1 draft-crocker-rfc4234bis-01.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. 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.) -- The draft header indicates that this document obsoletes RFC4234, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 9, 2007) is 6044 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: 'RULE' is mentioned on line 383, but not defined == Unused Reference: 'US-ASCII' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 512, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 13 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: 4234 (if approved) P. Overell 5 Intended status: Standards Track THUS plc. 6 Expires: April 11, 2008 October 9, 2007 8 Augmented BNF for Syntax Specifications: ABNF 9 draft-crocker-rfc4234bis-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Internet technical specifications often need to define a formal 43 syntax. Over the years, a modified version of Backus-Naur Form 44 (BNF), called Augmented BNF (ABNF), has been popular among many 45 Internet specifications. The current specification documents ABNF. 46 It balances compactness and simplicity, with reasonable 47 representational power. The differences between standard BNF and 48 ABNF involve naming rules, repetition, alternatives, order- 49 independence, and value ranges. This specification also supplies 50 additional rule definitions and encoding for a core lexical analyzer 51 of the type common to several Internet specifications. 53 Table of Contents 55 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. RULE DEFINITION . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Rule Naming . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Rule Form . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Terminal Values . . . . . . . . . . . . . . . . . . . . . 4 60 2.4. External Encodings . . . . . . . . . . . . . . . . . . . . 5 61 3. OPERATORS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Concatenation: Rule1 Rule2 . . . . . . . . . . . . . . . 6 63 3.2. Alternatives: Rule1 / Rule2 . . . . . . . . . . . . . . . 6 64 3.3. Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . . 7 65 3.4. Value Range Alternatives: %c##-## . . . . . . . . . . . . 7 66 3.5. Sequence Group: (Rule1 Rule2) . . . . . . . . . . . . . . 8 67 3.6. Variable Repetition: *Rule . . . . . . . . . . . . . . . 8 68 3.7. Specific Repetition: nRule . . . . . . . . . . . . . . . 9 69 3.8. Optional Sequence: [RULE] . . . . . . . . . . . . . . . . 9 70 3.9. Comment: ; Comment . . . . . . . . . . . . . . . . . . . 9 71 3.10. Operator Precedence . . . . . . . . . . . . . . . . . . . 9 72 4. ABNF DEFINITION OF ABNF . . . . . . . . . . . . . . . . . . . 10 73 5. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 11 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Appendix A. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . 12 78 Appendix B. CORE ABNF OF ABNF . . . . . . . . . . . . . . . . . . 13 79 B.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 80 B.2. Common Encoding . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. INTRODUCTION 86 Internet technical specifications often need to define a formal 87 syntax and are free to employ whatever notation their authors deem 88 useful. Over the years, a modified version of Backus-Naur Form 89 (BNF), called Augmented BNF (ABNF), has been popular among many 90 Internet specifications. It balances compactness and simplicity, 91 with reasonable representational power. In the early days of the 92 Arpanet, each specification contained its own definition of ABNF. 93 This included the email specifications, [RFC733] and then [RFC822], 94 which came to be the common citations for defining ABNF. The current 95 document separates those definitions to permit selective reference. 96 Predictably, it also provides some modifications and enhancements. 98 The differences between standard BNF and ABNF involve naming rules, 99 repetition, alternatives, order-independence, and value ranges. 100 Appendix B supplies rule definitions and encoding for a core lexical 101 analyzer of the type common to several Internet specifications. It 102 is provided as a convenience and is otherwise separate from the meta 103 language defined in the body of this document, and separate from its 104 formal status. 106 2. RULE DEFINITION 108 2.1. Rule Naming 110 The name of a rule is simply the name itself; that is, a sequence of 111 characters, beginning with an alphabetic character, and followed by a 112 combination of alphabetics, digits, and hyphens (dashes). 114 NOTE: 116 Rule names are case-insensitive 118 The names , , , and all 119 refer to the same rule. 121 Unlike original BNF, angle brackets ("<", ">") are not required. 122 However, angle brackets may be used around a rule name whenever their 123 presence facilitates in discerning the use of a rule name. This is 124 typically restricted to rule name references in free-form prose, or 125 to distinguish partial rules that combine into a string not separated 126 by white space, such as shown in the discussion about repetition, 127 below. 129 2.2. Rule Form 131 A rule is defined by the following sequence: 133 name = elements crlf 135 where is the name of the rule, is one or more rule 136 names or terminal specifications, and is the end-of-line 137 indicator (carriage return followed by line feed). The equal sign 138 separates the name from the definition of the rule. The elements 139 form a sequence of one or more rule names and/or value definitions, 140 combined according to the various operators defined in this document, 141 such as alternative and repetition. 143 For visual ease, rule definitions are left aligned. When a rule 144 requires multiple lines, the continuation lines are indented. The 145 left alignment and indentation are relative to the first lines of the 146 ABNF rules and need not match the left margin of the document. 148 2.3. Terminal Values 150 Rules resolve into a string of terminal values, sometimes called 151 characters. In ABNF, a character is merely a non-negative integer. 152 In certain contexts, a specific mapping (encoding) of values into a 153 character set (such as ASCII) will be specified. 155 Terminals are specified by one or more numeric characters, with the 156 base interpretation of those characters indicated explicitly. The 157 following bases are currently defined: 159 b = binary 161 d = decimal 163 x = hexadecimal 165 Hence: 167 CR = %d13 169 CR = %x0D 170 respectively specify the decimal and hexadecimal representation of 171 [US-ASCII] for carriage return. 173 A concatenated string of such values is specified compactly, using a 174 period (".") to indicate a separation of characters within that 175 value. Hence: 177 CRLF = %d13.10 179 ABNF permits the specification of literal text strings directly, 180 enclosed in quotation-marks. Hence: 182 command = "command string" 184 Literal text strings are interpreted as a concatenated set of 185 printable characters. 187 NOTE: 189 ABNF strings are case-insensitive and the character set for these 190 strings is us-ascii. 192 Hence: 194 rulename = "abc" 196 and: 198 rulename = "aBc" 200 will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and 201 "ABC". 203 To specify a rule that IS case SENSITIVE, specify the characters 204 individually. 206 For example: 208 rulename = %d97 %d98 %d99 210 or 212 rulename = %d97.98.99 214 will match only the string that comprises only the lowercased 215 characters, abc. 217 2.4. External Encodings 219 External representations of terminal value characters will vary 220 according to constraints in the storage or transmission environment. 221 Hence, the same ABNF-based grammar may have multiple external 222 encodings, such as one for a 7-bit US-ASCII environment, another for 223 a binary octet environment, and still a different one when 16-bit 224 Unicode is used. Encoding details are beyond the scope of ABNF, 225 although Appendix B provides definitions for a 7-bit US-ASCII 226 environment as has been common to much of the Internet. 228 By separating external encoding from the syntax, it is intended that 229 alternate encoding environments can be used for the same syntax. 231 3. OPERATORS 233 3.1. Concatenation: Rule1 Rule2 235 A rule can define a simple, ordered string of values (i.e., a 236 concatenation of contiguous characters) by listing a sequence of rule 237 names. For example: 239 foo = %x61 ; a 241 bar = %x62 ; b 243 mumble = foo bar foo 245 So that the rule matches the lowercase string "aba". 247 LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing 248 model. A string of contiguous characters (values) is parsed 249 according to the rules defined in ABNF. For Internet specifications, 250 there is some history of permitting linear white space (space and 251 horizontal tab) to be freely and implicitly interspersed around major 252 constructs, such as delimiting special characters or atomic strings. 254 NOTE: 256 This specification for ABNF does not provide for implicit 257 specification of linear white space. 259 Any grammar that wishes to permit linear white space around 260 delimiters or string segments must specify it explicitly. It is 261 often useful to provide for such white space in "core" rules that are 262 then used variously among higher-level rules. The "core" rules might 263 be formed into a lexical analyzer or simply be part of the main 264 ruleset. 266 3.2. Alternatives: Rule1 / Rule2 268 Elements separated by a forward slash ("/") are alternatives. 269 Therefore, 270 foo / bar 272 will accept or . 274 NOTE: 276 A quoted string containing alphabetic characters is a special form 277 for specifying alternative characters and is interpreted as a non- 278 terminal representing the set of combinatorial strings with the 279 contained characters, in the specified order but with any mixture 280 of upper and lower case. 282 3.3. Incremental Alternatives: Rule1 =/ Rule2 284 It is sometimes convenient to specify a list of alternatives in 285 fragments. That is, an initial rule may match one or more 286 alternatives, with later rule definitions adding to the set of 287 alternatives. This is particularly useful for otherwise, independent 288 specifications that derive from the same parent rule set, such as 289 often occurs with parameter lists. ABNF permits this incremental 290 definition through the construct: 292 oldrule =/ additional-alternatives 294 So that the rule set 296 ruleset = alt1 / alt2 298 ruleset =/ alt3 300 ruleset =/ alt4 / alt5 302 is the same as specifying 304 ruleset = alt1 / alt2 / alt3 / alt4 / alt5 306 3.4. Value Range Alternatives: %c##-## 308 A range of alternative numeric values can be specified compactly, 309 using dash ("-") to indicate the range of alternative values. Hence: 311 DIGIT = %x30-39 313 is equivalent to: 315 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / 317 "7" / "8" / "9" 319 Concatenated numeric values and numeric value ranges cannot be 320 specified in the same string. A numeric value may use the dotted 321 notation for concatenation or it may use the dash notation to specify 322 one value range. Hence, to specify one printable character between 323 end of line sequences, the specification could be: 325 char-line = %x0D.0A %x20-7E %x0D.0A 327 3.5. Sequence Group: (Rule1 Rule2) 329 Elements enclosed in parentheses are treated as a single element, 330 whose contents are STRICTLY ORDERED. Thus, 332 elem (foo / bar) blat 334 matches (elem foo blat) or (elem bar blat), and 336 elem foo / bar blat 338 matches (elem foo) or (bar blat). 340 NOTE: 342 It is strongly advised that grouping notation be used, rather than 343 relying on the proper reading of "bare" alternations, when 344 alternatives consist of multiple rule names or literals. 346 Hence, it is recommended that the following form be used: 348 (elem foo) / (bar blat) 350 It will avoid misinterpretation by casual readers. 352 The sequence group notation is also used within free text to set off 353 an element sequence from the prose. 355 3.6. Variable Repetition: *Rule 357 The operator "*" preceding an element indicates repetition. The full 358 form is: 360 *element 362 where and are optional decimal values, indicating at least 363 and at most occurrences of the element. 365 Default values are 0 and infinity so that * allows any 366 number, including zero; 1* requires at least one; 367 3*3 allows exactly 3 and 1*2 allows one or two. 369 3.7. Specific Repetition: nRule 371 A rule of the form: 373 element 375 is equivalent to 377 *element 379 That is, exactly occurrences of . Thus, 2DIGIT is a 380 2-digit number, and 3ALPHA is a string of three alphabetic 381 characters. 383 3.8. Optional Sequence: [RULE] 385 Square brackets enclose an optional element sequence: 387 [foo bar] 389 is equivalent to 391 *1(foo bar). 393 3.9. Comment: ; Comment 395 A semi-colon starts a comment that continues to the end of line. 396 This is a simple way of including useful notes in parallel with the 397 specifications. 399 3.10. Operator Precedence 401 The various mechanisms described above have the following precedence, 402 from highest (binding tightest) at the top, to lowest (loosest) at 403 the bottom: 405 Rule name, prose-val, Terminal value 407 Comment 409 Value range 411 Repetition 413 Grouping, Optional 414 Concatenation 416 Alternative 418 Use of the alternative operator, freely mixed with concatenations, 419 can be confusing. 421 Again, it is recommended that the grouping operator be used to 422 make explicit concatenation groups. 424 4. ABNF DEFINITION OF ABNF 426 NOTES: 428 1. This syntax requires a formatting of rules that is relatively 429 strict. Hence, the version of a ruleset included in a 430 specification might need preprocessing to ensure that it can 431 be interpreted by an ABNF parser. 433 2. This syntax uses the rules provided in Appendix B. 435 rulelist = 1*( rule / (*c-wsp c-nl) ) 437 rule = rulename defined-as elements c-nl 438 ; continues if next line starts 439 ; with white space 441 rulename = ALPHA *(ALPHA / DIGIT / "-") 443 defined-as = *c-wsp ("=" / "=/") *c-wsp 444 ; basic rules definition and 445 ; incremental alternatives 447 elements = alternation *c-wsp 449 c-wsp = WSP / (c-nl WSP) 451 c-nl = comment / CRLF 452 ; comment or newline 454 comment = ";" *(WSP / VCHAR) CRLF 456 alternation = concatenation 457 *(*c-wsp "/" *c-wsp concatenation) 459 concatenation = repetition *(1*c-wsp repetition) 460 repetition = [repeat] element 462 repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) 464 element = rulename / group / option / 465 char-val / num-val / prose-val 467 group = "(" *c-wsp alternation *c-wsp ")" 469 option = "[" *c-wsp alternation *c-wsp "]" 471 char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE 472 ; quoted string of SP and VCHAR 473 ; without DQUOTE 475 num-val = "%" (bin-val / dec-val / hex-val) 477 bin-val = "b" 1*BIT 478 [ 1*("." 1*BIT) / ("-" 1*BIT) ] 479 ; series of concatenated bit values 480 ; or single ONEOF range 482 dec-val = "d" 1*DIGIT 483 [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] 485 hex-val = "x" 1*HEXDIG 486 [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] 488 prose-val = "<" *(%x20-3D / %x3F-7E) ">" 489 ; bracketed string of SP and VCHAR 490 ; without angles 491 ; prose description, to be used as 492 ; last resort 494 5. SECURITY CONSIDERATIONS 496 Security is truly believed to be irrelevant to this document. 498 6. References 500 6.1. Normative References 502 [US-ASCII] 503 American National Standards Institute, "Coded Character 504 Set -- 7-bit American Standard Code for Information 505 Interchange", ANSI X3.4, 1986. 507 6.2. Informative References 509 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 510 Specifications: ABNF", RFC 2234, November 1997. 512 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 513 Specifications: ABNF", RFC 4234, October 2005. 515 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 516 "Standard for the format of ARPA network text messages", 517 RFC 733, November 1977. 519 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 520 text messages", STD 11, RFC 822, August 1982. 522 Appendix A. ACKNOWLEDGEMENTS 524 The syntax for ABNF was originally specified in RFC 733. Ken L. 525 Harrenstien, of SRI International, was responsible for re-coding the 526 BNF into an augmented BNF that makes the representation smaller and 527 easier to understand. 529 This recent project began as a simple effort to cull out the portion 530 of RFC 822 that has been repeatedly cited by non-email specification 531 writers, namely the description of augmented BNF. Rather than simply 532 and blindly converting the existing text into a separate document, 533 the working group chose to give careful consideration to the 534 deficiencies, as well as benefits, of the existing specification and 535 related specifications made available over the last 15 years, and 536 therefore to pursue enhancement. This turned the project into 537 something rather more ambitious than was first intended. 538 Interestingly, the result is not massively different from that 539 original, although decisions, such as removing the list notation, 540 came as a surprise. 542 This "separated" version of the specification was part of the DRUMS 543 working group, with significant contributions from Jerome Abela, 544 Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom 545 Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete 546 Resnick, and Henning Schulzrinne. 548 Julian Reschke warrants a special thanks for converting the Draft 549 Standard version to XML source form. 551 Appendix B. CORE ABNF OF ABNF 553 This appendix contains some basic rules that are in common use. 554 Basic rules are in uppercase. Note that these rules are only valid 555 for ABNF encoded in 7-bit ASCII or in characters sets that are a 556 superset of 7-bit ASCII. 558 B.1. Core Rules 560 Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT, 561 ALPHA, etc. 563 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 565 BIT = "0" / "1" 567 CHAR = %x01-7F 568 ; any 7-bit US-ASCII character, 569 ; excluding NUL 571 CR = %x0D 572 ; carriage return 574 CRLF = CR LF 575 ; Internet standard newline 577 CTL = %x00-1F / %x7F 578 ; controls 580 DIGIT = %x30-39 581 ; 0-9 583 DQUOTE = %x22 584 ; " (Double Quote) 586 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 588 HTAB = %x09 589 ; horizontal tab 591 LF = %x0A 592 ; linefeed 594 LWSP = *(WSP / CRLF WSP) 595 ; Use of this linear-white-space rule 596 ; permits lines containing only white 597 ; space that are no longer legal in 598 ; mail headers and have caused 599 ; interoperability problems in other 600 ; contexts. 601 ; Do not use when defining mail 602 ; headers and use with caution in 603 ; other contexts. 605 OCTET = %x00-FF 606 ; 8 bits of data 608 SP = %x20 610 VCHAR = %x21-7E 611 ; visible (printing) characters 613 WSP = SP / HTAB 614 ; white space 616 B.2. Common Encoding 618 Externally, data are represented as "network virtual ASCII" (namely, 619 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to 620 zero. A string of values is in "network byte order", in which the 621 higher-valued bytes are represented on the left-hand side and are 622 sent over the network first. 624 Authors' Addresses 626 Dave Crocker (editor) 627 Brandenburg InternetWorking 628 675 Spruce Dr. 629 Sunnyvale, CA 94086 630 US 632 Phone: +1.408.246.8253 633 Email: dcrocker@bbiw.net 634 Paul Overell 635 THUS plc. 636 1/2 Berkeley Square, 637 99 Berkeley Street 638 Glasgow G3 7HR 639 UK 641 Email: paul.overell@thus.net 643 Full Copyright Statement 645 Copyright (C) The IETF Trust (2007). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights. 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 654 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 655 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 656 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Acknowledgment 685 Funding for the RFC Editor function is provided by the IETF 686 Administrative Support Activity (IASA).