idnits 2.17.1 draft-ietf-crisp-iris-lwz-06.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 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 703. ** 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 -- 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 (May 25, 2006) is 6517 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 (~~), 2 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: November 26, 2006 May 25, 2006 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-06 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 November 26, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . 17 72 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 22 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 74 Intellectual Property and Copyright Statements . . . . . . . . . . 24 76 1. Introduction 78 Using S-NAPTR [4], IRIS has the ability to define the use of multiple 79 application transports or transfer protocols for different types of 80 registry services, all at the descretion of the server operator. The 81 UDP transfer protocol defined in this document is completely modular 82 and may be used by any registry types. 84 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 85 (for IRIS Lightweight using Compression). Its message exchange 86 pattern is simple: a client sends a request in one UDP packet, and a 87 server responds with an answer in one UDP packet. 89 IRIS-LWZ packets are composed of two parts, a binary payload 90 descriptor and an request/response transaction payload. The request/ 91 response transaction payload may be compressed using the DEFLATE [1] 92 algorithm. 94 2. Document Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC2119 [6]. 100 Octet fields with numberic values are given according to the 101 conventions in RFC 1166 [8]: the left most bit of the whole field is 102 the most significant bit; when a multi-octet quantity is transmitted 103 the most significant octet is transmitted first. Bits signifying 104 flags in an octet are numbered according to the conventions of RFC 105 1166 [8]: bit 0 is the most significant bit and bit 7 is the least 106 significant bit. When a diagram describes a group of octets, the 107 order of tranmission for the octets starts from the left. 109 3. Packet Format 111 The UDP packet format for IRIS-LWZ is as follows: 113 +------+------+----------+--------+------------+---------+ 114 field | src | dest | checksum | UDP | payload | payload | 115 | port | port | | length | descriptor | | 116 +------+------+----------+--------+------------+---------+ 117 octets 2 2 2 2 3 or 6..261* 0..n 119 * In request packets, the payload descriptor can vary in length 120 from 6 to 261 octets (i.e. 6..261). In response packets, the 121 payload descriptor is always 3 octets. 123 (where "src port" means source port and "dest port" means destination 124 port). 126 Each IRIS-LWZ query or response is contained in a single UDP packet. 127 Servers MUST be prepared to accepted packets as large as 4000 octets, 128 and clients MUST NOT send packets larger than 4000 octets. 130 3.1. Payload Descriptor 132 The payload descriptor has two different formats, one for a request 133 and one for a response. However, each format shares a common 1 octet 134 payload header described in Section 3.1.3. 136 3.1.1. Payload Request Descriptor 138 The payload descriptor for request packets varies from 6 to 261 139 octets in lenght and has the following format: 141 +--------+-------------+----------+-----------+-----------+ 142 field | header | transaction | maximum | authority | authority | 143 | | ID | response | length | | 144 | | | length | | | 145 +--------+-------------+----------+-----------+-----------+ 146 octets 1 2 2 1 0..255 148 These fields have the following meanings: 150 header - as described in Section 3.1.3. 152 transaction ID - a 16 bit value identifying the transaction. This 153 value will be returned in the payload response descriptor 154 (Section 3.1.2) and can be used by clients to match requests with 155 responses. Clients SHOULD pick the value randomly and SHOULD NOT 156 use sequences of 16 bit values. Clients MUST NOT set all the bits 157 in this value to 1 (i.e. use a value of 0xFFFF). 159 maximum response length - the total length of the UDP packet (i.e. 160 UDP header length + payload descriptor length + XML payload 161 length) that should not be exceeded when responding to this 162 request. If the server cannot provide a response that is equal to 163 or less than this value, then it MUST respond with size 164 information (Section 3.1.6). 166 authority length - the length of the authority field in this 167 payload descriptor. 169 authority - a string of octets describing the authority against 170 wich this request is to be executed. See [3] for the definition 171 and description of an authority. The number of octets in this 172 string MUST be no more and no less than the number specified by 173 the authority length. 175 3.1.2. Payload Response Descriptor 177 The payload descriptor for response packets is always 3 octets and 178 consists of a payload header (Section 3.1.3) and a transaction ID. 180 +--------+-------------+ 181 field | header | transaction | 182 | | ID | 183 +--------+-------------+ 184 octets 1 2 186 The purpose of the transaction ID is to allow clients to match 187 requests to responses. A value of 0xFFFF is reserved for server use. 188 The value of the transaction ID is as follows: 190 1. If the transaction ID in the corresponding request could not be 191 read due to truncation, servers MUST use a transaction ID with 192 all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor 193 error (see Section 3.1.7). 195 2. If the transaction ID in the corresponding request is a value of 196 0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a 197 descriptor error (see Section 3.1.7). 199 3. Otherwise, the transaction ID MUST be the value of the 200 transaction ID of the corresponding request. 202 3.1.3. Payload Header 204 The bits of the payload header are ordered according to RFC 1166 [8], 205 where bit 0 is the most significant and bit 7 is the least 206 significant. Each bit in the one octet payload header has the 207 following meaning: 209 bits 0 and 1 - version number ('V' field) - If 0 (both bits are 210 zero), the protocol is the version defined in this document. 211 Otherwise, the rest of the bits in the header and the payload may 212 be interpreted as another version. 214 bit 2 - request/response flag ('RR' flag) - If 0, this packet is a 215 request (Section 3.1.1) packet. If 1, this packet is a response 216 (Section 3.1.2) packet. 218 bits 3 - payload deflated ('PD' flag) - If 1, the payload is 219 compressed using the DEFLATE [1] algorithm. 221 bit 4 - deflate supported ('DS' flag) - If 1, the sender of this 222 packet supports compression using the DEFLATE algorithm. When 223 this bit is 0 in a request, the payload of the response MUST NOT 224 be compressed with DEFLATE. 226 bit 5 - reserved - This MUST be 0. 228 bits 6 and 7 - The value of these bits indicate payload types 229 (Section 3.1.4) ('PT' field). 231 3.1.4. Payload Types 233 A payload type indicates the type of content in the UDP packet 234 following the payload descriptor. Some payload types have no meaning 235 in request packets, and some payload types differ in meaning between 236 requests and responses. Some payload types indicate an empty 237 payload. 239 The payload type values in binary are as follows: 241 00 - xml payload ('xml' type). The payload is either an IRIS- 242 based XML request or an IRIS-based XML response. 244 01 - version info ('vi' type). In a request packet, this payload 245 type indicates that the server is to respond with version 246 information (Section 3.1.5), and that the payload is empty. In a 247 response packet, this payload type indicates that the payload is 248 version information (Section 3.1.5). 250 10 - size info ('si' type). This payload type has no meaning in a 251 request packet and is a descriptor error. In a response packet, 252 this payload type indicates that the payload is size information 253 (Section 3.1.6). 255 11 - other info ('oi' type). This payload type has no meaning in 256 a request packet and is a descriptor error. In a response packet, 257 this payload type indicates that the payload is other information 258 (Section 3.1.7). 260 3.1.5. Version Information 262 A payload type with version information ('vi') MUST be comformant to 263 the XML defined in [7] and use the element as the root 264 element. 266 In the context of IRIS-LWZ, the protocol identifiers for these 267 elements are as follows: 269 - the value "iris.lwz1" to indicate the 270 protocol specified in this document. 272 - the XML namespace identifier for IRIS [3]. 274 - the XML namespace identifier for IRIS registries. 276 This document defines no extension identifiers and no authentication 277 mechanism identifiers. 279 Servers SHOULD send version information in the following cases: 281 1. In response to a version information request (i.e. the PT flag is 282 set to 'vi'). 284 2. The version in a payload descriptor header does not match a 285 version the server supports. 287 3. The IRIS-based XML payload does not match a version the server 288 supports. 290 The protocols identified by the element MUST only 291 indicate protocols running on the same socket as the sender of the 292 corresponding request. In other words, while a server operator may 293 also be running IRIS-XPC, this XML instance is only intended to 294 describe version negotiation for IRIS-LWZ. 296 The definition of octet size for the 'requestSizeOctets' and 297 'responseSizeOctets' attributes of the element are 298 defined in Section 3.1.6. 300 3.1.6. Size Information 302 A payload type with size information ('si') MUST be comformant to the 303 XML defined in [7] and use the element as the root element. 305 Octet counts provided by this information are defined as the total 306 length of the UDP packet (i.e. UDP header length + payload 307 descriptor length + XML payload length). 309 3.1.7. Other Information 311 A payload type with other information ('oi') MUST be comformant to 312 the XML defined in [7] and use the element as the root 313 element. 315 The values for the 'type' attribute of are as follows: 317 'descriptor-error' - indicates there was an error decoding the 318 descriptor. Servers SHOULD send a descriptor error in the 319 following cases: 321 1. When a request is received with a payload type indicating size 322 information (i.e. the PT flag is 'si'). 324 2. When a request is received with a payload type indicating 325 other information (i.e. the PT flag is 'oi'). 327 3. When a request is sent with a transaction ID of 0xFFFF (which 328 is reserved for server use). 330 4. When a request is received with an incomplete or truncated 331 payload descriptor. 333 5. When reserved bits in the payload descriptor are set to values 334 other than zero. 336 'payload-error' - indicates there was an error interpretting the 337 payload. Servers MUST send a payload error if they receive XML 338 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 340 'system-error' - indicates that the receiver cannot process the 341 request due to a condition not related to this protocol. Servers 342 SHOULD send a system-error when they are capable of responding to 343 requests but not capable of processing requests. 345 'authority-error' - indicates that the intended authority 346 specified in the corresponding request is not served by the 347 receiver. Servers SHOULD send an authority error when they 348 receive a request directed to an authority other than those they 349 serve. 351 'no-inflation-support-error' - indicates that the receiver does 352 not support payloads that have been compressed with DEFLATE [1]. 353 Servers MUST send this error when they receive a request that has 354 been compressed with DEFLATE but they do not support inflation. 356 4. Interactions 358 The intent of IRIS-LWZ is to utilize UDP for IRIS requests and 359 responses when UDP is appropriate. Not all IRIS requests and 360 responses will be able to utilize UDP and may require the use of 361 other transfer protocols (i.e. IRIS-XPC and/or BEEP). The following 362 strategy SHOULD be used: 364 1. If a request requires authentication, confidentiality, or other 365 security, use another transfer protocol. 367 2. If a request is less than or equal to 4000 octets, send it 368 uncompressed. 370 3. If a request can be compressed to a size less than or equal to 371 4000 octets, send the request using compression. Otherwise use 372 another transfer protocol. 374 4. If a request yields a size error, send the request with another 375 transfer protocol. 377 5. Internationalization Considerations 379 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 380 encodings. Use of the XML defined by [7] MUST NOT use any other 381 character encodings other than UTF-8 or UTF-16. 383 6. IRIS Transport Mapping Definitions 385 This section lists the definitions required by IRIS [3] for transport 386 mappings. 388 6.1. URI Scheme 390 See Section 7.1.1. 392 6.2. Application Protocol Label 394 See Section 7.1.3. 396 7. IANA Considerations 398 7.1. Registrations 400 7.1.1. URI Scheme Registration 402 URL scheme name: iris.lwz 404 URL scheme syntax: defined in Section 6.1 and [3]. 406 Character encoding considerations: as defined in RFC2396 [5]. 408 Intended usage: identifies an IRIS entity made available using XML 409 over UDP 411 Applications using this scheme: defined in IRIS [3]. 413 Interoperability considerations: n/a 415 Security Considerations: defined in Section 8. 417 Relevant Publications: IRIS [3]. 419 Contact Information: Andrew Newton 421 Author/Change controller: the IESG 423 7.1.2. Well-known UDP Port Registration 425 Protocol Number: UDP 427 UDP Port Number: TBD by IANA 429 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 430 and Section 3.1. 432 Functions: defined in IRIS [3]. 434 Use of Broadcast/Multicast: none 436 Proposed Name: IRIS-LWZ 438 Short name: iris.lwz 440 Contact Information: Andrew Newton 442 7.1.3. S-NAPTR Registration 444 Application Protocol Label (see [4]): iris.lwz 446 Intended usage: identifies an IRIS server using XML over UDP 448 Interoperability considerations: n/a 450 Security Considerations: defined in Section 8. 452 Relevant Publications: IRIS [3]. 454 Contact Information: Andrew Newton 456 Author/Change controller: the IESG 458 8. Security Considerations 460 IRIS-LWZ is intended for serving public data; it provides no in-band 461 mechanisms for authentication or encryption. Any application with 462 this need must provide out of band mechanisms to provide it (e.g., 463 IPSec), or use the IRIS transfer protocols that provides such 464 capabilities. 466 Because IRIS-LWZ is a UDP based protocol, it is possible for servers 467 using IRIS-LWZ to be used in a type of distributed denial of service 468 attack known as a reflection attack. This type of attack affects 469 other types of UDP using protocols, such as DNS. Server operators 470 should be prepared to apply the same methods used for mitigating 471 reflection attacks with other protocols, such as DNS, when using 472 IRIS-LWZ. 474 9. Normative References 476 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 477 version 1.3", RFC 1951, May 1996. 479 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 480 ISBN 0-201-61633-5, 2000, . 482 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 483 RFC 3891, January 2004. 485 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 486 Location Using SRV RRs and the Dynamic Delegation Discovery 487 Service (DDDS)", RFC 3958, January 2005. 489 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 490 Resource Identifiers (URI): Generic Syntax", RFC 2396, 491 August 1998. 493 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Levels", RFC 2119, BCP 14, March 1997. 496 [7] Newton, A., "A Common Schema for Internet Registry Information 497 Service Transfer Protocols", 498 draft-ietf-crips-iris-common-transport-00 (work in progress), 499 April 2005. 501 [8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 502 RFC 1166, July 1990. 504 Appendix A. Examples 506 This section gives examples of IRIS-LWZ exchanges. Lines beginning 507 with "C:" denote data sent by the client to the server, and lines 508 beginning with "S:" denote data sent by the server to the client. 509 Following the "C:" or "S:", the line either contains octet values in 510 hexadecimal notation with comments or XML fragments. No line 511 contains both octet values with comments and XML fragments. Comments 512 are contained within parenthesis. 514 The following example demonstrates an IRIS client requesting a lookup 515 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 516 client passes a bag with the search request. The server responds 517 with a 'nameNotFound' response and an explanation. 519 C: (request packet) 520 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 521 C: 0x03 0xA4 (transaction ID=932) 522 C: 0x05 0xDA (maximum response size=1498) 523 C: 0x09 (authority length=9) 524 C: (authority="localhost") 525 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 526 C: (IRIS XML request) 527 C: 529 C: 530 C: 531 C: 532 C: 127.0.0.1:3434 533 C: 4LnQ1KdCahzyvwBqJis5rw== 534 C: 535 C: 536 C: 540 C: 541 C: 543 S: (response packet) 544 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 545 S: 0x03 0xA4 (transaction ID=932) 546 S: (IRIS XML response) 547 S: 548 S: 549 S: 550 S: The name 'AUP' is not found in 'local'. 551 S: 553 Figure 4: Example 1 555 The following example demonstrates an IRIS client requesting domain 556 availability information for 'milo.example.com'. The server responds 557 that the domain is assigned and active. 559 C: (request packet) 560 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 561 C: 0x0B 0xE7 (transaction ID=3047) 562 C: 0x0F 0xA0 (maximum response size=4000) 563 C: 0x0B (authority length=11) 564 C: (authority="example.com") 565 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 566 C: (IRIS XML request) 567 C: 570 C: 571 C: 575 C: 576 C: 578 S: (response packet) 579 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 580 S: 0x0B 0xE7 (transaction ID=3047) 581 S: (IRIS XML response) 582 S: 583 S: 588 S: milo.example.com 589 S: 590 S: 592 Figure 5: Example 2 594 The following example demonstrates an IRIS client requesting domain 595 availability information for felix.example.net, hobbes.example.net, 596 and daffy.example.net. The client does not support responses 597 compressed with DEFLATE and the maximum UDP packet it can safely 598 receive is 498 octets. The server responds with size information 599 indicating that it would take 1211 octets to provide an answer. 601 C: (request packet) 602 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 603 C: 0x7E 0x8A (transaction ID=32394) 604 C: 0x01 0xF2 (maximum response size=498) 605 C: 0x0B (authority length=11) 606 C: (authority="example.net") 607 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 608 C: (IRIS XML request) 609 C: 612 C: 613 C: 615 C: 616 C: 617 C: 619 C: 620 C: 621 C: 623 C: 624 C: 626 S: (response packet) 627 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 628 S: 0x7E 0x8A (transaction ID=32394) 629 S: (Size Information XML response) 630 S: 631 S: 1211 632 S: 634 Figure 6: Example 3 636 The following example illustrates an IRIS client requesting the 637 version information from a server, and the server returning the 638 verion information. 640 C: (request packet) 641 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 642 C: 0x2E 0x9C (transaction ID=11932) 643 C: 0x01 0xF2 (maximum response size=498) 644 C: 0x0B (authority length=11) 645 C: (authority="example.net") 646 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 648 S: (response packet) 649 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 650 S: 0x2E 0x9C (transaction ID=11932) 651 S: (Version Information XML response) 652 S: 653 S: 654 S: 655 S: 656 S: 657 S: 658 S: 659 S: 661 Figure 7: Example 4 663 Appendix B. Contributors 665 Substantive contributions to this document have been provided by the 666 members of the IETF's CRISP Working Group, especially Milena Caires 667 and David Blacka. 669 Author's Address 671 Andrew L. Newton 672 VeriSign, Inc. 673 21345 Ridgetop Circle 674 Sterling, VA 20166 675 USA 677 Phone: +1 703 948 3382 678 Email: andy@hxr.us 679 URI: http://www.verisignlabs.com/ 681 Intellectual Property Statement 683 The IETF takes no position regarding the validity or scope of any 684 Intellectual Property Rights or other rights that might be claimed to 685 pertain to the implementation or use of the technology described in 686 this document or the extent to which any license under such rights 687 might or might not be available; nor does it represent that it has 688 made any independent effort to identify any such rights. Information 689 on the procedures with respect to rights in RFC documents can be 690 found in BCP 78 and BCP 79. 692 Copies of IPR disclosures made to the IETF Secretariat and any 693 assurances of licenses to be made available, or the result of an 694 attempt made to obtain a general license or permission for the use of 695 such proprietary rights by implementers or users of this 696 specification can be obtained from the IETF on-line IPR repository at 697 http://www.ietf.org/ipr. 699 The IETF invites any interested party to bring to its attention any 700 copyrights, patents or patent applications, or other proprietary 701 rights that may cover technology that may be required to implement 702 this standard. Please address the information to the IETF at 703 ietf-ipr@ietf.org. 705 Disclaimer of Validity 707 This document and the information contained herein are provided on an 708 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 709 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 710 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 711 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 712 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 715 Copyright Statement 717 Copyright (C) The Internet Society (2006). This document is subject 718 to the rights, licenses and restrictions contained in BCP 78, and 719 except as set forth therein, the authors retain all their rights. 721 Acknowledgment 723 Funding for the RFC Editor function is currently provided by the 724 Internet Society.