idnits 2.17.1 draft-ietf-crisp-iris-lwz-02.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 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 612. ** 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 127 has weird spacing: '...esponse descr...' == Line 189 has weird spacing: '...payload types...' == Line 218 has weird spacing: '...s other infor...' == Line 242 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 (April 29, 2005) is 6929 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' Summary: 5 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: October 31, 2005 April 29, 2005 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-02 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 October 31, 2005. 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). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 48 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 50 3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5 51 3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6 52 3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6 53 4. Internationalization Considerations . . . . . . . . . . . . . 10 54 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11 55 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 56 5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 59 6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 60 6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12 61 6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 65 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 Intellectual Property and Copyright Statements . . . . . . . . 20 68 1. Introduction 70 Using S-NAPTR [4], IRIS has the ability to define the use of multiple 71 application transports or transfer protocols for different types of 72 registry services, all at the descretion of the server operator. The 73 UDP transfer protocol defined in this document is completely modular 74 and may be used by any registry types. 76 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 77 (for IRIS Lightweight using Compression). 79 IRIS-LWZ is composed of two parts, a binary payload descriptor and an 80 request/response transaction payload. The request/response 81 transaction payload may be compressed using the DEFLATE [1] 82 algorithm. 84 2. Document Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC2119 [6]. 90 3. Packet Format 92 The UDP packet format for IRIS-LWZ is as follows: 94 +------+------+----------+--------+------------+---------+ 95 field | src | dest | checksum | UDP | payload | payload | 96 | port | port | | length | descriptor | | 97 +------+------+----------+--------+------------+---------+ 98 octets 2 2 2 2 1..261 0..n 100 (where "src port" means source port and "dest port" means destination 101 port). 103 Each IRIS-LWZ query or response is contained in a single UDP packet. 105 3.1 Payload Descriptor 107 The payload descriptor has two different formats, one for a request 108 and one for a response. However, each format shares a common 1 octet 109 payload header described in Section 3.1.3. 111 3.1.1 Payload Request Descriptor 113 The payload descriptor for request packets has the following format: 115 +--------+-------------+----------+-----------+-----------+ 116 field | header | transaction | maximum | authority | authority | 117 | | ID | response | length | | 118 | | | length | | | 119 +--------+-------------+----------+-----------+-----------+ 120 octets 1 2 2 1 0..255 122 These fields have the following meanings: 124 header - as described in Section 3.1.3. 126 transaction ID - a 16 bit value identifying the transaction. This 127 value will be returned in the payload response descriptor 128 (Section 3.1.2) and can be used by clients to match requests with 129 responses. Clients SHOULD pick the value randomly and SHOULD NOT 130 use sequences of 16 bit values. Clients MUST NOT set all the bits 131 in this value to 1 (i.e. use a value of 0xFFFF). 133 maximum response length - the total length of the UDP packet (i.e. 134 UDP header length + payload descriptor length + XML payload 135 length) that should not be exceeded when responding to this 136 request. If the server cannot provide a response that is equal to 137 or less than this value, then it MUST respond with size 138 information (Section 3.1.3.1.2). 140 authority length - the length of the authority field in this 141 payload descriptor. 143 authority - a string of octets describing the authority against 144 wich this request is to be executed. See [3] for the definition 145 and description of an authority. The number of octets in this 146 string MUST be no more and no less than the number specified by 147 the authority length. 149 3.1.2 Payload Response Descriptor 151 The payload descriptor for response packets consists of a payload 152 header (Section 3.1.3) and a transaction ID. 154 +--------+-------------+ 155 field | header | transaction | 156 | | ID | 157 +--------+-------------+ 158 octets 1 2 160 The transaction ID MUST be the value of the transaction ID of the 161 corresponding request. If the corresponding request did not contain 162 a transaction ID, servers MUST use a transaction ID with all bits set 163 to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see 164 Section 3.1.3.1.3). 166 3.1.3 Payload Header 168 Each bit in the 1 byte payload header has the following meaning: 170 bits 7 and 6 - version number ('V' flag) - If 0 (both bits are 171 zero), the protocol is the version defined in this document. 172 Otherwise, the rest of the bits in the header and the payload may 173 be interpreted as another version. 175 bit 5 - request/response flag ('RR' flag) - If 0, this packet is a 176 request (Section 3.1.1) packet. If 1, this packet is a response 177 (Section 3.1.2) packet. 179 bits 4 - payload deflated ('PD' flag) - If 1, the payload is 180 compressed using the DEFLATE [1] algorithm. 182 bit 3 - deflate supported ('DS' flag) - If 1, the sender of this 183 packet supports compression using the DEFLATE algorithm. When 184 this bit is 0 in a request, the payload of the response MUST NOT 185 be compressed with DEFLATE. 187 bit 2 - reserved - This MUST be 0. 189 bits 1 and 0 - The value of these bits indicate payload types 190 (Section 3.1.3.1) ('PT' flag). 192 3.1.3.1 Payload types 194 A payload type indicates the type of content in the UDP packet 195 following the payload descriptor. Some payload types have no meaning 196 in request packets, and some payload types differ in meaning between 197 requests and responses. Some payload types indicate an empty 198 payload. 200 The payload type values in binary are as follows: 202 00 - xml payload ('xml' type). The payload is either an IRIS- 203 based XML request or an IRIS-based XML response. 205 01 - version info ('vi' type). In a request packet, this payload 206 type indicates that the server is to respond with version 207 information (Section 3.1.3.1.1), and that the payload is empty. 208 In a response packet, this payload type indicates that the payload 209 is version information (Section 3.1.3.1.1). 211 10 - size info ('si' type). This payload type has no meaning in a 212 request packet and is a descriptor error. In a response packet, 213 this payload type indicates that the payload is size information 214 (Section 3.1.3.1.2). 216 11 - other info ('oi' type). This payload type has no meaning in 217 a request packet and is a descriptor error. In a response packet, 218 this payload type indicates that the payload is other information 219 (Section 3.1.3.1.3). 221 3.1.3.1.1 Version Information 223 A payload type with version information ('vi') MUST be comformant to 224 the XML defined in [7] and use the element as the root 225 element. 227 In the context of IRIS-LWZ, the protocol identifiers for these 228 elements are as follows: 230 - the value "iris.lwz1" to indicate the 231 protocol specified in this document. 233 - the XML namespace identifier for IRIS [3]. 235 - the XML namespace identifier for IRIS registries. 237 This document defines no extension identifiers and no authentication 238 mechanism identifiers. 240 Servers SHOULD send version information in the following cases: 242 1. In response to a version information request (i.e. the PT flag 243 is set to 'vi'). 245 2. The version in a payload descriptor header does not match a 246 version the server supports. 248 3. The IRIS-based XML payload does not match a version the server 249 supports. 251 The protocols identified by the element MUST only 252 indicate protocols running on the same socket as the sender of the 253 corresponding request. In other words, while a server operator may 254 also be running IRIS-XPC, this XML instance is only intended to 255 describe version negotiation for IRIS-LWZ. 257 3.1.3.1.2 Size Information 259 A payload type with size information ('si') MUST be comformant to the 260 XML defined in [7] and use the element as the root 261 element. 263 3.1.3.1.3 Other Information 265 A payload type with other information ('oi') MUST be comformant to 266 the XML defined in [7] and use the element as the root 267 element. 269 The values for the 'type' attribute of are as follows: 271 'descriptor-error' - indicates there was an error decoding the 272 descriptor. Servers SHOULD send a descriptor error in the 273 following cases: 275 1. When a request is received with a payload type indicating size 276 information (i.e. the PT flag is 'si'). 278 2. When a request is received with a payload type indicating 279 other information (i.e. the PT flag is 'oi'). 281 3. When a request is sent with an invalid transaction ID. 283 4. When reserved bits in the payload descriptor are set to 284 values other than zero. 286 'payload-error' - indicates there was an error interpretting the 287 payload. Servers MUST send a payload error if they receive XML 288 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 290 'system-error' - indicates that the receiver cannot process the 291 request due to a condition not related to this protocol. Servers 292 SHOULD send a system-error when they are capable of responding to 293 requests but not capable of processing requests. 295 'authority-error' - indicates that the intended authority 296 specified in the corresponding request is not served by the 297 receiver. Servers SHOULD send an authority error when they 298 receive a request directed to an authority other than those they 299 serve. 301 'no-inflation-support-error' - indicates that the receiver does 302 not support payloads that have been compressed with DEFLATE [1]. 303 Servers MUST send this error when they receive a request that has 304 been compressed with DEFLATE but they do not support inflation. 306 4. Internationalization Considerations 308 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 309 encodings. Use of the XML defined by [7] MUST NOT use any other 310 character encodings other than UTF-8 or UTF-16. 312 5. IRIS Transport Mapping Definitions 314 This section lists the definitions required by IRIS [3] for transport 315 mappings. 317 5.1 URI Scheme 319 See Section 6.1.1. 321 5.2 Application Protocol Label 323 See Section 6.1.3. 325 6. IANA Considerations 327 6.1 Registrations 329 6.1.1 URI Scheme Registration 331 URL scheme name: iris.lwz 333 URL scheme syntax: defined in Section 5.1 and [3]. 335 Character encoding considerations: as defined in RFC2396 [5]. 337 Intended usage: identifies an IRIS entity made available using XML 338 over UDP 340 Applications using this scheme: defined in IRIS [3]. 342 Interoperability considerations: n/a 344 Security Considerations: defined in Section 7. 346 Relevant Publications: IRIS [3]. 348 Contact Information: Andrew Newton 350 Author/Change controller: the IESG 352 6.1.2 Well-known UDP Port Registration 354 Protocol Number: UDP 356 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 357 and Section 3.1. 359 Functions: defined in IRIS [3]. 361 Use of Broadcast/Multicast: none 363 Proposed Name: IRIS-LWZ 365 Short name: iris.lwz 367 Contact Information: Andrew Newton 369 6.1.3 S-NAPTR Registration 371 Application Protocol Label (see [4]): iris.lwz 372 Intended usage: identifies an IRIS server using XML over UDP 374 Interoperability considerations: n/a 376 Security Considerations: defined in Section 7. 378 Relevant Publications: IRIS [3]. 380 Contact Information: Andrew Newton 382 Author/Change controller: the IESG 384 7. Security Considerations 386 IRIS-LWZ is intended for serving public data; it provides no in-band 387 mechanisms for authentication or encryption. Any application with 388 this need must provide out of band mechanisms to provide it (e.g., 389 IPSec), or use the IRIS transfer protocols that provides such 390 capabilities. 392 8. Normative References 394 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 395 version 1.3", RFC 1951, May 1996. 397 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 398 ISBN 0-201-61633-5, 2000, . 400 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 401 RFC 3891, January 2004. 403 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 404 Location Using SRV RRs and the Dynamic Delegation Discovery 405 Service (DDDS)", RFC 3958, January 2005. 407 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 408 Resource Identifiers (URI): Generic Syntax", RFC 2396, 409 August 1998. 411 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 412 Levels", RFC 2119, BCP 14, March 1997. 414 [7] Newton, A., "A Common Schema for Internet Registry Information 415 Service Transfer Protocols", 416 draft-ietf-crips-iris-common-transport-00 (work in progress), 417 April 2005. 419 Author's Address 421 Andrew L. Newton 422 VeriSign, Inc. 423 21345 Ridgetop Circle 424 Sterling, VA 20166 425 USA 427 Phone: +1 703 948 3382 428 Email: anewton@verisignlabs.com; andy@hxr.us 429 URI: http://www.verisignlabs.com/ 431 Appendix A. Examples 433 This section gives examples of IRIS-LWZ exchanges. Lines beginning 434 with "C:" denote data sent by the client to the server, and lines 435 beginning with "S:" denote data sent by the server to the client. 436 Following the "C:" or "S:", the line either contains octet values in 437 hexadecimal notation with comments or XML fragments. No line 438 contains both octet values with comments and XML fragments. Comments 439 are contained within parenthesis. 441 The following example demonstrates an IRIS client requesting a lookup 442 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 443 client passes a bag with the search request. The server responds 444 with a 'nameNotFound' response and an explanation. 446 C: (request packet) 447 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 448 C: 0x03 0xA4 (transaction ID=932) 449 C: 0x05 0xDA (maximum response size=1498) 450 C: 0x09 (authority length=9) 451 C: (authority="localhost") 452 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 453 C: (IRIS XML request) 454 C: 456 C: 457 C: 458 C: 459 C: 127.0.0.1:3434 460 C: 4LnQ1KdCahzyvwBqJis5rw== 461 C: 462 C: 463 C: 467 C: 468 C: 470 S: (response packet) 471 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 472 S: 0x03 0xA4 (transaction ID=932) 473 S: (IRIS XML response) 474 S: 475 S: 476 S: 477 S: The name 'AUP' is not found in 'local'. 478 S: 480 Figure 4: Example 1 482 The following example demonstrates an IRIS client requesting domain 483 availability information for 'milo.example.com'. The server responds 484 that the domain is assigned and active. 486 C: (request packet) 487 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 488 C: 0x0B 0xE7 (transaction ID=3047) 489 C: 0x0F 0xA0 (maximum response size=4000) 490 C: 0x0B (authority length=11) 491 C: (authority="example.com") 492 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 493 C: (IRIS XML request) 494 C: 497 C: 498 C: 502 C: 503 C: 505 S: (response packet) 506 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 507 S: 0x0B 0xE7 (transaction ID=3047) 508 S: (IRIS XML response) 509 S: 510 S: 515 S: milo.example.com 516 S: 517 S: 519 Figure 5: Example 2 521 The following example demonstrates an IRIS client requesting domain 522 availability information for felix.example.net, hobbes.example.net, 523 and daffy.example.net. The client does not support responses 524 compressed with DEFLATE and the maximum UDP packet it can safely 525 receive is 498 octets. The server responds with size information 526 indicating that it would take 1211 octets to provide an answer. 528 C: (request packet) 529 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 530 C: 0x7E 0x8A (transaction ID=32394) 531 C: 0x01 0xF2 (maximum response size=498) 532 C: 0x0B (authority length=11) 533 C: (authority="example.net") 534 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 535 C: (IRIS XML request) 536 C: 539 C: 540 C: 542 C: 543 C: 544 C: 546 C: 547 C: 548 C: 550 C: 551 C: 553 S: (response packet) 554 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 555 S: 0x7E 0x8A (transaction ID=32394) 556 S: (Size Information XML response) 557 S: 558 S: 1211 559 S: 561 Figure 6: Example 3 563 The following example illustrates an IRIS client requesting the 564 version information from a server, and the server returning the 565 verion information. 567 C: (request packet) 568 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 569 C: 0x2E 0x9C (transaction ID=11932) 570 C: 0x01 0xF2 (maximum response size=498) 571 C: 0x0B (authority length=11) 572 C: (authority="example.net") 573 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 575 S: (response packet) 576 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 577 S: 0x2E 0x9C (transaction ID=11932) 578 S: (Version Information XML response) 579 S: 580 S: 581 S: 582 S: 583 S: 584 S: 585 S: 586 S: 588 Figure 7: Example 4 590 Intellectual Property Statement 592 The IETF takes no position regarding the validity or scope of any 593 Intellectual Property Rights or other rights that might be claimed to 594 pertain to the implementation or use of the technology described in 595 this document or the extent to which any license under such rights 596 might or might not be available; nor does it represent that it has 597 made any independent effort to identify any such rights. Information 598 on the procedures with respect to rights in RFC documents can be 599 found in BCP 78 and BCP 79. 601 Copies of IPR disclosures made to the IETF Secretariat and any 602 assurances of licenses to be made available, or the result of an 603 attempt made to obtain a general license or permission for the use of 604 such proprietary rights by implementers or users of this 605 specification can be obtained from the IETF on-line IPR repository at 606 http://www.ietf.org/ipr. 608 The IETF invites any interested party to bring to its attention any 609 copyrights, patents or patent applications, or other proprietary 610 rights that may cover technology that may be required to implement 611 this standard. Please address the information to the IETF at 612 ietf-ipr@ietf.org. 614 Disclaimer of Validity 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 619 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 620 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 621 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Copyright Statement 626 Copyright (C) The Internet Society (2005). This document is subject 627 to the rights, licenses and restrictions contained in BCP 78, and 628 except as set forth therein, the authors retain all their rights. 630 Acknowledgment 632 Funding for the RFC Editor function is currently provided by the 633 Internet Society.