idnits 2.17.1 draft-ietf-crisp-iris-lwz-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 649. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 6 has weird spacing: '...for the the I...' == Line 145 has weird spacing: '...esponse descr...' == Line 210 has weird spacing: '...payload types...' == Line 239 has weird spacing: '...s other infor...' == Line 263 has weird spacing: '... 1. In respo...' == (2 more instances...) -- 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 12, 2005) is 6862 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) ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) -- No information found for draft-ietf-crips-iris-common-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '8') Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: January 13, 2006 July 12, 2005 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 13, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a lightweight UDP transfer protocol for the 42 Internet Registry Information Service (IRIS). This transfer protocol 43 uses a single packet for every request and response, and optionally 44 employs compression over the contents of the packet. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 50 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 52 3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5 53 3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6 54 3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6 55 3.1.4 Payload Types . . . . . . . . . . . . . . . . . . . . 7 56 3.1.5 Version Information . . . . . . . . . . . . . . . . . 7 57 3.1.6 Size Information . . . . . . . . . . . . . . . . . . . 8 58 3.1.7 Other Information . . . . . . . . . . . . . . . . . . 8 59 4. Internationalization Considerations . . . . . . . . . . . . . 10 60 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11 61 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 66 6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12 67 6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 71 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 Intellectual Property and Copyright Statements . . . . . . . . 22 75 1. Introduction 77 Using S-NAPTR [4], IRIS has the ability to define the use of multiple 78 application transports or transfer protocols for different types of 79 registry services, all at the descretion of the server operator. The 80 UDP transfer protocol defined in this document is completely modular 81 and may be used by any registry types. 83 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 84 (for IRIS Lightweight using Compression). Its message exchange 85 pattern is simple: a client sends a request in one UDP packet, and a 86 server responds with an answer in one UDP packet. 88 IRIS-LWZ packets are composed of two parts, a binary payload 89 descriptor and an request/response transaction payload. The request/ 90 response transaction payload may be compressed using the DEFLATE [1] 91 algorithm. 93 2. Document Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC2119 [6]. 99 Octet fields with numberic values are given according to the 100 conventions in RFC 1166 [8]: the left most bit of the whole field is 101 the most significant bit; when a multi-octet quantity is transmitted 102 the most significant octet is transmitted first. Bits signifying 103 flags in an octet are numbered according to the conventions of RFC 104 1166 [8]: bit 0 is the most significant bit and bit 7 is the least 105 significant bit. When a diagram describes a group of octets, the 106 order of tranmission for the octets starts from the left. 108 3. Packet Format 110 The UDP packet format for IRIS-LWZ is as follows: 112 +------+------+----------+--------+------------+---------+ 113 field | src | dest | checksum | UDP | payload | payload | 114 | port | port | | length | descriptor | | 115 +------+------+----------+--------+------------+---------+ 116 octets 2 2 2 2 1..261 0..n 118 (where "src port" means source port and "dest port" means destination 119 port). 121 Each IRIS-LWZ query or response is contained in a single UDP packet. 123 3.1 Payload Descriptor 125 The payload descriptor has two different formats, one for a request 126 and one for a response. However, each format shares a common 1 octet 127 payload header described in Section 3.1.3. 129 3.1.1 Payload Request Descriptor 131 The payload descriptor for request packets has the following format: 133 +--------+-------------+----------+-----------+-----------+ 134 field | header | transaction | maximum | authority | authority | 135 | | ID | response | length | | 136 | | | length | | | 137 +--------+-------------+----------+-----------+-----------+ 138 octets 1 2 2 1 0..255 140 These fields have the following meanings: 142 header - as described in Section 3.1.3. 144 transaction ID - a 16 bit value identifying the transaction. This 145 value will be returned in the payload response descriptor 146 (Section 3.1.2) and can be used by clients to match requests with 147 responses. Clients SHOULD pick the value randomly and SHOULD NOT 148 use sequences of 16 bit values. Clients MUST NOT set all the bits 149 in this value to 1 (i.e. use a value of 0xFFFF). 151 maximum response length - the total length of the UDP packet (i.e. 152 UDP header length + payload descriptor length + XML payload 153 length) that should not be exceeded when responding to this 154 request. If the server cannot provide a response that is equal to 155 or less than this value, then it MUST respond with size 156 information (Section 3.1.6). 158 authority length - the length of the authority field in this 159 payload descriptor. 161 authority - a string of octets describing the authority against 162 wich this request is to be executed. See [3] for the definition 163 and description of an authority. The number of octets in this 164 string MUST be no more and no less than the number specified by 165 the authority length. 167 3.1.2 Payload Response Descriptor 169 The payload descriptor for response packets consists of a payload 170 header (Section 3.1.3) and a transaction ID. 172 +--------+-------------+ 173 field | header | transaction | 174 | | ID | 175 +--------+-------------+ 176 octets 1 2 178 The transaction ID MUST be the value of the transaction ID of the 179 corresponding request. If the corresponding request did not contain 180 a transaction ID, servers MUST use a transaction ID with all bits set 181 to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see 182 Section 3.1.7). 184 3.1.3 Payload Header 186 The bits of the payload header are ordered according to RFC 1166 [8], 187 where bit 0 is the most significant and bit 7 is the least 188 significant. Each bit in the one octet payload header has the 189 following meaning: 191 bits 0 and 1 - version number ('V' field) - If 0 (both bits are 192 zero), the protocol is the version defined in this document. 193 Otherwise, the rest of the bits in the header and the payload may 194 be interpreted as another version. 196 bit 2 - request/response flag ('RR' flag) - If 0, this packet is a 197 request (Section 3.1.1) packet. If 1, this packet is a response 198 (Section 3.1.2) packet. 200 bits 3 - payload deflated ('PD' flag) - If 1, the payload is 201 compressed using the DEFLATE [1] algorithm. 203 bit 4 - deflate supported ('DS' flag) - If 1, the sender of this 204 packet supports compression using the DEFLATE algorithm. When 205 this bit is 0 in a request, the payload of the response MUST NOT 206 be compressed with DEFLATE. 208 bit 5 - reserved - This MUST be 0. 210 bits 6 and 7 - The value of these bits indicate payload types 211 (Section 3.1.4) ('PT' field). 213 3.1.4 Payload Types 215 A payload type indicates the type of content in the UDP packet 216 following the payload descriptor. Some payload types have no meaning 217 in request packets, and some payload types differ in meaning between 218 requests and responses. Some payload types indicate an empty 219 payload. 221 The payload type values in binary are as follows: 223 00 - xml payload ('xml' type). The payload is either an IRIS- 224 based XML request or an IRIS-based XML response. 226 01 - version info ('vi' type). In a request packet, this payload 227 type indicates that the server is to respond with version 228 information (Section 3.1.5), and that the payload is empty. In a 229 response packet, this payload type indicates that the payload is 230 version information (Section 3.1.5). 232 10 - size info ('si' type). This payload type has no meaning in a 233 request packet and is a descriptor error. In a response packet, 234 this payload type indicates that the payload is size information 235 (Section 3.1.6). 237 11 - other info ('oi' type). This payload type has no meaning in 238 a request packet and is a descriptor error. In a response packet, 239 this payload type indicates that the payload is other information 240 (Section 3.1.7). 242 3.1.5 Version Information 244 A payload type with version information ('vi') MUST be comformant to 245 the XML defined in [7] and use the element as the root 246 element. 248 In the context of IRIS-LWZ, the protocol identifiers for these 249 elements are as follows: 251 - the value "iris.lwz1" to indicate the 252 protocol specified in this document. 254 - the XML namespace identifier for IRIS [3]. 256 - the XML namespace identifier for IRIS registries. 258 This document defines no extension identifiers and no authentication 259 mechanism identifiers. 261 Servers SHOULD send version information in the following cases: 263 1. In response to a version information request (i.e. the PT flag 264 is set to 'vi'). 266 2. The version in a payload descriptor header does not match a 267 version the server supports. 269 3. The IRIS-based XML payload does not match a version the server 270 supports. 272 The protocols identified by the element MUST only 273 indicate protocols running on the same socket as the sender of the 274 corresponding request. In other words, while a server operator may 275 also be running IRIS-XPC, this XML instance is only intended to 276 describe version negotiation for IRIS-LWZ. 278 The definition of octet size for the 'requestSizeOctets' and 279 'responseSizeOctets' attributes of the element are 280 defined in Section 3.1.6. 282 3.1.6 Size Information 284 A payload type with size information ('si') MUST be comformant to the 285 XML defined in [7] and use the element as the root element. 287 Octet counts provided by this information are defined as the total 288 length of the UDP packet (i.e. UDP header length + payload 289 descriptor length + XML payload length). 291 3.1.7 Other Information 293 A payload type with other information ('oi') MUST be comformant to 294 the XML defined in [7] and use the element as the root 295 element. 297 The values for the 'type' attribute of are as follows: 299 'descriptor-error' - indicates there was an error decoding the 300 descriptor. Servers SHOULD send a descriptor error in the 301 following cases: 303 1. When a request is received with a payload type indicating size 304 information (i.e. the PT flag is 'si'). 306 2. When a request is received with a payload type indicating 307 other information (i.e. the PT flag is 'oi'). 309 3. When a request is sent with an invalid transaction ID. 311 4. When reserved bits in the payload descriptor are set to 312 values other than zero. 314 'payload-error' - indicates there was an error interpretting the 315 payload. Servers MUST send a payload error if they receive XML 316 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 318 'system-error' - indicates that the receiver cannot process the 319 request due to a condition not related to this protocol. Servers 320 SHOULD send a system-error when they are capable of responding to 321 requests but not capable of processing requests. 323 'authority-error' - indicates that the intended authority 324 specified in the corresponding request is not served by the 325 receiver. Servers SHOULD send an authority error when they 326 receive a request directed to an authority other than those they 327 serve. 329 'no-inflation-support-error' - indicates that the receiver does 330 not support payloads that have been compressed with DEFLATE [1]. 331 Servers MUST send this error when they receive a request that has 332 been compressed with DEFLATE but they do not support inflation. 334 4. Internationalization Considerations 336 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 337 encodings. Use of the XML defined by [7] MUST NOT use any other 338 character encodings other than UTF-8 or UTF-16. 340 5. IRIS Transport Mapping Definitions 342 This section lists the definitions required by IRIS [3] for transport 343 mappings. 345 5.1 URI Scheme 347 See Section 6.1.1. 349 5.2 Application Protocol Label 351 See Section 6.1.3. 353 6. IANA Considerations 355 6.1 Registrations 357 6.1.1 URI Scheme Registration 359 URL scheme name: iris.lwz 361 URL scheme syntax: defined in Section 5.1 and [3]. 363 Character encoding considerations: as defined in RFC2396 [5]. 365 Intended usage: identifies an IRIS entity made available using XML 366 over UDP 368 Applications using this scheme: defined in IRIS [3]. 370 Interoperability considerations: n/a 372 Security Considerations: defined in Section 7. 374 Relevant Publications: IRIS [3]. 376 Contact Information: Andrew Newton 378 Author/Change controller: the IESG 380 6.1.2 Well-known UDP Port Registration 382 Protocol Number: UDP 384 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 385 and Section 3.1. 387 Functions: defined in IRIS [3]. 389 Use of Broadcast/Multicast: none 391 Proposed Name: IRIS-LWZ 393 Short name: iris.lwz 395 Contact Information: Andrew Newton 397 6.1.3 S-NAPTR Registration 399 Application Protocol Label (see [4]): iris.lwz 400 Intended usage: identifies an IRIS server using XML over UDP 402 Interoperability considerations: n/a 404 Security Considerations: defined in Section 7. 406 Relevant Publications: IRIS [3]. 408 Contact Information: Andrew Newton 410 Author/Change controller: the IESG 412 7. Security Considerations 414 IRIS-LWZ is intended for serving public data; it provides no in-band 415 mechanisms for authentication or encryption. Any application with 416 this need must provide out of band mechanisms to provide it (e.g., 417 IPSec), or use the IRIS transfer protocols that provides such 418 capabilities. 420 8. Normative References 422 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 423 version 1.3", RFC 1951, May 1996. 425 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 426 ISBN 0-201-61633-5, 2000, . 428 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 429 RFC 3891, January 2004. 431 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 432 Location Using SRV RRs and the Dynamic Delegation Discovery 433 Service (DDDS)", RFC 3958, January 2005. 435 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 436 Resource Identifiers (URI): Generic Syntax", RFC 2396, 437 August 1998. 439 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 440 Levels", RFC 2119, BCP 14, March 1997. 442 [7] Newton, A., "A Common Schema for Internet Registry Information 443 Service Transfer Protocols", 444 draft-ietf-crips-iris-common-transport-00 (work in progress), 445 April 2005. 447 [8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 448 RFC 1166, July 1990. 450 Author's Address 452 Andrew L. Newton 453 VeriSign, Inc. 454 21345 Ridgetop Circle 455 Sterling, VA 20166 456 USA 458 Phone: +1 703 948 3382 459 Email: anewton@verisignlabs.com; andy@hxr.us 460 URI: http://www.verisignlabs.com/ 462 Appendix A. Examples 464 This section gives examples of IRIS-LWZ exchanges. Lines beginning 465 with "C:" denote data sent by the client to the server, and lines 466 beginning with "S:" denote data sent by the server to the client. 467 Following the "C:" or "S:", the line either contains octet values in 468 hexadecimal notation with comments or XML fragments. No line 469 contains both octet values with comments and XML fragments. Comments 470 are contained within parenthesis. 472 The following example demonstrates an IRIS client requesting a lookup 473 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 474 client passes a bag with the search request. The server responds 475 with a 'nameNotFound' response and an explanation. 477 C: (request packet) 478 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 479 C: 0x03 0xA4 (transaction ID=932) 480 C: 0x05 0xDA (maximum response size=1498) 481 C: 0x09 (authority length=9) 482 C: (authority="localhost") 483 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 484 C: (IRIS XML request) 485 C: 487 C: 488 C: 489 C: 490 C: 127.0.0.1:3434 491 C: 4LnQ1KdCahzyvwBqJis5rw== 492 C: 493 C: 494 C: 498 C: 499 C: 501 S: (response packet) 502 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 503 S: 0x03 0xA4 (transaction ID=932) 504 S: (IRIS XML response) 505 S: 506 S: 507 S: 508 S: The name 'AUP' is not found in 'local'. 509 S: 511 Figure 4: Example 1 513 The following example demonstrates an IRIS client requesting domain 514 availability information for 'milo.example.com'. The server responds 515 that the domain is assigned and active. 517 C: (request packet) 518 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 519 C: 0x0B 0xE7 (transaction ID=3047) 520 C: 0x0F 0xA0 (maximum response size=4000) 521 C: 0x0B (authority length=11) 522 C: (authority="example.com") 523 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 524 C: (IRIS XML request) 525 C: 528 C: 529 C: 533 C: 534 C: 536 S: (response packet) 537 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 538 S: 0x0B 0xE7 (transaction ID=3047) 539 S: (IRIS XML response) 540 S: 541 S: 546 S: milo.example.com 547 S: 548 S: 550 Figure 5: Example 2 552 The following example demonstrates an IRIS client requesting domain 553 availability information for felix.example.net, hobbes.example.net, 554 and daffy.example.net. The client does not support responses 555 compressed with DEFLATE and the maximum UDP packet it can safely 556 receive is 498 octets. The server responds with size information 557 indicating that it would take 1211 octets to provide an answer. 559 C: (request packet) 560 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 561 C: 0x7E 0x8A (transaction ID=32394) 562 C: 0x01 0xF2 (maximum response size=498) 563 C: 0x0B (authority length=11) 564 C: (authority="example.net") 565 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 566 C: (IRIS XML request) 567 C: 570 C: 571 C: 573 C: 574 C: 575 C: 577 C: 578 C: 579 C: 581 C: 582 C: 584 S: (response packet) 585 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 586 S: 0x7E 0x8A (transaction ID=32394) 587 S: (Size Information XML response) 588 S: 589 S: 1211 590 S: 592 Figure 6: Example 3 594 The following example illustrates an IRIS client requesting the 595 version information from a server, and the server returning the 596 verion information. 598 C: (request packet) 599 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 600 C: 0x2E 0x9C (transaction ID=11932) 601 C: 0x01 0xF2 (maximum response size=498) 602 C: 0x0B (authority length=11) 603 C: (authority="example.net") 604 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 606 S: (response packet) 607 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 608 S: 0x2E 0x9C (transaction ID=11932) 609 S: (Version Information XML response) 610 S: 611 S: 612 S: 613 S: 614 S: 615 S: 616 S: 617 S: 619 Figure 7: Example 4 621 Appendix B. Contributors 623 Substantive contributions to this document have been provided by the 624 members of the IETF's CRISP Working Group, especially Milena Caires 625 and David Blacka. 627 Intellectual Property Statement 629 The IETF takes no position regarding the validity or scope of any 630 Intellectual Property Rights or other rights that might be claimed to 631 pertain to the implementation or use of the technology described in 632 this document or the extent to which any license under such rights 633 might or might not be available; nor does it represent that it has 634 made any independent effort to identify any such rights. Information 635 on the procedures with respect to rights in RFC documents can be 636 found in BCP 78 and BCP 79. 638 Copies of IPR disclosures made to the IETF Secretariat and any 639 assurances of licenses to be made available, or the result of an 640 attempt made to obtain a general license or permission for the use of 641 such proprietary rights by implementers or users of this 642 specification can be obtained from the IETF on-line IPR repository at 643 http://www.ietf.org/ipr. 645 The IETF invites any interested party to bring to its attention any 646 copyrights, patents or patent applications, or other proprietary 647 rights that may cover technology that may be required to implement 648 this standard. Please address the information to the IETF at 649 ietf-ipr@ietf.org. 651 Disclaimer of Validity 653 This document and the information contained herein are provided on an 654 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 655 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 656 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 657 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 658 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 661 Copyright Statement 663 Copyright (C) The Internet Society (2005). This document is subject 664 to the rights, licenses and restrictions contained in BCP 78, and 665 except as set forth therein, the authors retain all their rights. 667 Acknowledgment 669 Funding for the RFC Editor function is currently provided by the 670 Internet Society.