idnits 2.17.1 draft-ietf-crisp-iris-beep-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 526. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 542), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 13, 2004) is 7226 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) == Unused Reference: '10' is defined on line 447, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-core-05 ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 3280 (ref. '10') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3023 (ref. '11') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3268 (ref. '13') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '15') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3205 (ref. '16') (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '18') (Obsoleted by RFC 9110) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Newton 2 Internet-Draft VeriSign, Inc. 3 Expires: January 11, 2005 M. Sanz 4 DENIC eG 5 July 13, 2004 7 IRIS - Using the Internet Registry Information Service (IRIS) over 8 the Blocks Extensible Exchange Protocol (BEEP) 9 draft-ietf-crisp-iris-beep-07 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 January 11, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document specifies how to use the Blocks Extensible Exchange 43 Protocol (BEEP) as the application transport substrate for the 44 Internet Registry Information Service (IRIS). 46 Table of Contents 48 1. Introduction and Motivations . . . . . . . . . . . . . . . . . 3 49 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 50 3. BEEP Profile Identification . . . . . . . . . . . . . . . . . 5 51 4. IRIS Message Packages . . . . . . . . . . . . . . . . . . . . 6 52 5. IRIS Message Patterns . . . . . . . . . . . . . . . . . . . . 7 53 5.1 Registry Dependent Patterns . . . . . . . . . . . . . . . 7 54 5.2 Default Pattern . . . . . . . . . . . . . . . . . . . . . 7 55 6. Server Authentication Methods . . . . . . . . . . . . . . . . 8 56 6.1 Registry Dependent Methods . . . . . . . . . . . . . . . . 8 57 6.2 Basic Server Authentication Method . . . . . . . . . . . . 8 58 7. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 9 59 7.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.2 Application Protocol Label . . . . . . . . . . . . . . . . 9 61 7.3 Allowable Character Sets . . . . . . . . . . . . . . . . . 9 62 7.4 BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1 BEEP Profile Registration . . . . . . . . . . . . . . . . 10 65 8.2 URI Scheme Registration . . . . . . . . . . . . . . . . . 10 66 8.3 Well-known TCP Port Registration . . . . . . . . . . . . . 11 67 8.4 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 11 68 9. Registry Definition Checklist . . . . . . . . . . . . . . . . 12 69 10. Internationalization Considerations . . . . . . . . . . . . 13 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 71 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 74 13.2 Informative References . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . 18 78 1. Introduction and Motivations 80 The proposal in this document describes the IRIS [6] application 81 transport binding using BEEP [2]. Requirements for IRIS and the 82 specification in this document are outlined in CRISP [19]. 84 The choice of BEEP as the transport substrate is primarily driven by 85 the need to re-use an existing, well-understood protocol with all the 86 necessary features to support the requirements. This gives 87 implementers a wealth of toolkits and debugging gear for use in 88 constructing both servers and clients and allows operators to apply 89 existing experience in issues of deployment. It is also felt that 90 the construction of a simple application transport for the specific 91 purpose of IRIS would yield a similar, though likely smaller and 92 probably less complete, standard after taking into consideration such 93 matters as framing, authentication, etc. 95 Precedents for using other transport mechanisms in layered 96 applications do not seem to fit with the design goals of IRIS. HTTP 97 [15] offers many features employed for use by similar applications. 98 However, it is not the intention of IRIS to be put to such uses as 99 by-passing fire-walls, co-mingling URI schemes, or any other such 100 methods which might lead to confusion between IRIS and traditional 101 World Wide Web applications. Beyond adhering to the guidelines 102 spelled out in RFC3205 [16], the use of HTTP also offers many other 103 challenges that quickly erode its appeal. For example, the 104 appropriate use of TLS [4] with HTTP is defined by RFC2817 [14], but 105 the common use as described in RFC2818 [18] is usually the only 106 method in most implementations. 108 Finally, the use of IRIS directly over TCP, such as that specified by 109 EPP-TCP [17], does not offer the client negotiation characteristics 110 needed by a referral application where a single client, in the act of 111 processing a query, may traverse multiple servers operating with 112 different parameters. 114 2. Document Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC2119 [5]. 120 3. BEEP Profile Identification 122 The BEEP profile identifier for IRIS is a URI composed of the IRIS 123 schema URN, followed by a slash, followed by an IRIS registry type 124 (which is a URN). 126 In the use of this profile identifier, the IRIS schema MUST be 127 abbreviated according to the rules of IRIS. This is possible because 128 the IRIS schema URN is compliant with XML_URN [20]. 130 The registry type URN MUST be abbreviated according to the rules of 131 IRIS (see [6]). This is possible because the registry type URN is 132 compliant with XML_URN [20]. 134 The following is an example of an IRIS profile identifier for BEEP. 135 It identifies the version of IRIS to match that specified by 136 "urn:iana:params:xml:ns:iris1" with a registry type URN of 137 "urn:iana:params:xml:ns:dreg1". 139 http://iana.org/beep/iris1/dreg1 141 The full ABNF [8] with certain values included from IRIS [6] follows. 143 profile = profile-uri "/" iris-urn-abbrev 144 "/" registry-urn-abbrev 145 profile-uri = "http://iana.org/beep/" 146 iris-urn-abbrev = // as specified by IRIS 147 registry-urn-abbrev = // as specified by IRIS 149 This URI is used in the "profile" element in BEEP during channel 150 creation. According to the rules of BEEP, multiple "profile" 151 elements may be offered thus allowing for a negotiation of the 152 version of IRIS to be used for every registry type being served. 154 Once this profile is accepted and the channel is created, the state 155 of the channel is considered ready to exchange IRIS messages. A 156 server MUST honor queries for all advertised registry types on any 157 channel opened with an IRIS profile URI. 159 4. IRIS Message Packages 161 The BEEP profile for IRIS transmits XML [1] containing the requests 162 and responses for IRIS registries. These XML instances MUST be 163 encoded as Unicode [9] using the media-type of "application/xml" 164 according to RFC3023 [11]. 166 XML processors are obliged to recognize both UTF-8 and UTF-16 [9] 167 encodings. XML provides for mechanisms to identify and use other 168 character encodings by means of the "encoding" attribute in the 169 declaration. Absence of this attribute or a byte order mark (BOM) 170 means a default of UTF-8 encoding. Thus, for compatibility reasons, 171 and per RFC 2277 [12], use of UTF-8 is RECOMMENDED with this 172 transport mapping. UTF-16 is OPTIONAL. Other encodings MUST NOT be 173 used. 175 A registry type MAY define other message packages that are not IRIS 176 XML instances (e.g. binary images referenced by an IRIS response). 178 5. IRIS Message Patterns 180 5.1 Registry Dependent Patterns 182 Because each registry type is defined by a separate BEEP profile (see 183 [6]), each registry type MAY define a different message pattern. 184 These patterns MUST be within the allowable scope of BEEP [2]. If a 185 registry type does not explicitly define a message pattern, the 186 default pattern is used (see Section 5.2). 188 However, each registry type MUST be capable of supporting the default 189 pattern (Section 5.2) for use with the query in IRIS. 191 5.2 Default Pattern 193 The default BEEP profile for IRIS only has a one-to-one request/ 194 response message pattern. This exchange involves sending an IRIS XML 195 instance, which results in a response of an IRIS XML instance. 197 The request is sent by the client using an "MSG" message containing a 198 valid IRIS XML instance. The server responds with an "RPY" message 199 containing a valid IRIS XML instance. The "ERR" message is used for 200 sending fault codes. The list of allowable fault codes is listed in 201 BEEP [2]. 203 6. Server Authentication Methods 205 6.1 Registry Dependent Methods 207 When using the TLS [4] tuning profile in BEEP, it is possible to 208 verify the authenticity of the server. However, a convention is 209 needed to conduct this authentication. This convention dictates the 210 name of the authority used by a client to ask for authentication 211 credentials so that the server knows which set of credentials to pass 212 back. Because this is dependent on the authority component of the 213 URI, each registry type SHOULD define a server authentication method. 215 If a registry type does not explicitly define a server authentication 216 method, the basic server authentication method (Section 6.2) is used. 218 6.2 Basic Server Authentication Method 220 The basic server authentication method is as follows: 221 1. When connecting to a server, the client MUST present the name of 222 the authority to the server using the BEEP [2] serverName 223 mechanism. For instance, if the URI "iris:dreg1//com/domain/ 224 example.com" is being resolved, the client would use the 225 serverName="com" attribute during the BEEP session instantiation. 226 2. During TLS negotiation, the server presents to the client a 227 certificate for the authority given in serverName. This 228 certificate MUST be an X.509 certificate [10]. This certificate 229 MUST contain the authority in either the subjectDN or the 230 subjectAltName extension of type dNSName. 231 3. The certificate MUST be cryptographically verified according to 232 the procedures of TLS. 233 4. The client then checks the subject of the certificate in the 234 following order for a case insensitive match: 235 1. Any of the dNSName types in the subjectAltName. 236 2. The subjectDN consisting solely of 'dc' components where each 237 'dc' component represents a label from the authority name 238 (e.g. example.com is dc=example, dc=com). 239 3. A subjectDN where the left-most component is a 'cn' component 240 containing the name of the authority. A wildcard character 241 ('*') MAY be used as teh left-most label of the name in the 242 'cn' component. 243 If the subject of the certificate does not match any of these 244 name components, then the certificate is invalid for representing 245 the authority. 247 7. IRIS Transport Mapping Definitions 249 This section lists the definitions required by IRIS [6] for transport 250 mappings. 252 7.1 URI Scheme 254 The URI scheme name specific to BEEP over IRIS MUST be "iris.beep". 256 7.2 Application Protocol Label 258 The application protocol label MUST be "iris.beep". 260 7.3 Allowable Character Sets 262 See Section 4 and Section 10. 264 7.4 BEEP Mapping 266 The mapping of IRIS in this document is specific to RFC 3080 [2]. 267 This mapping MUST use TCP as specified by RFC 3081 [3]. 269 8. Registrations 271 8.1 BEEP Profile Registration 273 Profile Identification: http://iana.org/beep/iris1 275 Messages exchanged during Channel Creation: none 277 Messages starting one-to-one exchanges: IRIS XML instance 279 Messages in positive replies: IRIS XML instance 281 Messages in negative replies: none 283 Messages in one-to-many exchanges: none 285 Message Syntax: IRIS XML instances as defined by IRIS [6]. 287 Message Semantics: request/response exchanges as defined by IRIS [6]. 289 Contact Information: Andrew Newton and Marcos Sanz 290 292 8.2 URI Scheme Registration 294 URL scheme name: iris.beep 296 URL scheme syntax: defined in Section 7.1 and [6]. 298 Character encoding considerations: as defined in RFC2396 [7]. 300 Intended usage: identifies an IRIS entity made available using the 301 BEEP profile for IRIS 303 Applications using this scheme: defined in IRIS [6]. 305 Interoperability considerations: n/a 307 Security Considerations: defined in Section 12. 309 Relevant Publications: BEEP [2] and IRIS [6]. 311 Contact Information: Andrew Newton and Marcos Sanz 312 314 Author/Change controller: the IESG 316 8.3 Well-known TCP Port Registration 318 Protocol Number: TCP 320 Message Formats, Types, Opcodes, and Sequences: defined in Section 3, 321 Section 4, and Section 5. 323 Functions: defined in IRIS [6]. 325 Use of Broadcast/Multicast: none 327 Proposed Name: IRIS over BEEP 329 Short name: iris.beep 331 Contact Information: Andrew Newton and Marcos Sanz 332 334 8.4 S-NAPTR Registration 336 Application Protocol Label: iris.beep 338 Intended usage: identifies an IRIS server using BEEP 340 Interoperability considerations: n/a 342 Security Considerations: defined in Section 12. 344 Relevant Publications: BEEP [2] and IRIS [6]. 346 Contact Information: Andrew Newton and Marcos Sanz 347 349 Author/Change controller: the IESG 351 9. Registry Definition Checklist 353 Specifications of registry types MUST include the following explicit 354 definitions: 355 o message pattern - A definition of the message pattern for use with 356 BEEP or a declaration to use the default message pattern in 357 Section 5.2. 358 o server authentication method - A definition of the method to use 359 for server authentication with TLS or a declaration to use the 360 basic server authentication method in Section 6.2 or a declaration 361 to use no server authentication at all. 363 10. Internationalization Considerations 365 See Section 4. 367 11. IANA Considerations 369 Registrations with the IANA are described in Section 8. 371 12. Security Considerations 373 Implementers should be fully aware of the security considerations 374 given by IRIS [6], BEEP [2], and TLS [4]. With respect to server 375 authentication with the use of TLS, see Section 6. 377 Clients SHOULD be prepared to use the following BEEP tuning profiles: 378 o http://iana.org/beep/SASL/DIGEST-MD5 - for user authentication 379 without the need of session encryption. 380 o http://iana.org/beep/SASL/OTP - for user authentication without 381 the need of session encryption. 382 o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 383 cipher - for encryption. 384 o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 385 cipher with client-side certificates - for encryption and user 386 authentication. 387 o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA 388 cipher - for encryption. See [13]. 389 o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA 390 cipher with client-side certificates - for encryption and user 391 authentication. See [13]. 392 o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA 393 cipher - for encryption. See [13]. 394 o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA 395 cipher with client-side certificates - for encryption and user 396 authentication. See [13]. 398 Anonymous client access SHOULD be considered in one of two methods: 399 1. When no authentication tuning profile has been used. 400 2. Using the SASL anonymous profile: 401 http://iana.org/beep/SASL/ANONYMOUS 403 IRIS contains a referral mechanism as a standard course of operation. 404 However, care should be taken that user authentication mechanisms do 405 not hand user credentials to untrusted servers. Therefore, clients 406 SHOULD NOT use the http://iana.org/beep/SASL/PLAIN tuning profile. 407 As specified by SASL/PLAIN, clients MUST NOT use the 408 http://iana.org/beep/SASL/PLAIN tuning profile without first 409 encrypting the TCP session (e.g. such as with the 410 http://iana.org/beep/TLS tuning profile). 412 13. References 414 13.1 Normative References 416 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 417 1.0", W3C XML, February 1998, 418 . 420 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 421 3080, March 2001. 423 [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 424 2001. 426 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 427 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 428 1999. 430 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 431 Levels", RFC 2119, BCP 14, March 1997. 433 [6] Newton, A. and M. Sanz, "Internet Registry Information 434 Service", draft-ietf-crisp-iris-core-05 (work in progress), 435 January 2004. 437 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 438 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 439 1998. 441 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 442 Specifications: ABNF", RFC 2234, November 1997. 444 [9] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 445 0-201-61633-5, 2000, . 447 [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 448 Public Key Infrastructure Certificate and Certificate 449 Revocation List (CRL) Profile", RFC 3280, April 2002. 451 [11] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 452 3023, January 2001. 454 [12] Alvestrand, H., "IETF Policy on Character Sets and Languages", 455 BCP 18, RFC 2277, January 1998. 457 [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 458 Transport Layer Security (TLS)", RFC 3268, June 2002. 460 13.2 Informative References 462 [14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 463 RFC 2817, May 2000. 465 [15] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 466 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 467 HTTP/1.1", RFC 2616, June 1999. 469 [16] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 470 3205, February 2002. 472 [17] Hollenbeck, S., "EPP TCP Transport", Internet Draft, 473 draft-ietf-provreg-epp-tcp-06, January 2002. 475 [18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 477 [19] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 478 Requirements", RFC 3707, February 2004. 480 [20] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, 481 February 2004. 483 Authors' Addresses 485 Andrew L. Newton 486 VeriSign, Inc. 487 21345 Ridgetop Circle 488 Sterling, VA 20166 489 USA 491 Phone: +1 703 948 3382 492 EMail: anewton@verisignlabs.com; andy@hxr.us 493 URI: http://www.verisignlabs.com/ 495 Marcos Sanz 496 DENIC eG 497 Wiesenhuettenplatz 26 498 D-60329 Frankfurt 499 Germany 501 EMail: sanz@denic.de 502 URI: http://www.denic.de/ 504 Intellectual Property Statement 506 The IETF takes no position regarding the validity or scope of any 507 Intellectual Property Rights or other rights that might be claimed to 508 pertain to the implementation or use of the technology described in 509 this document or the extent to which any license under such rights 510 might or might not be available; nor does it represent that it has 511 made any independent effort to identify any such rights. Information 512 on the procedures with respect to rights in RFC documents can be 513 found in BCP 78 and BCP 79. 515 Copies of IPR disclosures made to the IETF Secretariat and any 516 assurances of licenses to be made available, or the result of an 517 attempt made to obtain a general license or permission for the use of 518 such proprietary rights by implementers or users of this 519 specification can be obtained from the IETF on-line IPR repository at 520 http://www.ietf.org/ipr. 522 The IETF invites any interested party to bring to its attention any 523 copyrights, patents or patent applications, or other proprietary 524 rights that may cover technology that may be required to implement 525 this standard. Please address the information to the IETF at 526 ietf-ipr@ietf.org. 528 Disclaimer of Validity 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Copyright Statement 540 Copyright (C) The Internet Society (2004). This document is subject 541 to the rights, licenses and restrictions contained in BCP 78, and 542 except as set forth therein, the authors retain all their rights. 544 Acknowledgment 546 Funding for the RFC Editor function is currently provided by the 547 Internet Society.