idnits 2.17.1 draft-ietf-crisp-iris-lwz-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 788. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For retransmission of requests considered to be unanswered, a client SHOULD retransmit using a timeout value initially set to 1 second. This timeout value SHOULD be doubled for every retransmission, and it a client SHOULD not retransmit any request once the timeout value has reached 60 seconds. If the next query the client sends is to the same server, it SHOULD start with the last timeout value used. -- 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 (March 5, 2007) is 6234 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. '8' -- No information found for draft-ietf-crips-iris-xpc - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '10') Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 12 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 Intended status: Standards Track March 5, 2007 5 Expires: September 6, 2007 7 A Lightweight UDP Transfer Protocol for the the Internet Registry 8 Information Service 9 draft-ietf-crisp-iris-lwz-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a lightweight UDP transfer protocol for the 43 Internet Registry Information Service (IRIS). This transfer protocol 44 uses a single packet for every request and response, and optionally 45 employs compression over the contents of the packet. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 51 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1. Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 53 3.1.1. Payload Request Descriptor . . . . . . . . . . . . . . 5 54 3.1.2. Payload Response Descriptor . . . . . . . . . . . . . 6 55 3.1.3. Payload Header . . . . . . . . . . . . . . . . . . . . 7 56 3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7 57 3.1.5. Version Information . . . . . . . . . . . . . . . . . 8 58 3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9 59 3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9 60 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 5. Internationalization Considerations . . . . . . . . . . . . . 13 62 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 14 63 6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14 64 6.2. Application Protocol Label . . . . . . . . . . . . . . . . 14 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 15 68 7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 15 69 7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 16 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 24 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 Intellectual Property and Copyright Statements . . . . . . . . . . 26 77 1. Introduction 79 Using Straightforward Name Authority Pointers [4], IRIS has the 80 ability to define the use of multiple application transports or 81 transfer protocols for different types of registry services, all at 82 the descretion of the server operator. The UDP transfer protocol 83 defined in this document is completely independent of the registry 84 types for which it can carry data. 86 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 87 (for IRIS Lightweight using Compression). Its message exchange 88 pattern is simple: a client sends a request in one UDP packet, and a 89 server responds with an answer in one UDP packet. 91 IRIS-LWZ packets are composed of two parts, a binary payload 92 descriptor and an request/response transaction payload. The request/ 93 response transaction payload may be compressed using the DEFLATE [1] 94 algorithm. 96 2. Document Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119 [6]. 102 Octet fields with numberic values are given according to the 103 conventions in RFC 1166 [10]: the left most bit of the whole field is 104 the most significant bit; when a multi-octet quantity is transmitted 105 the most significant octet is transmitted first. Bits signifying 106 flags in an octet are numbered according to the conventions of RFC 107 1166 [10]: bit 0 is the most significant bit and bit 7 is the least 108 significant bit. When a diagram describes a group of octets, the 109 order of tranmission for the octets starts from the left. 111 3. Packet Format 113 The packet format for IRIS-LWZ is as follows: 115 +------------+---------+ 116 field | payload | payload | 117 | descriptor | | 118 +------------+---------+ 119 octets 3 or 6..261* 0..n 121 * In request packets, the payload descriptor can vary in length 122 from 6 to 261 octets (i.e. 6..261). In response packets, the 123 payload descriptor is always 3 octets. 125 IRIS-LWZ Packet 127 (where "src port" means source port and "dest port" means destination 128 port). 130 Each IRIS-LWZ query or response is contained in a single UDP packet. 131 Servers MUST be prepared to accepted packets as large as 4000 octets, 132 and clients MUST NOT send packets larger than 4000 octets. 134 3.1. Payload Descriptor 136 The payload descriptor has two different formats, one for a request 137 and one for a response. However, each format shares a common 1 octet 138 payload header described in Section 3.1.3. 140 3.1.1. Payload Request Descriptor 142 The payload descriptor for request packets varies from 6 to 261 143 octets in lenght and has the following format: 145 +--------+-------------+----------+-----------+-----------+ 146 field | header | transaction | maximum | authority | authority | 147 | | ID | response | length | | 148 | | | length | | | 149 +--------+-------------+----------+-----------+-----------+ 150 octets 1 2 2 1 0..255 152 Request Payload Descriptor 154 These fields have the following meanings: 156 o header - as described in Section 3.1.3. 158 o transaction ID - a 16 bit value identifying the transaction. This 159 value will be returned in the payload response descriptor 160 (Section 3.1.2) and can be used by clients to match requests with 161 responses. Clients SHOULD NOT use sequential values (See 162 Section 8). Clients MUST NOT set all the bits in this value to 1 163 (i.e. use a value of 0xFFFF). 165 o maximum response length - the total length of the UDP packet (i.e. 166 UDP header length + payload descriptor length + XML payload 167 length) that should not be exceeded when responding to this 168 request. If the server cannot provide a response that is equal to 169 or less than this value, then it MUST respond with size 170 information (Section 3.1.6). 172 o authority length - the length of the authority field in this 173 payload descriptor. 175 o authority - a string of octets describing the authority against 176 wich this request is to be executed. See [3] for the definition 177 and description of an authority. The number of octets in this 178 string MUST be no more and no less than the number specified by 179 the authority length. 181 3.1.2. Payload Response Descriptor 183 The payload descriptor for response packets is always 3 octets and 184 consists of a payload header (Section 3.1.3) and a transaction ID. 186 +--------+-------------+ 187 field | header | transaction | 188 | | ID | 189 +--------+-------------+ 190 octets 1 2 192 Response Payload Descriptor 194 The purpose of the transaction ID is to allow clients to match 195 requests to responses. A value of 0xFFFF is reserved for server use. 196 The value of the transaction ID is as follows: 198 1. If the transaction ID in the corresponding request could not be 199 read due to truncation, servers MUST use a transaction ID with 200 all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor 201 error (see Section 3.1.7). 203 2. If the transaction ID in the corresponding request is a value of 204 0xFFFF, servers MUST use a transaction ID of 0xFFFF and send a 205 descriptor error (see Section 3.1.7). 207 3. Otherwise, the transaction ID MUST be the value of the 208 transaction ID of the corresponding request. 210 3.1.3. Payload Header 212 The bits of the payload header are ordered according to RFC 1166 213 [10], where bit 0 is the most significant and bit 7 is the least 214 significant. Each bit in the one octet payload header has the 215 following meaning: 217 o bits 0 and 1 - version number ('V' field) - If 0 (both bits are 218 zero), the protocol is the version defined in this document. 219 Otherwise, the rest of the bits in the header and the payload may 220 be interpreted as another version. 222 o bit 2 - request/response flag ('RR' flag) - If 0, this packet is a 223 request (Section 3.1.1) packet. If 1, this packet is a response 224 (Section 3.1.2) packet. 226 o bits 3 - payload deflated ('PD' flag) - If 1, the payload is 227 compressed using the DEFLATE [1] algorithm. 229 o bit 4 - deflate supported ('DS' flag) - If 1, the sender of this 230 packet supports compression using the DEFLATE algorithm. When 231 this bit is 0 in a request, the payload of the response MUST NOT 232 be compressed with DEFLATE. 234 o bit 5 - reserved - This MUST be 0. 236 o bits 6 and 7 - The value of these bits indicate payload types 237 (Section 3.1.4) ('PT' field). 239 3.1.4. Payload Types 241 A payload type indicates the type of content in the UDP packet 242 following the payload descriptor. Some payload types have no meaning 243 in request packets, and some payload types differ in meaning between 244 requests and responses. Some payload types indicate an empty 245 payload. 247 The payload type values in binary are as follows: 249 00 - xml payload ('xml' type). The payload is either an IRIS- 250 based XML request or an IRIS-based XML response. 252 01 - version info ('vi' type). In a request packet, this payload 253 type indicates that the server is to respond with version 254 information (Section 3.1.5), and that the payload is empty. In a 255 response packet, this payload type indicates that the payload is 256 version information (Section 3.1.5). 258 10 - size info ('si' type). This payload type has no meaning in a 259 request packet and is a descriptor error. In a response packet, 260 this payload type indicates that the payload is size information 261 (Section 3.1.6). 263 11 - other info ('oi' type). This payload type has no meaning in 264 a request packet and is a descriptor error. In a response packet, 265 this payload type indicates that the payload is other information 266 (Section 3.1.7). 268 3.1.5. Version Information 270 A payload type with version information ('vi') MUST be comformant to 271 the XML defined in [8] and use the element as the root 272 element. 274 In the context of IRIS-LWZ, the protocol identifiers for these 275 elements are as follows: 277 - the value "iris.lwz1" to indicate the 278 protocol specified in this document. 280 - the XML namespace identifier for IRIS [3]. 282 - the XML namespace identifier for IRIS registries. 284 This document defines no extension identifiers and no authentication 285 mechanism identifiers. 287 Servers SHOULD send version information in the following cases: 289 1. In response to a version information request (i.e. the PT flag is 290 set to 'vi'). 292 2. The version in a payload descriptor header does not match a 293 version the server supports. 295 3. The IRIS-based XML payload does not match a version the server 296 supports. 298 The protocols identified by the element MUST only 299 indicate protocols running on the same socket as the sender of the 300 corresponding response. In other words, while a server operator may 301 also be running IRIS-XPC [9], this XML instance is only intended to 302 describe version negotiation for IRIS-LWZ. 304 The definition of octet size for the 'requestSizeOctets' and 305 'responseSizeOctets' attributes of the element are 306 defined in Section 3.1.6. 308 3.1.6. Size Information 310 A payload type with size information ('si') MUST be comformant to the 311 XML defined in [8] and use the element as the root element. 313 Octet counts provided by this information are defined as the total 314 length of the UDP packet (i.e. UDP header length + payload 315 descriptor length + XML payload length). 317 3.1.7. Other Information 319 A payload type with other information ('oi') MUST be comformant to 320 the XML defined in [8] and use the element as the root 321 element. 323 The values for the 'type' attribute of are as follows: 325 'descriptor-error' - indicates there was an error decoding the 326 descriptor. Servers SHOULD send a descriptor error in the 327 following cases: 329 1. When a request is received with a payload type indicating size 330 information (i.e. the PT flag is 'si'). 332 2. When a request is received with a payload type indicating 333 other information (i.e. the PT flag is 'oi'). 335 3. When a request is sent with a transaction ID of 0xFFFF (which 336 is reserved for server use). 338 4. When a request is received with an incomplete or truncated 339 payload descriptor. 341 5. When reserved bits in the payload descriptor are set to values 342 other than zero. 344 'payload-error' - indicates there was an error interpretting the 345 payload. Servers MUST send a payload error if they receive XML 346 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 348 'system-error' - indicates that the receiver cannot process the 349 request due to a condition not related to this protocol. Servers 350 SHOULD send a system-error when they are capable of responding to 351 requests but not capable of processing requests. 353 'authority-error' - indicates that the intended authority 354 specified in the corresponding request is not served by the 355 receiver. Servers SHOULD send an authority error when they 356 receive a request directed to an authority other than those they 357 serve. 359 'no-inflation-support-error' - indicates that the receiver does 360 not support payloads that have been compressed with DEFLATE [1]. 361 Servers MUST send this error when they receive a request that has 362 been compressed with DEFLATE but they do not support inflation. 364 4. Interactions 366 The intent of IRIS-LWZ is to utilize UDP for IRIS requests and 367 responses when UDP is appropriate. Not all IRIS requests and 368 responses will be able to utilize UDP and may require the use of 369 other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The 370 following strategy SHOULD be used: 372 1. If a request requires authentication, confidentiality, or other 373 security, use another transfer protocol. IRIS-XPC [9] is 374 RECOMMENDED. 376 2. The maximum packet size should be calculated as follows: 378 1. If the path MTU is unknown, the maximum packet size MUST be 379 1500 octets. 381 2. If the path MTU is known, the maximum packet size MUST NOT 382 exceed the path MTU and MUST NOT exceed 4000 octets. 384 3. If a request is less than or equal to the maximum packet size, 385 send it uncompressed. 387 4. If a request can be compressed to a size less than or equal to 388 the maximum packet size, send the request using compression. 389 Otherwise use another transfer protocol. In cases where another 390 transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED. 392 5. If a request yields a size error, send the request with another 393 transfer protocol. IRIS-XPC [9] is RECOMMENDED. 395 If a client does not know the path MTU or does not use the packet 396 size recommendations above, the client MUST allocate or have 397 allocated dedicated network resources that will ensure fairness to 398 other network packets and avoid packet fragmentation. 400 For retransmission of requests considered to be unanswered, a client 401 SHOULD retransmit using a timeout value initially set to 1 second. 402 This timeout value SHOULD be doubled for every retransmission, and it 403 a client SHOULD not retransmit any request once the timeout value has 404 reached 60 seconds. If the next query the client sends is to the 405 same server, it SHOULD start with the last timeout value used. 407 Clients that use timeout values other than the recommendations above 408 MUST allocate or have allocated dedicate network resources that will 409 ensure fairness to other network packets and avoid network 410 congestion. 412 Clients MUST NOT have more than one outstanding request (i.e. a 413 unanswered request that has not timed out) at a time unless they 414 allocate or have been allocated dedicated network bandwidth and 415 resources reserved specifically for this purpose. 417 Finally, if a client intends multiple requests to the same server in 418 a short amount of time, this protocol offers no real advantage over 419 IRIS-XPC [9]. In such a case, IRIS-XPC should be used as it would be 420 similarly effecient and would offer greater reponse sizes and allow 421 better security. 423 5. Internationalization Considerations 425 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 426 encodings. Use of the XML defined by [8] MUST NOT use any other 427 character encodings other than UTF-8 or UTF-16. 429 6. IRIS Transport Mapping Definitions 431 This section lists the definitions required by IRIS [3] for transport 432 mappings. 434 6.1. URI Scheme 436 See Section 7.1.1. 438 6.2. Application Protocol Label 440 See Section 7.1.3. 442 7. IANA Considerations 444 7.1. Registrations 446 7.1.1. URI Scheme Registration 448 URL scheme name: iris.lwz 450 URL scheme syntax: defined in Section 6.1 and [3]. 452 Character encoding considerations: as defined in RFC2396 [5]. 454 Intended usage: identifies an IRIS entity made available using XML 455 over UDP 457 Applications using this scheme: defined in IRIS [3]. 459 Interoperability considerations: n/a 461 Security Considerations: defined in Section 8. 463 Relevant Publications: IRIS [3]. 465 Contact Information: Andrew Newton 467 Author/Change controller: the IESG 469 7.1.2. Well-known UDP Port Registration 471 Protocol Number: UDP 473 UDP Port Number: TBD by IANA 475 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 476 and Section 3.1. 478 Functions: defined in IRIS [3]. 480 Use of Broadcast/Multicast: none 482 Proposed Name: IRIS-LWZ 484 Short name: iris.lwz 486 Contact Information: Andrew Newton 488 7.1.3. S-NAPTR Registration 490 Application Protocol Label (see [4]): iris.lwz 492 Intended usage: identifies an IRIS server using XML over UDP 494 Interoperability considerations: n/a 496 Security Considerations: defined in Section 8. 498 Relevant Publications: IRIS [3]. 500 Contact Information: Andrew Newton 502 Author/Change controller: the IESG 504 8. Security Considerations 506 IRIS-LWZ is intended for serving public data; it provides no in-band 507 mechanisms for authentication or confidentiality. Any application 508 with these needs must provide out of band mechanisms (e.g., IPSec), 509 or use the IRIS transfer protocols that provides such capabilities, 510 such as IRIS-XPC [9]. 512 Due to this lack of security, it is possible for an attacker to alter 513 IRIS-LWZ messages sent from the client to the server and from the 514 server to the client. Such an attack can result in denying usage of 515 an IRIS service or in supplying false information to end users and 516 many other scenarios. 518 Because IRIS-LWZ is a UDP based protocol, it is possible for servers 519 using IRIS-LWZ to be used in a type of distributed denial of service 520 attack known as a reflection attack. This type of attack affects 521 other types of UDP using protocols, such as DNS. Server operators 522 should be prepared to apply the same methods used for mitigating 523 reflection attacks with other protocols, such as DNS, when using 524 IRIS-LWZ. All operators should follow the advice given in BCP 38 525 [7]. 527 IRIS-LWZ uses transaction IDs in the payload descriptors to better 528 enable a client to match a response to a request. By randomizing the 529 transaction IDs being used (i.e. not using sequential numbers), 530 attackers flooding the network with a large amount of spoofed packets 531 have a lesser chance of succeeding with the attack. This measure is 532 not guaranteed to thwart any such attack. Client implementers MUST 533 take appropriate measures when ignoring this advice. 535 9. Normative References 537 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 538 version 1.3", RFC 1951, May 1996. 540 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 541 ISBN 0-201-61633-5, 2000, . 543 [3] Newton, A. and M. Sanz, "Internet Registry Information 544 Service", RFC 3891, January 2004. 546 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 547 Location Using SRV RRs and the Dynamic Delegation Discovery 548 Service (DDDS)", RFC 3958, January 2005. 550 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 551 Resource Identifiers (URI): Generic Syntax", RFC 2396, 552 August 1998. 554 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 555 Levels", RFC 2119, BCP 14, March 1997. 557 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: 558 Defeating Denial of Service Attacks which employ IP Source 559 Address Spoofing", BCP 38, RFC 2827, May 2000. 561 [8] Newton, A., "A Common Schema for Internet Registry Information 562 Service Transfer Protocols", 563 draft-ietf-crips-iris-common-transport-00 (work in progress), 564 April 2005. 566 [9] Newton, A., "XML Pipelining with Chunks for the Information 567 Registry Information Service", draft-ietf-crips-iris-xpc-05 568 (work in progress), January 2007. 570 [10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 571 RFC 1166, July 1990. 573 Appendix A. Examples 575 This section gives examples of IRIS-LWZ exchanges. Lines beginning 576 with "C:" denote data sent by the client to the server, and lines 577 beginning with "S:" denote data sent by the server to the client. 578 Following the "C:" or "S:", the line either contains octet values in 579 hexadecimal notation with comments or XML fragments. No line 580 contains both octet values with comments and XML fragments. Comments 581 are contained within parenthesis. 583 The following example demonstrates an IRIS client requesting a lookup 584 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 585 client passes a bag with the search request. The server responds 586 with a 'nameNotFound' response and an explanation. 588 C: (request packet) 589 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 590 C: 0x03 0xA4 (transaction ID=932) 591 C: 0x05 0xDA (maximum response size=1498) 592 C: 0x09 (authority length=9) 593 C: (authority="localhost") 594 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 595 C: (IRIS XML request) 596 C: 598 C: 599 C: 600 C: 601 C: 127.0.0.1:3434 602 C: 4LnQ1KdCahzyvwBqJis5rw== 603 C: 604 C: 605 C: 609 C: 610 C: 612 S: (response packet) 613 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 614 S: 0x03 0xA4 (transaction ID=932) 615 S: (IRIS XML response) 616 S: 617 S: 618 S: 619 S: The name 'AUP' is not found in 'local'. 620 S: 622 Figure 4: Example 1 624 The following example demonstrates an IRIS client requesting domain 625 availability information for 'milo.example.com'. The server responds 626 that the domain is assigned and active. 628 C: (request packet) 629 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 630 C: 0x0B 0xE7 (transaction ID=3047) 631 C: 0x0F 0xA0 (maximum response size=4000) 632 C: 0x0B (authority length=11) 633 C: (authority="example.com") 634 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 635 C: (IRIS XML request) 636 C: 639 C: 640 C: 644 C: 645 C: 647 S: (response packet) 648 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 649 S: 0x0B 0xE7 (transaction ID=3047) 650 S: (IRIS XML response) 651 S: 652 S: 657 S: milo.example.com 658 S: 659 S: 661 Figure 5: Example 2 663 The following example demonstrates an IRIS client requesting domain 664 availability information for felix.example.net, hobbes.example.net, 665 and daffy.example.net. The client does not support responses 666 compressed with DEFLATE and the maximum UDP packet it can safely 667 receive is 498 octets. The server responds with size information 668 indicating that it would take 1211 octets to provide an answer. 670 C: (request packet) 671 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 672 C: 0x7E 0x8A (transaction ID=32394) 673 C: 0x01 0xF2 (maximum response size=498) 674 C: 0x0B (authority length=11) 675 C: (authority="example.net") 676 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 677 C: (IRIS XML request) 678 C: 681 C: 682 C: 684 C: 685 C: 686 C: 688 C: 689 C: 690 C: 692 C: 693 C: 695 S: (response packet) 696 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 697 S: 0x7E 0x8A (transaction ID=32394) 698 S: (Size Information XML response) 699 S: 700 S: 1211 701 S: 703 Figure 6: Example 3 705 The following example illustrates an IRIS client requesting the 706 version information from a server, and the server returning the 707 verion information. 709 C: (request packet) 710 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 711 C: 0x2E 0x9C (transaction ID=11932) 712 C: 0x01 0xF2 (maximum response size=498) 713 C: 0x0B (authority length=11) 714 C: (authority="example.net") 715 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 717 S: (response packet) 718 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 719 S: 0x2E 0x9C (transaction ID=11932) 720 S: (Version Information XML response) 721 S: 722 S: 723 S: 724 S: 725 S: 726 S: 727 S: 728 S: 730 Figure 7: Example 4 732 Appendix B. Contributors 734 Substantive contributions to this document have been provided by the 735 members of the IETF's CRISP Working Group, especially Milena Caires 736 and David Blacka. 738 Author's Address 740 Andrew L. Newton 741 VeriSign, Inc. 742 21345 Ridgetop Circle 743 Sterling, VA 20166 744 USA 746 Phone: +1 703 948 3382 747 Email: andy@hxr.us 748 URI: http://www.verisignlabs.com/ 750 Full Copyright Statement 752 Copyright (C) The IETF Trust (2007). 754 This document is subject to the rights, licenses and restrictions 755 contained in BCP 78, and except as set forth therein, the authors 756 retain all their rights. 758 This document and the information contained herein are provided on an 759 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 760 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 761 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 762 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 763 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 764 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 766 Intellectual Property 768 The IETF takes no position regarding the validity or scope of any 769 Intellectual Property Rights or other rights that might be claimed to 770 pertain to the implementation or use of the technology described in 771 this document or the extent to which any license under such rights 772 might or might not be available; nor does it represent that it has 773 made any independent effort to identify any such rights. Information 774 on the procedures with respect to rights in RFC documents can be 775 found in BCP 78 and BCP 79. 777 Copies of IPR disclosures made to the IETF Secretariat and any 778 assurances of licenses to be made available, or the result of an 779 attempt made to obtain a general license or permission for the use of 780 such proprietary rights by implementers or users of this 781 specification can be obtained from the IETF on-line IPR repository at 782 http://www.ietf.org/ipr. 784 The IETF invites any interested party to bring to its attention any 785 copyrights, patents or patent applications, or other proprietary 786 rights that may cover technology that may be required to implement 787 this standard. Please address the information to the IETF at 788 ietf-ipr@ietf.org. 790 Acknowledgment 792 Funding for the RFC Editor function is provided by the IETF 793 Administrative Support Activity (IASA).