idnits 2.17.1 draft-josefsson-dns-url-13.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (August 5, 2005) is 6839 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) == Unused Reference: '11' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. '7') (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '8') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2538 (ref. '10') (Obsoleted by RFC 4398) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '11') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2673 (ref. '12') (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2717 (ref. '13') (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '15') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. '16') (Obsoleted by RFC 5890, RFC 5891) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft August 5, 2005 4 Expires: February 6, 2006 6 Domain Name System Uniform Resource Identifiers 7 draft-josefsson-dns-url-13 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 6, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document define Uniform Resource Identifiers for Domain Name 41 System resources. 43 See for more information. 45 Table of Contents 47 1. Introduction and Background . . . . . . . . . . . . . . . . . 3 48 2. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. DNS URI Registration . . . . . . . . . . . . . . . . . . . . . 5 50 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 52 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 54 8. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 10 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 57 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 59 A. Revision Changes . . . . . . . . . . . . . . . . . . . . . . . 11 60 A.1 Changes since -06 . . . . . . . . . . . . . . . . . . . . 11 61 A.2 Changes since -07 . . . . . . . . . . . . . . . . . . . . 12 62 A.3 Changes since -08 . . . . . . . . . . . . . . . . . . . . 12 63 A.4 Changes since -09 . . . . . . . . . . . . . . . . . . . . 12 64 A.5 Changes since -10 . . . . . . . . . . . . . . . . . . . . 12 65 A.6 Changes since -11 . . . . . . . . . . . . . . . . . . . . 12 66 A.7 Changes since -12 . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . 14 69 1. Introduction and Background 71 The Domain Name System (DNS) [1] [2] is a widely deployed system used 72 to, among other things, translate host names into IP addresses. 73 Several protocols are using Uniform Resource Identifier (URI) to 74 refer to data. By defining a URI scheme for DNS data, the gap 75 between these two worlds are bridged. The DNS URI scheme defined 76 here can be used to reference any data stored in the DNS. 78 Data browsers may support DNS URIs by forming DNS queries and render 79 DNS responses using HTML [14], similar to what is commonly done for 80 FTP [6] resources. Applications that are Multipurpose Internet Mail 81 Extension (MIME) [7] aware may tag DNS data retrieve using this 82 scheme with the text/dns or application/dns types as specified in 83 [18]. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [3]. 89 2. Usage Model 91 The reader is referred to section 1 of [5] for an in-depth discussion 92 of URI classifications. In particular, the reader is assumed to be 93 familiar with the "name" vs "locator" distinction. This section 94 describe how the DNS URI scheme is intended to be used, and outline 95 future work that may be required to use URIs with the DNS for some 96 applications. 98 The URI scheme described in this document focus on the data stored in 99 the DNS. As such, there is no provision to specify any of the fields 100 in the actual DNS protocol. This is intentional, so that the URI may 101 be used even in situations where the DNS protocol is not used 102 directly. Two examples for this is zone file editors and DNS-related 103 configuration files, which may use this URI scheme to identify data. 104 The application would not use the DNS protocol to resolve the URIs. 106 A limitation of this design is that it do not accommodate all 107 protocol parameters within the DNS protocol. It is expected that for 108 certain applications, a more detailed URI syntax that map more 109 closely to the DNS protocol may be required. However, such an URI 110 definition is not included in this document. This document specify a 111 URI that is primarily intended to name DNS resources, but it can also 112 be used to locate said resources for simple (but common) 113 applications. 115 3. DNS URI Registration 117 The section contain the registration template for the DNS URI scheme 118 in accordance with [13]. 120 URL scheme name: "dns". 122 URL scheme syntax: A DNS URI designate a DNS resource record set, 123 referenced by domain name, class, type and optionally the authority. 124 The DNS URI follows the generic syntax from RFC 3986 [5], and is 125 described using ABNF [4]. Strings are not case sensitive and free 126 insertion of linear-white-space is not permitted. 128 dnsurl = "dns:" [ "//" dnsauthority "/" ] 129 dnsname ["?" dnsquery] 131 dnsauthority = host [ ":" port ] 132 ; See RFC 3986 for the 133 ; definition of "host" and "port". 135 dnsname = *pchar 136 ; See RFC 3986 for the 137 ; definition of "pchar". 139 ; The "dnsname" field may be a 140 ; "relative" or "absolute" name, 141 ; as per RFC 1034 section 3.1. 143 ; Note further that an empty 144 ; "dnsname" value is to be 145 ; interpreted as the root itself. 146 ; See below on relative dnsname's. 148 dnsquery = dnsqueryelement [";" dnsquery] 150 dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval ) 151 ; Each clause MUST NOT be used more 152 ; than once. 154 dnsclassval = 1*digit / "IN" / "CH" / 155 157 dnstypeval = 1*digit / "A" / "NS" / "MD" / 158 160 Unless specified in the URI, the authority ("dnsauthority") is 161 assumed to be locally known, the class ("dnsclassval") to be the 162 Internet class ("IN"), and the type ("dnstypeval") to be the Address 163 type ("A"). These default values match the typical use of DNS; to 164 look up addresses for host names. 166 A dnsquery element MUST NOT contain more than one occurance of the 167 "CLASS" and "TYPE" fields. For example, both "dns: 168 example?TYPE=A;TYPE=TXT" and "dns:example?TYPE=A;TYPE=A" are invalid. 169 However, the fields may occur in any order, so that both "dns: 170 example?TYPE=A;CLASS=IN" and "dns:example?CLASS=IN;TYPE=A" are valid. 172 The digit representation of types and classes MAY be used when a 173 mnemonic for the corresponding value is not well known (e.g., for 174 newly introduced types or classes), but SHOULD NOT be used for the 175 types or classes defined in the DNS specification [2]. All 176 implementations MUST recognize the mnemonics defined in [2]. 178 To avoid ambiguity, relative "dnsname" values (i.e., those not ending 179 with ".") are assumed to be relative to the root. For example, "dns: 180 host.example" and "dns:host.example." both refer to the same owner 181 name, namely "host.example.". Further, an empty "dnsname" value is 182 considered to be a degenerative form of a relative name, which refer 183 to the root ("."). 185 To resolve a DNS URI using the DNS protocol [2] a query is created, 186 using as input the dnsname, dnsclassval and dnstypeval from the URI 187 string (or the appropriate default values). If an authority 188 ("dnsauthority") is given in the URI string, this indicate the server 189 that should receive the DNS query, otherwise the default DNS server 190 should receive it. 192 Note that DNS URIs could be resolved by other protocols than the DNS 193 protocol, or by using the DNS protocol in some other way than as 194 described above (e.g., multicast DNS). DNS URIs do not require the 195 use of the DNS protocol, although it is expected to be the typical 196 usage. The previous paragraph only illustrate how DNS URIs are 197 resolved using the DNS protocol. 199 A client MAY want to check that it understands the dnsclassval and 200 dnstypeval before sending a query, so that it will be able to 201 understand the response. However, a typical example of a client that 202 would not need to check dnsclassval and dnstypeval would be a proxy, 203 that would just treat the received answer as opaque data. 205 Character encoding considerations: The characters are encoded as per 206 RFC 3986 [5]. The DNS protocol do not consider character sets, it 207 simply transports opaque data. In particular, the "dnsname" field of 208 the DNS URI is to be considered an internationalized domain name 209 (IDN) unaware domain name slot, in the terminology of [16]. The 210 considerations for "host" and "port" are discussed in [5] 211 Because "." is used as the DNS label separator, an escaping mechanism 212 is required to encode a "." that is part of a DNS label. The 213 escaping mechanism is described in section 5.1 of RFC 1035. For 214 example, a DNS label of "exa.mple" can be escaped as "exa\.mple" or 215 "exa\046mple". However, the URI specification disallow the "\" 216 character from occuring directly in URIs, so it must be escaped as 217 "%5c". The single DNS label "exa.mple" is thus encoded as "exa% 218 5c.mple". The same mechanism can be used to encode other characters, 219 for example "?" and ";". Note that "." and "%2e" are equivalent 220 within dnsname, and are interchangable. 222 This URI specification allows all possible domain names to be encoded 223 (of course following the encoding rules of [5]), however certain 224 applications may restrict the set of valid characters. Care should 225 be taken so that invalid characters in these contexts does not cause 226 harm. In particular, host names in the DNS have certain 227 restrictions. It is up to these application to limit this subset, 228 this URI scheme places no restrictions. 230 Intended usage: Whenever DNS resources are useful to reference by 231 protocol independent identifiers, often when the data is more 232 important than the access method. Since software in general has 233 coped without this so far, it is not anticipated to be implemented 234 widely, nor migrated to by existing systems, but specific solutions 235 (especially security related) may find this appropriate. 237 Applications and/or protocols which use this scheme: Security related 238 software. DNS administration tools. Network programming packages. 240 Interoperability considerations: The data referenced by this URI 241 scheme might be transferred by protocols that are not URI aware (such 242 as the DNS protocol). This is not anticipated to have any serious 243 interoperability impact though. 245 Interoperability problems may occur if one entity understands a new 246 DNS class/type mnemonic and another entity do not understand it. 247 This is an interoperability problem for DNS software in general, 248 although it is not a major practical problem as the DNS types and 249 classes are fairly static. To guarantee interoperability 250 implementations can use integers for all mnemonics not defined in 251 [2]. 253 Interaction with Binary Labels [12], or other extended label types, 254 has not been analyzed. However, they appear to be infrequently used 255 in practice. 257 Contact: simon@josefsson.org 258 Author/Change Controller: simon@josefsson.org 260 4. Examples 262 A DNS URI is of the following general form. This is intended to 263 illustrate, not define, the scheme. 265 dns:[//authority/]domain[?CLASS=class;TYPE=type] 267 The following illustrate a URI for a resource with the absolute name 268 "www.example.org.", the Internet (IN) class and the Address (A) type: 270 dns:www.example.org.?clAsS=IN;tYpE=A 272 Since the default class is IN, and the default type is A, the same 273 resource can be identified by a shorter URI, using a relative name: 275 dns:www.example.org 277 The following illustrate a URI for a resource with the name 278 "simon.example.org", for the CERT type, in the Internet (IN) class: 280 dns:simon.example.org?type=CERT 282 The following illustrate a URI for a resource with the name 283 "ftp.example.org", in the Internet (IN) class and the address (A) 284 type, but from the DNS authority 192.168.1.1 instead of the default 285 authority: 287 dns://192.168.1.1/ftp.example.org?type=A 289 The following illustrate various escaping techniques. The owner name 290 would be "world wide web.example\.domain.org" where "\." denote the 291 character "." as part of a label, and "." denote the label separator: 293 dns:world%20wide%20web.example%5c.domain.example?TYPE=TXT 295 The following illustrate a strange, but valid, DNS resource: 297 dns://fw.example.org/*.%20%00.example?type=TXT 299 5. Acknowledgments 301 Thanks to Stuart Cheshire, Donald Eastlake, Pasi Eronen, Bill Fenner, 302 Ted Hardie, Russ Housley, Peter Koch, Andrew Main, Larry Masinter, 303 Michael Mealling, Steve Mattson, Paul Vixie, Sam Weiler, and Bert 304 Wijnen for comments and suggestions. The author acknowledges the RSA 305 Laboratories for supporting the work that led to this document. 307 6. Security Considerations 309 If a DNS URI references domains in the Internet DNS environment, both 310 the URI itself and the information referenced by the URI is public 311 information. If a DNS URI is used within an "internal" DNS 312 environment, both the DNS URI and the data is referenced should be 313 handled using the same considerations that apply to DNS data in the 314 environment. 316 If information referenced by DNS URIs are used to make security 317 decisions (examples of such data include, but is not limited to, 318 certificates stored in the DNS [10]), implementations may need to 319 employ security techniques such as Secure DNS [9], or even CMS [15] 320 or OpenPGP [8], to protect the data during transport. How to 321 implement this will depend on the usage scenario, and it is not up to 322 this URI scheme to define how the data referenced by DNS URIs should 323 be protected. 325 If applications accept unknown dnsqueryelement values (e.g., accepts 326 the URI "dns:www.example.org?secret=value" without knowing what the 327 "secret=value" dnsqueryelement means), a covert channel used to 328 "leak" information may be enabled. The implications of covert 329 channels should be understood by applications that accepts unknown 330 dnsqueryelement values. 332 Slight variations, such as difference between upper and lower case in 333 the dnsname field, can be used as a covert channel to leak 334 information. 336 7. IANA Considerations 338 The IANA is asked to register the DNS URI scheme, using the template 339 in section 3, in accordance with RFC 2717 [13]. 341 8. Copying conditions 343 Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005 Simon Josefsson 345 Regarding this entire document or any portion of it, the author makes 346 no guarantees and is not responsible for any damage resulting from 347 its use. The author grants irrevocable permission to anyone to use, 348 modify, and distribute it in any way that does not diminish the 349 rights of anyone else to use, modify, and distribute it, provided 350 that redistributed derivative works do not contain misleading author 351 or version information. Derivative works need not be licensed under 352 similar terms. 354 9. References 356 9.1 Normative References 358 [1] Mockapetris, P., "Domain names - concepts and facilities", 359 STD 13, RFC 1034, November 1987. 361 [2] Mockapetris, P., "Domain names - implementation and 362 specification", STD 13, RFC 1035, November 1987. 364 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 365 Levels", BCP 14, RFC 2119, March 1997. 367 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 368 Specifications: ABNF", RFC 2234, November 1997. 370 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 371 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 372 January 2005. 374 9.2 Informative References 376 [6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 377 RFC 959, October 1985. 379 [7] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 380 Mail Extensions (MIME) Part Four: Registration Procedures", 381 BCP 13, RFC 2048, November 1996. 383 [8] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 384 "OpenPGP Message Format", RFC 2440, November 1998. 386 [9] Eastlake, D., "Domain Name System Security Extensions", 387 RFC 2535, March 1999. 389 [10] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 390 Domain Name System (DNS)", RFC 2538, March 1999. 392 [11] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, 393 "X.509 Internet Public Key Infrastructure Online Certificate 394 Status Protocol - OCSP", RFC 2560, June 1999. 396 [12] Crawford, M., "Binary Labels in the Domain Name System", 397 RFC 2673, August 1999. 399 [13] Petke, R. and I. King, "Registration Procedures for URL Scheme 400 Names", BCP 35, RFC 2717, November 1999. 402 [14] Connolly, D. and L. Masinter, "The 'text/html' Media Type", 403 RFC 2854, June 2000. 405 [15] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 406 August 2002. 408 [16] Faltstrom, P., Hoffman, P., and A. Costello, 409 "Internationalizing Domain Names in Applications (IDNA)", 410 RFC 3490, March 2003. 412 [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 413 STD 63, RFC 3629, November 2003. 415 [18] Josefsson, S., "Domain Name System Media Types", RFC 4027, 416 April 2005. 418 Author's Address 420 Simon Josefsson 422 Email: simon@josefsson.org 424 Appendix A. Revision Changes 426 Note to RFC editor: Remove this appendix before publication. 428 A.1 Changes since -06 430 The MIME registration templates for text/dns and application/dns was 431 removed, and will be defined in separate documents. 433 Improved discussion related to which mnemonics that must be 434 supported. The interoperability problem that provoked the 435 clarification is also mentioned. 437 Security consideration improvements. 439 A.2 Changes since -07 441 Author/Change Controller changed to author of this document, not 442 IESG. Terminology section collapsed into introduction. The second 443 paragraph of the introduction rewritten and gives explicit examples. 444 Intended usage and applications fields fixed. Moved this revision 445 tracking information to an appendix. Mention IDN in charset section. 446 All previous thanks to suggestions by Larry Masinter. 448 A.3 Changes since -08 450 Modifications derived from Last-Call comments: Made more clear that 451 DNS URIs does not imply use of the DNS protocol, but the issue is not 452 stressed because of the apparent inflamatory state of affairs. Added 453 informative references to HTML and FTP. Clarified that dnsname can 454 be empty. Clarified that first dnsqueryelement "win" in case of 455 ambiguity. Clarified security consideration with respect to unknown 456 dnsqueryelements. Use "authority" instead of "server". Say "IANA 457 registered" instead of "standard". Interoperability note about 458 binary DNS labels. Typos. 460 A.4 Changes since -09 462 Use legal texts from RFC 3667. Update UTF-8 reference to RFC 3629. 463 Simplified introduction. Discuss relative and absolute dnsname's. 464 Clarify that empty dnsname correspond to the root. Change so that 465 dns:foo?TYPE=A;TYPE=TXT is invalid, instead of meaning TYPE=A. The 466 underspecified extension mechanism was dropped; now only TYPE= and 467 CLASS= are permitted. Remove background discussion of why the 468 dnsname field is made a IDN unaware domain name slot. Use standard 469 DNS escaping (i.e, "\." for ".") instead of broken approach that 470 violated the URI specification. Improve examples. Add security 471 considerations. 473 A.5 Changes since -10 475 Add section "Usage Model". Move acknowledgements, as per rfc2223bis. 476 Add permissive copying condition. Updates to align with RFC 3986. 478 A.6 Changes since -11 480 Fix typos. IESG feedback: Move RFC2119 reference to normative 481 section. Replace OCSP example with X.509 CRL Distribution Point 482 extension. Fix ABNF not to use "...". 484 A.7 Changes since -12 486 Reference MIME and RFC 4027. IESG feedback: Do not mention OpenPGP/ 487 X.509 as illustrative examples in the introduction section. 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 518 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 519 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 520 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Copyright Statement 525 Copyright (C) The Internet Society (2005). This document is subject 526 to the rights, licenses and restrictions contained in BCP 78, and 527 except as set forth therein, the authors retain all their rights. 529 Acknowledgment 531 Funding for the RFC Editor function is currently provided by the 532 Internet Society.