idnits 2.17.1 draft-ietf-crisp-iris-lwz-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 741. ** 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 == 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. -- 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 (January 9, 2007) is 6309 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: 6 errors (**), 0 flaws (~~), 3 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 Expires: July 13, 2007 January 9, 2007 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-07 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 July 13, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2007). 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 . . . . . . . . . . . . . . . . . . . . 7 55 3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7 56 3.1.5. Version Information . . . . . . . . . . . . . . . . . 8 57 3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9 58 3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9 59 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 5. Internationalization Considerations . . . . . . . . . . . . . 12 61 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13 62 6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 63 6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 66 7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14 67 7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14 68 7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 72 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 23 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 74 Intellectual Property and Copyright Statements . . . . . . . . . . 25 76 1. Introduction 78 Using Straightforward Name Authority Pointers [4], IRIS has the 79 ability to define the use of multiple application transports or 80 transfer protocols for different types of registry services, all at 81 the descretion of the server operator. The UDP transfer protocol 82 defined in this document is completely independent of the registry 83 types for which it can carry data. 85 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 86 (for IRIS Lightweight using Compression). Its message exchange 87 pattern is simple: a client sends a request in one UDP packet, and a 88 server responds with an answer in one UDP packet. 90 IRIS-LWZ packets are composed of two parts, a binary payload 91 descriptor and an request/response transaction payload. The request/ 92 response transaction payload may be compressed using the DEFLATE [1] 93 algorithm. 95 2. Document Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC2119 [6]. 101 Octet fields with numberic values are given according to the 102 conventions in RFC 1166 [10]: the left most bit of the whole field is 103 the most significant bit; when a multi-octet quantity is transmitted 104 the most significant octet is transmitted first. Bits signifying 105 flags in an octet are numbered according to the conventions of RFC 106 1166 [10]: bit 0 is the most significant bit and bit 7 is the least 107 significant bit. When a diagram describes a group of octets, the 108 order of tranmission for the octets starts from the left. 110 3. Packet Format 112 The packet format for IRIS-LWZ is as follows: 114 +------------+---------+ 115 field | payload | payload | 116 | descriptor | | 117 +------------+---------+ 118 octets 3 or 6..261* 0..n 120 * In request packets, the payload descriptor can vary in length 121 from 6 to 261 octets (i.e. 6..261). In response packets, the 122 payload descriptor is always 3 octets. 124 (where "src port" means source port and "dest port" means destination 125 port). 127 Each IRIS-LWZ query or response is contained in a single UDP packet. 128 Servers MUST be prepared to accepted packets as large as 4000 octets, 129 and clients MUST NOT send packets larger than 4000 octets. 131 3.1. Payload Descriptor 133 The payload descriptor has two different formats, one for a request 134 and one for a response. However, each format shares a common 1 octet 135 payload header described in Section 3.1.3. 137 3.1.1. Payload Request Descriptor 139 The payload descriptor for request packets varies from 6 to 261 140 octets in lenght and has the following format: 142 +--------+-------------+----------+-----------+-----------+ 143 field | header | transaction | maximum | authority | authority | 144 | | ID | response | length | | 145 | | | length | | | 146 +--------+-------------+----------+-----------+-----------+ 147 octets 1 2 2 1 0..255 149 These fields have the following meanings: 151 header - as described in Section 3.1.3. 153 transaction ID - a 16 bit value identifying the transaction. This 154 value will be returned in the payload response descriptor 155 (Section 3.1.2) and can be used by clients to match requests with 156 responses. Clients SHOULD NOT use sequential values (See 157 Section 8). Clients MUST NOT set all the bits in this value to 1 158 (i.e. use a value of 0xFFFF). 160 maximum response length - the total length of the UDP packet (i.e. 161 UDP header length + payload descriptor length + XML payload 162 length) that should not be exceeded when responding to this 163 request. If the server cannot provide a response that is equal to 164 or less than this value, then it MUST respond with size 165 information (Section 3.1.6). 167 authority length - the length of the authority field in this 168 payload descriptor. 170 authority - a string of octets describing the authority against 171 wich this request is to be executed. See [3] for the definition 172 and description of an authority. The number of octets in this 173 string MUST be no more and no less than the number specified by 174 the authority length. 176 3.1.2. Payload Response Descriptor 178 The payload descriptor for response packets is always 3 octets and 179 consists of a payload header (Section 3.1.3) and a transaction ID. 181 +--------+-------------+ 182 field | header | transaction | 183 | | ID | 184 +--------+-------------+ 185 octets 1 2 187 The purpose of the transaction ID is to allow clients to match 188 requests to responses. A value of 0xFFFF is reserved for server use. 189 The value of the transaction ID is as follows: 191 1. If the transaction ID in the corresponding request could not be 192 read due to truncation, servers MUST use a transaction ID with 193 all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor 194 error (see Section 3.1.7). 196 2. If the transaction ID in the corresponding request is a value of 197 0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a 198 descriptor error (see Section 3.1.7). 200 3. Otherwise, the transaction ID MUST be the value of the 201 transaction ID of the corresponding request. 203 3.1.3. Payload Header 205 The bits of the payload header are ordered according to RFC 1166 206 [10], where bit 0 is the most significant and bit 7 is the least 207 significant. Each bit in the one octet payload header has the 208 following meaning: 210 bits 0 and 1 - version number ('V' field) - If 0 (both bits are 211 zero), the protocol is the version defined in this document. 212 Otherwise, the rest of the bits in the header and the payload may 213 be interpreted as another version. 215 bit 2 - request/response flag ('RR' flag) - If 0, this packet is a 216 request (Section 3.1.1) packet. If 1, this packet is a response 217 (Section 3.1.2) packet. 219 bits 3 - payload deflated ('PD' flag) - If 1, the payload is 220 compressed using the DEFLATE [1] algorithm. 222 bit 4 - deflate supported ('DS' flag) - If 1, the sender of this 223 packet supports compression using the DEFLATE algorithm. When 224 this bit is 0 in a request, the payload of the response MUST NOT 225 be compressed with DEFLATE. 227 bit 5 - reserved - This MUST be 0. 229 bits 6 and 7 - The value of these bits indicate payload types 230 (Section 3.1.4) ('PT' field). 232 3.1.4. Payload Types 234 A payload type indicates the type of content in the UDP packet 235 following the payload descriptor. Some payload types have no meaning 236 in request packets, and some payload types differ in meaning between 237 requests and responses. Some payload types indicate an empty 238 payload. 240 The payload type values in binary are as follows: 242 00 - xml payload ('xml' type). The payload is either an IRIS- 243 based XML request or an IRIS-based XML response. 245 01 - version info ('vi' type). In a request packet, this payload 246 type indicates that the server is to respond with version 247 information (Section 3.1.5), and that the payload is empty. In a 248 response packet, this payload type indicates that the payload is 249 version information (Section 3.1.5). 251 10 - size info ('si' type). This payload type has no meaning in a 252 request packet and is a descriptor error. In a response packet, 253 this payload type indicates that the payload is size information 254 (Section 3.1.6). 256 11 - other info ('oi' type). This payload type has no meaning in 257 a request packet and is a descriptor error. In a response packet, 258 this payload type indicates that the payload is other information 259 (Section 3.1.7). 261 3.1.5. Version Information 263 A payload type with version information ('vi') MUST be comformant to 264 the XML defined in [8] and use the element as the root 265 element. 267 In the context of IRIS-LWZ, the protocol identifiers for these 268 elements are as follows: 270 - the value "iris.lwz1" to indicate the 271 protocol specified in this document. 273 - the XML namespace identifier for IRIS [3]. 275 - the XML namespace identifier for IRIS registries. 277 This document defines no extension identifiers and no authentication 278 mechanism identifiers. 280 Servers SHOULD send version information in the following cases: 282 1. In response to a version information request (i.e. the PT flag is 283 set to 'vi'). 285 2. The version in a payload descriptor header does not match a 286 version the server supports. 288 3. The IRIS-based XML payload does not match a version the server 289 supports. 291 The protocols identified by the element MUST only 292 indicate protocols running on the same socket as the sender of the 293 corresponding response. In other words, while a server operator may 294 also be running IRIS-XPC [9], this XML instance is only intended to 295 describe version negotiation for IRIS-LWZ. 297 The definition of octet size for the 'requestSizeOctets' and 298 'responseSizeOctets' attributes of the element are 299 defined in Section 3.1.6. 301 3.1.6. Size Information 303 A payload type with size information ('si') MUST be comformant to the 304 XML defined in [8] and use the element as the root element. 306 Octet counts provided by this information are defined as the total 307 length of the UDP packet (i.e. UDP header length + payload 308 descriptor length + XML payload length). 310 3.1.7. Other Information 312 A payload type with other information ('oi') MUST be comformant to 313 the XML defined in [8] and use the element as the root 314 element. 316 The values for the 'type' attribute of are as follows: 318 'descriptor-error' - indicates there was an error decoding the 319 descriptor. Servers SHOULD send a descriptor error in the 320 following cases: 322 1. When a request is received with a payload type indicating size 323 information (i.e. the PT flag is 'si'). 325 2. When a request is received with a payload type indicating 326 other information (i.e. the PT flag is 'oi'). 328 3. When a request is sent with a transaction ID of 0xFFFF (which 329 is reserved for server use). 331 4. When a request is received with an incomplete or truncated 332 payload descriptor. 334 5. When reserved bits in the payload descriptor are set to values 335 other than zero. 337 'payload-error' - indicates there was an error interpretting the 338 payload. Servers MUST send a payload error if they receive XML 339 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 341 'system-error' - indicates that the receiver cannot process the 342 request due to a condition not related to this protocol. Servers 343 SHOULD send a system-error when they are capable of responding to 344 requests but not capable of processing requests. 346 'authority-error' - indicates that the intended authority 347 specified in the corresponding request is not served by the 348 receiver. Servers SHOULD send an authority error when they 349 receive a request directed to an authority other than those they 350 serve. 352 'no-inflation-support-error' - indicates that the receiver does 353 not support payloads that have been compressed with DEFLATE [1]. 354 Servers MUST send this error when they receive a request that has 355 been compressed with DEFLATE but they do not support inflation. 357 4. Interactions 359 The intent of IRIS-LWZ is to utilize UDP for IRIS requests and 360 responses when UDP is appropriate. Not all IRIS requests and 361 responses will be able to utilize UDP and may require the use of 362 other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The 363 following strategy SHOULD be used: 365 1. If a request requires authentication, confidentiality, or other 366 security, use another transfer protocol. IRIS-XPC [9] is 367 RECOMMENDED. 369 2. If a request is less than or equal to 4000 octets, send it 370 uncompressed. 372 3. If a request can be compressed to a size less than or equal to 373 4000 octets, send the request using compression. Otherwise use 374 another transfer protocol. In cases where another transfer 375 protocol is needed, IRIS-XPC [9] is RECOMMENDED. 377 4. If a request yields a size error, send the request with another 378 transfer protocol. IRIS-XPC [9] is RECOMMENDED. 380 For retransmission of requests considered to be unanswered, a client 381 SHOULD retransmit using a timeout value initially set to 1 second. 382 This timeout value SHOULD be doubled for every retransmission, and it 383 a client SHOULD not retransmit any request once the timeout value has 384 reached 60 seconds. 386 Additionally, if a client intends thousands of requests to the same 387 server in a short amount of time, this protocol offers no real 388 advantage over IRIS-XPC [9]. In such a case, IRIS-XPC should be used 389 as it would be similarly effecient and would offer greater reponse 390 sizes and allow better security. 392 5. Internationalization Considerations 394 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 395 encodings. Use of the XML defined by [8] MUST NOT use any other 396 character encodings other than UTF-8 or UTF-16. 398 6. IRIS Transport Mapping Definitions 400 This section lists the definitions required by IRIS [3] for transport 401 mappings. 403 6.1. URI Scheme 405 See Section 7.1.1. 407 6.2. Application Protocol Label 409 See Section 7.1.3. 411 7. IANA Considerations 413 7.1. Registrations 415 7.1.1. URI Scheme Registration 417 URL scheme name: iris.lwz 419 URL scheme syntax: defined in Section 6.1 and [3]. 421 Character encoding considerations: as defined in RFC2396 [5]. 423 Intended usage: identifies an IRIS entity made available using XML 424 over UDP 426 Applications using this scheme: defined in IRIS [3]. 428 Interoperability considerations: n/a 430 Security Considerations: defined in Section 8. 432 Relevant Publications: IRIS [3]. 434 Contact Information: Andrew Newton 436 Author/Change controller: the IESG 438 7.1.2. Well-known UDP Port Registration 440 Protocol Number: UDP 442 UDP Port Number: TBD by IANA 444 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 445 and Section 3.1. 447 Functions: defined in IRIS [3]. 449 Use of Broadcast/Multicast: none 451 Proposed Name: IRIS-LWZ 453 Short name: iris.lwz 455 Contact Information: Andrew Newton 457 7.1.3. S-NAPTR Registration 459 Application Protocol Label (see [4]): iris.lwz 461 Intended usage: identifies an IRIS server using XML over UDP 463 Interoperability considerations: n/a 465 Security Considerations: defined in Section 8. 467 Relevant Publications: IRIS [3]. 469 Contact Information: Andrew Newton 471 Author/Change controller: the IESG 473 8. Security Considerations 475 IRIS-LWZ is intended for serving public data; it provides no in-band 476 mechanisms for authentication or confidentiality. Any application 477 with these needs must provide out of band mechanisms (e.g., IPSec), 478 or use the IRIS transfer protocols that provides such capabilities, 479 such as IRIS-XPC [9]. 481 Due to this lack of security, it is possible for an attacker to alter 482 IRIS-LWZ messages sent from the client to the server and from the 483 server to the client. Such an attack can result in denying usage of 484 an IRIS service or in supplying false information to end users and 485 many other scenarios. 487 Because IRIS-LWZ is a UDP based protocol, it is possible for servers 488 using IRIS-LWZ to be used in a type of distributed denial of service 489 attack known as a reflection attack. This type of attack affects 490 other types of UDP using protocols, such as DNS. Server operators 491 should be prepared to apply the same methods used for mitigating 492 reflection attacks with other protocols, such as DNS, when using 493 IRIS-LWZ. All operators should follow the advice given in BCP 38 494 [7]. 496 IRIS-LWZ uses transaction IDs in the payload descriptors to better 497 enable a client to match a response to a request. By randomizing the 498 transaction IDs being used (i.e. not using sequential numbers), 499 attackers flooding the network with a large amount of spoofed packets 500 have a lesser chance of succeeding with the attack. This measure is 501 not guaranteed to thwart any such attack. Client implementers MUST 502 take appropriate measures when ignoring this advice. 504 9. Normative References 506 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 507 version 1.3", RFC 1951, May 1996. 509 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 510 ISBN 0-201-61633-5, 2000, . 512 [3] Newton, A. and M. Sanz, "Internet Registry Information 513 Service", RFC 3891, January 2004. 515 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 516 Location Using SRV RRs and the Dynamic Delegation Discovery 517 Service (DDDS)", RFC 3958, January 2005. 519 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 520 Resource Identifiers (URI): Generic Syntax", RFC 2396, 521 August 1998. 523 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 524 Levels", RFC 2119, BCP 14, March 1997. 526 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: 527 Defeating Denial of Service Attacks which employ IP Source 528 Address Spoofing", BCP 38, RFC 2827, May 2000. 530 [8] Newton, A., "A Common Schema for Internet Registry Information 531 Service Transfer Protocols", 532 draft-ietf-crips-iris-common-transport-00 (work in progress), 533 April 2005. 535 [9] Newton, A., "XML Pipelining with Chunks for the Information 536 Registry Information Service", draft-ietf-crips-iris-xpc-05 537 (work in progress), January 2007. 539 [10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 540 RFC 1166, July 1990. 542 Appendix A. Examples 544 This section gives examples of IRIS-LWZ exchanges. Lines beginning 545 with "C:" denote data sent by the client to the server, and lines 546 beginning with "S:" denote data sent by the server to the client. 547 Following the "C:" or "S:", the line either contains octet values in 548 hexadecimal notation with comments or XML fragments. No line 549 contains both octet values with comments and XML fragments. Comments 550 are contained within parenthesis. 552 The following example demonstrates an IRIS client requesting a lookup 553 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 554 client passes a bag with the search request. The server responds 555 with a 'nameNotFound' response and an explanation. 557 C: (request packet) 558 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 559 C: 0x03 0xA4 (transaction ID=932) 560 C: 0x05 0xDA (maximum response size=1498) 561 C: 0x09 (authority length=9) 562 C: (authority="localhost") 563 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 564 C: (IRIS XML request) 565 C: 567 C: 568 C: 569 C: 570 C: 127.0.0.1:3434 571 C: 4LnQ1KdCahzyvwBqJis5rw== 572 C: 573 C: 574 C: 578 C: 579 C: 581 S: (response packet) 582 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 583 S: 0x03 0xA4 (transaction ID=932) 584 S: (IRIS XML response) 585 S: 586 S: 587 S: 588 S: The name 'AUP' is not found in 'local'. 589 S: 591 Figure 4: Example 1 593 The following example demonstrates an IRIS client requesting domain 594 availability information for 'milo.example.com'. The server responds 595 that the domain is assigned and active. 597 C: (request packet) 598 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 599 C: 0x0B 0xE7 (transaction ID=3047) 600 C: 0x0F 0xA0 (maximum response size=4000) 601 C: 0x0B (authority length=11) 602 C: (authority="example.com") 603 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 604 C: (IRIS XML request) 605 C: 608 C: 609 C: 613 C: 614 C: 616 S: (response packet) 617 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 618 S: 0x0B 0xE7 (transaction ID=3047) 619 S: (IRIS XML response) 620 S: 621 S: 626 S: milo.example.com 627 S: 628 S: 630 Figure 5: Example 2 632 The following example demonstrates an IRIS client requesting domain 633 availability information for felix.example.net, hobbes.example.net, 634 and daffy.example.net. The client does not support responses 635 compressed with DEFLATE and the maximum UDP packet it can safely 636 receive is 498 octets. The server responds with size information 637 indicating that it would take 1211 octets to provide an answer. 639 C: (request packet) 640 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 641 C: 0x7E 0x8A (transaction ID=32394) 642 C: 0x01 0xF2 (maximum response size=498) 643 C: 0x0B (authority length=11) 644 C: (authority="example.net") 645 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 646 C: (IRIS XML request) 647 C: 650 C: 651 C: 653 C: 654 C: 655 C: 657 C: 658 C: 659 C: 661 C: 662 C: 664 S: (response packet) 665 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 666 S: 0x7E 0x8A (transaction ID=32394) 667 S: (Size Information XML response) 668 S: 669 S: 1211 670 S: 672 Figure 6: Example 3 674 The following example illustrates an IRIS client requesting the 675 version information from a server, and the server returning the 676 verion information. 678 C: (request packet) 679 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 680 C: 0x2E 0x9C (transaction ID=11932) 681 C: 0x01 0xF2 (maximum response size=498) 682 C: 0x0B (authority length=11) 683 C: (authority="example.net") 684 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 686 S: (response packet) 687 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 688 S: 0x2E 0x9C (transaction ID=11932) 689 S: (Version Information XML response) 690 S: 691 S: 692 S: 693 S: 694 S: 695 S: 696 S: 697 S: 699 Figure 7: Example 4 701 Appendix B. Contributors 703 Substantive contributions to this document have been provided by the 704 members of the IETF's CRISP Working Group, especially Milena Caires 705 and David Blacka. 707 Author's Address 709 Andrew L. Newton 710 VeriSign, Inc. 711 21345 Ridgetop Circle 712 Sterling, VA 20166 713 USA 715 Phone: +1 703 948 3382 716 Email: andy@hxr.us 717 URI: http://www.verisignlabs.com/ 719 Intellectual Property Statement 721 The IETF takes no position regarding the validity or scope of any 722 Intellectual Property Rights or other rights that might be claimed to 723 pertain to the implementation or use of the technology described in 724 this document or the extent to which any license under such rights 725 might or might not be available; nor does it represent that it has 726 made any independent effort to identify any such rights. Information 727 on the procedures with respect to rights in RFC documents can be 728 found in BCP 78 and BCP 79. 730 Copies of IPR disclosures made to the IETF Secretariat and any 731 assurances of licenses to be made available, or the result of an 732 attempt made to obtain a general license or permission for the use of 733 such proprietary rights by implementers or users of this 734 specification can be obtained from the IETF on-line IPR repository at 735 http://www.ietf.org/ipr. 737 The IETF invites any interested party to bring to its attention any 738 copyrights, patents or patent applications, or other proprietary 739 rights that may cover technology that may be required to implement 740 this standard. Please address the information to the IETF at 741 ietf-ipr@ietf.org. 743 Disclaimer of Validity 745 This document and the information contained herein are provided on an 746 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 747 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 748 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 749 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 750 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 751 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 753 Copyright Statement 755 Copyright (C) The Internet Society (2007). This document is subject 756 to the rights, licenses and restrictions contained in BCP 78, and 757 except as set forth therein, the authors retain all their rights. 759 Acknowledgment 761 Funding for the RFC Editor function is currently provided by the 762 Internet Society.