idnits 2.17.1 draft-ietf-crisp-iris-lwz-05.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 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 6 has weird spacing: '...for the the I...' == Line 149 has weird spacing: '...esponse descr...' == Line 224 has weird spacing: '...payload types...' == Line 253 has weird spacing: '...s other infor...' == Line 277 has weird spacing: '... 1. In respo...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2006) is 6653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) -- No information found for draft-ietf-crips-iris-common-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '8') Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: August 11, 2006 February 7, 2006 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-05 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 August 11, 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 . . . . . . . . . . . . . . . . . . . . 6 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 72 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 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..261 0..n 119 (where "src port" means source port and "dest port" means destination 120 port). 122 Each IRIS-LWZ query or response is contained in a single UDP packet. 123 Servers MUST be prepared to accepted packets as large as 4000 octets, 124 and clients MUST NOT send packets larger than 4000 octets. 126 3.1 Payload Descriptor 128 The payload descriptor has two different formats, one for a request 129 and one for a response. However, each format shares a common 1 octet 130 payload header described in Section 3.1.3. 132 3.1.1 Payload Request Descriptor 134 The payload descriptor for request packets varies from 6 to 261 135 octets in lenght and has the following format: 137 +--------+-------------+----------+-----------+-----------+ 138 field | header | transaction | maximum | authority | authority | 139 | | ID | response | length | | 140 | | | length | | | 141 +--------+-------------+----------+-----------+-----------+ 142 octets 1 2 2 1 0..255 144 These fields have the following meanings: 146 header - as described in Section 3.1.3. 148 transaction ID - a 16 bit value identifying the transaction. This 149 value will be returned in the payload response descriptor 150 (Section 3.1.2) and can be used by clients to match requests with 151 responses. Clients SHOULD pick the value randomly and SHOULD NOT 152 use sequences of 16 bit values. Clients MUST NOT set all the bits 153 in this value to 1 (i.e. use a value of 0xFFFF). 155 maximum response length - the total length of the UDP packet (i.e. 156 UDP header length + payload descriptor length + XML payload 157 length) that should not be exceeded when responding to this 158 request. If the server cannot provide a response that is equal to 159 or less than this value, then it MUST respond with size 160 information (Section 3.1.6). 162 authority length - the length of the authority field in this 163 payload descriptor. 165 authority - a string of octets describing the authority against 166 wich this request is to be executed. See [3] for the definition 167 and description of an authority. The number of octets in this 168 string MUST be no more and no less than the number specified by 169 the authority length. 171 3.1.2 Payload Response Descriptor 173 The payload descriptor for response packets is always 3 octets and 174 consists of a payload header (Section 3.1.3) and a transaction ID. 176 +--------+-------------+ 177 field | header | transaction | 178 | | ID | 179 +--------+-------------+ 180 octets 1 2 182 The purpose of the transaction ID is to allow clients to match 183 requests to responses. A value of 0xFFFF is reserved for server use. 184 The value of the transaction ID is as follows: 186 1. If the transaction ID in the corresponding request could not be 187 read due to truncation, servers MUST use a transaction ID with 188 all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor 189 error (see Section 3.1.7). 191 2. If the transaction ID in the corresponding request is a value of 192 0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a 193 descriptor error (see Section 3.1.7). 195 3. Otherwise, the transaction ID MUST be the value of the 196 transaction ID of the corresponding request. 198 3.1.3 Payload Header 200 The bits of the payload header are ordered according to RFC 1166 [8], 201 where bit 0 is the most significant and bit 7 is the least 202 significant. Each bit in the one octet payload header has the 203 following meaning: 205 bits 0 and 1 - version number ('V' field) - If 0 (both bits are 206 zero), the protocol is the version defined in this document. 207 Otherwise, the rest of the bits in the header and the payload may 208 be interpreted as another version. 210 bit 2 - request/response flag ('RR' flag) - If 0, this packet is a 211 request (Section 3.1.1) packet. If 1, this packet is a response 212 (Section 3.1.2) packet. 214 bits 3 - payload deflated ('PD' flag) - If 1, the payload is 215 compressed using the DEFLATE [1] algorithm. 217 bit 4 - deflate supported ('DS' flag) - If 1, the sender of this 218 packet supports compression using the DEFLATE algorithm. When 219 this bit is 0 in a request, the payload of the response MUST NOT 220 be compressed with DEFLATE. 222 bit 5 - reserved - This MUST be 0. 224 bits 6 and 7 - The value of these bits indicate payload types 225 (Section 3.1.4) ('PT' field). 227 3.1.4 Payload Types 229 A payload type indicates the type of content in the UDP packet 230 following the payload descriptor. Some payload types have no meaning 231 in request packets, and some payload types differ in meaning between 232 requests and responses. Some payload types indicate an empty 233 payload. 235 The payload type values in binary are as follows: 237 00 - xml payload ('xml' type). The payload is either an IRIS- 238 based XML request or an IRIS-based XML response. 240 01 - version info ('vi' type). In a request packet, this payload 241 type indicates that the server is to respond with version 242 information (Section 3.1.5), and that the payload is empty. In a 243 response packet, this payload type indicates that the payload is 244 version information (Section 3.1.5). 246 10 - size info ('si' type). This payload type has no meaning in a 247 request packet and is a descriptor error. In a response packet, 248 this payload type indicates that the payload is size information 249 (Section 3.1.6). 251 11 - other info ('oi' type). This payload type has no meaning in 252 a request packet and is a descriptor error. In a response packet, 253 this payload type indicates that the payload is other information 254 (Section 3.1.7). 256 3.1.5 Version Information 258 A payload type with version information ('vi') MUST be comformant to 259 the XML defined in [7] and use the element as the root 260 element. 262 In the context of IRIS-LWZ, the protocol identifiers for these 263 elements are as follows: 265 - the value "iris.lwz1" to indicate the 266 protocol specified in this document. 268 - the XML namespace identifier for IRIS [3]. 270 - the XML namespace identifier for IRIS registries. 272 This document defines no extension identifiers and no authentication 273 mechanism identifiers. 275 Servers SHOULD send version information in the following cases: 277 1. In response to a version information request (i.e. the PT flag 278 is set to 'vi'). 280 2. The version in a payload descriptor header does not match a 281 version the server supports. 283 3. The IRIS-based XML payload does not match a version the server 284 supports. 286 The protocols identified by the element MUST only 287 indicate protocols running on the same socket as the sender of the 288 corresponding request. In other words, while a server operator may 289 also be running IRIS-XPC, this XML instance is only intended to 290 describe version negotiation for IRIS-LWZ. 292 The definition of octet size for the 'requestSizeOctets' and 293 'responseSizeOctets' attributes of the element are 294 defined in Section 3.1.6. 296 3.1.6 Size Information 298 A payload type with size information ('si') MUST be comformant to the 299 XML defined in [7] and use the element as the root element. 301 Octet counts provided by this information are defined as the total 302 length of the UDP packet (i.e. UDP header length + payload 303 descriptor length + XML payload length). 305 3.1.7 Other Information 307 A payload type with other information ('oi') MUST be comformant to 308 the XML defined in [7] and use the element as the root 309 element. 311 The values for the 'type' attribute of are as follows: 313 'descriptor-error' - indicates there was an error decoding the 314 descriptor. Servers SHOULD send a descriptor error in the 315 following cases: 317 1. When a request is received with a payload type indicating size 318 information (i.e. the PT flag is 'si'). 320 2. When a request is received with a payload type indicating 321 other information (i.e. the PT flag is 'oi'). 323 3. When a request is sent with a transaction ID of 0xFFFF (which 324 is reserved for server use). 326 4. When a request is received with an incomplete or truncated 327 payload descriptor. 329 5. When reserved bits in the payload descriptor are set to 330 values other than zero. 332 'payload-error' - indicates there was an error interpretting the 333 payload. Servers MUST send a payload error if they receive XML 334 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 336 'system-error' - indicates that the receiver cannot process the 337 request due to a condition not related to this protocol. Servers 338 SHOULD send a system-error when they are capable of responding to 339 requests but not capable of processing requests. 341 'authority-error' - indicates that the intended authority 342 specified in the corresponding request is not served by the 343 receiver. Servers SHOULD send an authority error when they 344 receive a request directed to an authority other than those they 345 serve. 347 'no-inflation-support-error' - indicates that the receiver does 348 not support payloads that have been compressed with DEFLATE [1]. 349 Servers MUST send this error when they receive a request that has 350 been compressed with DEFLATE but they do not support inflation. 352 4. Interactions 354 The intent of IRIS-LWZ is to utilize UDP for IRIS requests and 355 responses when UDP is appropriate. Not all IRIS requests and 356 responses will be able to utilize UDP and may require the use of 357 other transfer protocols (i.e. IRIS-XPC and/or BEEP). The following 358 strategy SHOULD be used: 360 1. If a request requires authentication, confidentiality, or other 361 security, use another transfer protocol. 363 2. If a request is less than or equal to 4000 octets, send it 364 uncompressed. 366 3. If a request can be compressed to a size less than or equal to 367 4000 octets, send the request using compression. Otherwise use 368 another transfer protocol. 370 4. If a request yields a size error, send the request with another 371 transfer protocol. 373 5. Internationalization Considerations 375 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 376 encodings. Use of the XML defined by [7] MUST NOT use any other 377 character encodings other than UTF-8 or UTF-16. 379 6. IRIS Transport Mapping Definitions 381 This section lists the definitions required by IRIS [3] for transport 382 mappings. 384 6.1 URI Scheme 386 See Section 7.1.1. 388 6.2 Application Protocol Label 390 See Section 7.1.3. 392 7. IANA Considerations 394 7.1 Registrations 396 7.1.1 URI Scheme Registration 398 URL scheme name: iris.lwz 400 URL scheme syntax: defined in Section 6.1 and [3]. 402 Character encoding considerations: as defined in RFC2396 [5]. 404 Intended usage: identifies an IRIS entity made available using XML 405 over UDP 407 Applications using this scheme: defined in IRIS [3]. 409 Interoperability considerations: n/a 411 Security Considerations: defined in Section 8. 413 Relevant Publications: IRIS [3]. 415 Contact Information: Andrew Newton 417 Author/Change controller: the IESG 419 7.1.2 Well-known UDP Port Registration 421 Protocol Number: UDP 423 UDP Port Number: TBD by IANA 425 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 426 and Section 3.1. 428 Functions: defined in IRIS [3]. 430 Use of Broadcast/Multicast: none 432 Proposed Name: IRIS-LWZ 434 Short name: iris.lwz 436 Contact Information: Andrew Newton 438 7.1.3 S-NAPTR Registration 440 Application Protocol Label (see [4]): iris.lwz 442 Intended usage: identifies an IRIS server using XML over UDP 444 Interoperability considerations: n/a 446 Security Considerations: defined in Section 8. 448 Relevant Publications: IRIS [3]. 450 Contact Information: Andrew Newton 452 Author/Change controller: the IESG 454 8. Security Considerations 456 IRIS-LWZ is intended for serving public data; it provides no in-band 457 mechanisms for authentication or encryption. Any application with 458 this need must provide out of band mechanisms to provide it (e.g., 459 IPSec), or use the IRIS transfer protocols that provides such 460 capabilities. 462 9. Normative References 464 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 465 version 1.3", RFC 1951, May 1996. 467 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 468 ISBN 0-201-61633-5, 2000, . 470 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 471 RFC 3891, January 2004. 473 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 474 Location Using SRV RRs and the Dynamic Delegation Discovery 475 Service (DDDS)", RFC 3958, January 2005. 477 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 478 Resource Identifiers (URI): Generic Syntax", RFC 2396, 479 August 1998. 481 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 482 Levels", RFC 2119, BCP 14, March 1997. 484 [7] Newton, A., "A Common Schema for Internet Registry Information 485 Service Transfer Protocols", 486 draft-ietf-crips-iris-common-transport-00 (work in progress), 487 April 2005. 489 [8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 490 RFC 1166, July 1990. 492 Author's Address 494 Andrew L. Newton 495 VeriSign, Inc. 496 21345 Ridgetop Circle 497 Sterling, VA 20166 498 USA 500 Phone: +1 703 948 3382 501 Email: andy@hxr.us 502 URI: http://www.verisignlabs.com/ 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 Intellectual Property Statement 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Disclaimer of Validity 695 This document and the information contained herein are provided on an 696 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 697 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 698 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 699 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 700 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 701 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 703 Copyright Statement 705 Copyright (C) The Internet Society (2006). This document is subject 706 to the rights, licenses and restrictions contained in BCP 78, and 707 except as set forth therein, the authors retain all their rights. 709 Acknowledgment 711 Funding for the RFC Editor function is currently provided by the 712 Internet Society.