idnits 2.17.1 draft-ietf-crisp-iris-xpc-00.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 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1088. ** 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3981, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3981, updated by this document, for RFC5378 checks: 2002-08-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 2005) is 6937 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2222 (ref. '4') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3268 (ref. '8') (Obsoleted by RFC 5246) -- No information found for draft-ietf-crips-iris-common-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 11 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 Updates: 3981 (if approved) April 29, 2005 5 Expires: October 31, 2005 7 XML Pipelining with Chunks for the Information Registry Information 8 Service 9 draft-ietf-crisp-iris-xpc-00 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 October 31, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a simple TCP transport binding for the 43 Internet Registry Information Service (IRIS). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 49 3. Request Block . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Response Block . . . . . . . . . . . . . . . . . . . . . . . 6 51 5. Connection Response Block . . . . . . . . . . . . . . . . . 7 52 6. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 8 53 7. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 7.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 10 55 7.2 Version Information Types . . . . . . . . . . . . . . . . 10 56 7.3 Other Information Types . . . . . . . . . . . . . . . . . 11 57 7.4 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 12 58 7.5 Authentication Succss Information Types . . . . . . . . . 13 59 7.6 Authentication Failure Information Types . . . . . . . . . 13 60 7.7 Application Data Types . . . . . . . . . . . . . . . . . . 13 61 8. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . 14 62 9. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 63 10. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . 16 64 11. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 17 65 11.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 17 66 11.2 Application Protocol Label . . . . . . . . . . . . . . . 17 67 12. Internationalization Considerations . . . . . . . . . . . . 18 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 69 13.1 XPC URI Scheme Registration . . . . . . . . . . . . . . 19 70 13.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . 19 71 13.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . 20 72 13.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . 20 73 13.5 Well-known TCP Port Registration . . . . . . . . . . . . 20 74 14. Security Considerations . . . . . . . . . . . . . . . . . . 21 75 15. Normative References . . . . . . . . . . . . . . . . . . . . 21 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 77 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 Intellectual Property and Copyright Statements . . . . . . . 32 80 1. Introduction 82 Using S-NAPTR [6], IRIS has the ability to define the use of multiple 83 application transports (or transfer protocols) for different types of 84 registry services, all at the descretion of the server operator. The 85 TCP transfer protocol defined in this document is completely modular 86 and may be used by any registry types. 88 This transfer protocol defines simple framing for sending XML in 89 chunks so that XML fragments may be acted upon (or pipelined) before 90 the reception of the entire XML instance. This document calls this 91 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 93 XPC is for use with simple request and response interactions between 94 clients and servers. Clients send a series of requests to a server 95 in data blocks. The server will respond to each data block 96 individually with a corresponding data block, but through the same 97 connection. Request and response data blocks are sent using the TCP 98 SEND function and received using the TCP RECEIVE function. 100 The lifecycle of an XPC session has the following phases: 102 1. A client establishes a TCP connection with a server. 104 2. The server sends a connection response block (CRB). 106 3. The client sends a request block (RQB). In this request, the 107 client can set a "keep open" flag requesting that the server keep 108 the XPC session open following the response to this request. 110 4. The server responds with a response block (RSB). In this 111 response, the server can indicate to the client whether or not 112 the XPC session will be closed using a "connection closing" flag. 114 5. If the XPC session is not to be terminated, then the lifecycle 115 repeats from step 3. 117 6. The TCP connection is closed. 119 2. Document Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC2119 [9]. 125 3. Request Block 127 The format for the request block (RQB) is as follows: 129 +--------+-----------+-----------+-------------+ 130 field | header | authority | authority | chunks 1..n | 131 | | length | | | 132 +--------+-----------+-----------+-------------+ 133 octets 1 1 0..255 variable 135 These fields have the following meanings: 137 o header - as described in Section 6. 139 o authority length - the length of the authority field in this 140 request block. 142 o authority - a string of octets describing the authority against 143 wich this request is to be executed. See [1] for the definition 144 and description of an authority. The number of octets in this 145 string MUST be no more and no less than the number specified by 146 the authority length. 148 o chunks 1..n - the request data broken into chunks (Section 7). 150 4. Response Block 152 The format for the response block (RSB) is as follows: 154 +--------+-------------+ 155 field | header | chunks 1..n | 156 | | | 157 +--------+-------------+ 158 octets 1 variable 160 These fields have the following meanings: 162 o header - as described in Section 6. 164 o chunks 1..n - the response data broken into chunks (Section 7). 166 5. Connection Response Block 168 A connection response block (CRB) is a response block sent by a 169 server to a client in response to the client initiating a session. A 170 connection response block has the same format as a response block 171 (RSB) (Section 4). The only difference is that it is constrained in 172 one of two ways: 174 1. It contains only one chunk (see Section 7) containing version 175 information (see Section 7.2) and the connection closing bit in 176 the block header (see Section 6) has a value of 1 (meaning the 177 connection is not closing). Servers MUST use this type of CRB to 178 indicate service availability. 180 2. It contains only one chunk (see Section 7) containing a system 181 error (see 'system-error' under Section 7.3) and the connection 182 closing bit in the block header (see Section 6) has a value of 0 183 (meaning the server will close the connection immediately after 184 sending the CRB). Servers MUST use this type of CRB when they 185 can accept connections but cannot process requests. 187 6. Block Header 189 Each data block starts with a one octet header called the block 190 header. This header has the same format for both request and 191 response data blocks, though some of the bits in the header only have 192 meaning in one type of data block. Each bit in the block header has 193 the following meaning: 195 o bits 7 and 6 - version (V flag) - If 0 (both bits are zero), the 196 protocol is the version defined in this document. Otherwise, the 197 rest of the bits in the header and the block may be interpreted as 198 another version. 200 o bits 5 - keep open (KO flag)- If 1, the client is requesting the 201 server not to close the TCP session. If 0, the client should 202 expect the server to close the TCP session immediately after 203 sending the corresponding response. This bit only has context in 204 request blocks. 206 o bit 4 - connection closing (CC flag)- If 0, the server will close 207 the TCP session immediately following this block. This bit only 208 has meaning in a response block. It MUST be 0 in a request block. 210 o bit 3, 2, 1, and 0 - reserved - These MUST be 0. 212 7. Chunks 214 Request and response blocks break the request and response XML data 215 down into chunks. Request and response blocks MUST always have a 216 minimum of 1 chunk. Each chunk has a one octet descriptor, and the 217 first bit of the desciptor determines if a chunk is the last chunk. 219 The bits of the chunk descriptor octet have the following meaning: 221 o bit 7 - last chunk (LC flag) - If 0, this chuck is the last chunk 222 in the block. 224 o bit 6 - data completion (DC flag) - If 0, the data in this chunk 225 represents the end of the data for the chunk type given. If this 226 bit is never set to 0 in any chunk descriptor for chunks of the 227 same type in a block, clients and servers MUST NOT assume the data 228 will continue in another block. If the block transitions from one 229 type of chunk to another with out signaling completion of the 230 data, clients and servers MUST assume that the remaining data will 231 not be sent in a remaining chunk. 233 o bits 5, 4, and 3 - reserved - These MUST be 0. 235 o bit 2, 1, and 0 - chunk type (CT flag) - determines the type of 236 data carried in the chunk. These are the binary values for the 237 chunk types: 239 * 000 - no data or 'nd' type (see Section 7.1) 241 * 001 - version information or 'vi' type (see Section 7.2) 243 * 010 - reserved 245 * 011 - other information or 'oi type (see Section 7.3) 247 * 100 - SASL data or 'sd' type (see Section 7.4) 249 * 101 - authentication success information or 'as' type (see 250 Section 7.5) 252 * 110 - authentication failure information or 'af' type (see 253 Section 7.6) 255 * 111 - application data or 'ad' type (see Section 7.7) 257 A block MAY have multiple types of chunks, but all chunks of the same 258 type MUST be contingous in a block and MUST be ordered in the block 259 in the order in which their data is to be intepretted. Contiguous 260 chunks must by ordered by type within a block in the following way: 262 1. authentication related chunks - either SASL data chunks (type 263 100), authentication success information chunks (type 101) or 264 authentication failure information chunks (type 110), but not 265 more than one type 267 2. data chunks - either no data chunks (type 000) or application 268 data chunks (type 111), but not both. 270 3. information chunks - either version information (type 001) or 271 other information (type 011), but not both. 273 A block MUST have at least one type of the above chunks. 275 The format for a chunk is as follows: 277 +-----------+------------+--------+ 278 field | chunk | chunk data | chunk | 279 | descriptor| length | data | 280 +-----------+------------+--------+ 281 octets 1 2 variable 283 These fields have the following meanings: 285 o chunk descriptor - as described above. 287 o chunk data length - the length of the data of the chunk 289 o chunk data - the data of the chunk 291 7.1 No Data Types 293 Servers and clients MUST ignore data in chunk types labeled no data. 294 There is no requirement for these types of chunks to be zero length. 295 A client MAY send "no data" to a server, and the server MUST respond 296 with either a chunk of the same type or other information 297 (Section 7.3). 299 7.2 Version Information Types 301 Chunks of this type contain XML conformant to the schema specified in 302 [10] and MUST have the element as the root element. 304 In the context of IRIS-XPC, the protocol identifiers for these 305 elements are as follows: 307 o - the value "iris.xpc1" to indicate the 308 protocol specified in this document. 310 o - the XML namespace identifier for IRIS [1]. 312 o - the XML namespace identifier for IRIS registries. 314 In the context of IRIS-XPC, the authentication mechanism identifiers 315 are the SASL mechanism names found in the IANA SASL mechanism 316 registry defined by RFC 2222 [4]. 318 This document defines no extension identifiers. 320 Clients MAY send a block with this type of chunk to a server. These 321 chunks SHOULD be zero length and servers MUST ignore any data in 322 them. When a server receives a chunk of this type, it MUST respond 323 with a chunk of this type. 325 7.3 Other Information Types 327 Chunks of this type contain XML conformant to the schema specified in 328 IRIS-COMMON [10] and MUST have the element as the root 329 element. 331 The values for the 'type' attribute of are as follows: 333 'block-error' - indicates there was an error decoding a block. 334 Servers SHOULD send a block error in the following cases: 336 1. When a request block is received containing a chunk of this 337 type. 339 2. When a request block is received containing authentication 340 success (see Section 7.5) or authentication failure (see 341 Section 7.6) information. 343 3. When the connection-closing bit in the block header of a 344 request block is 1. 346 4. When reserved bits in the request block are 1. 348 5. When a block has not been received in its entirety and the TCP 349 session has been idle for a specific period of time. Two 350 minutes is RECOMMENDED for this timeout value. 352 'data-error' - indicates there was an error parsing data in chunks 353 containing application or SASL data (e.g. XML is not valid in 354 application data). 356 'system-error' - indicates that the receiver cannot process the 357 request due to a condition not related to this protocol. Servers 358 SHOULD send a system-error when they are capable of responding to 359 requests but not capable of processing requests. 361 'authority-error' - indicates that the intended authority 362 specified in the corresponding request is not served by the 363 receiver. Servers SHOULD send an authority error when they 364 receive a request directed to an authority other than those they 365 serve. 367 'idle-timeout' - indicates that an XPC session has been idle for 368 too long. Usage of this value is defined in Section 8. 370 7.4 SASL Types 372 The SASL chunk type allows clients and servers to exchange SASL data. 374 The format for the data of this type of chunk is as follows: 376 +-----------+-----------+-----------+-----------+ 377 field | mechanism | mechanism | mechanism | mechanism | 378 | name | name | data | data | 379 | length | | length | | 380 +-----------+-----------+-----------+-----------+ 381 octets 1 variable 2 variable 383 These fields have the following meaning: 385 o mechanism name length - the length of the SASL mechanism name 387 o mechanism - the name of the SASL mechanism as registered in the 388 IANA SASL mechanism registry defined by [4]. 390 o mechanism data length - the length of the SASL data 392 o mechanism data - the data used for SASL 394 These fields MUST NOT span multiple chunks. Therefore it should be 395 noted that SASL data length exceeding the length of the chunk minus 396 the length of SASL profile name minus one is an error. 398 Depending on the nature of the SASL mechansim being used, SASL data 399 is sent from clients to servers and from servers to clients and may 400 require multiple request/response transactions to complete. However, 401 once a SASL exchange is complete and a server can determine 402 authentication status, the server MUST send either authentication 403 success information (see Section 7.5) or authentication failure 404 information (see Section 7.6). 406 7.5 Authentication Succss Information Types 408 Chunks of this type contain XML conformant to the schema specified in 409 IRIS-COMMON [10] and MUST have the element as 410 the root element. 412 This type of chunk is only sent from a server to a client. If a 413 client sends it to a server, this will result in a block error (see 414 'block-error' in Section 7.3). The usage of this chunk type is 415 defined in Section 7.4. 417 7.6 Authentication Failure Information Types 419 Chunks of this type contain XML conformant to the schema specified in 420 IRIS-COMMON [10] and MUST have the element as 421 the root element. 423 This type of chunk is only sent from a server to a client. If a 424 client sends it to a server, this will result in a block error (see 425 'block-error' in Section 7.3). The usage of this chunk type is 426 defined in Section 7.4. 428 7.7 Application Data Types 430 These chunks contain application data. For IRIS, these are IRIS [1] 431 XML instances. 433 8. Idle Sessions 435 An XPC session may become idle between request/response transactions. 436 This can occur when a server honors a client's request to keep the 437 TCP connection running (see the keep-open and connection-closing bits 438 in the block header (Section 6)). Servers are not expected to allow 439 XPC sessions be idle between requests indefinitely. 441 Clients MUST send no less than 1 request every 2 minutes. This can 442 be any type of request specified by this document. If a client has 443 no need to send a specific type of request but must send a request to 444 fulfill this obligation, sending a request block containing one chunk 445 of "no data" (see Section 7.1) with a length of zero is RECOMMENDED. 447 If a server has not received a request block 5 minutes after sending 448 a response block (either RSB or CRB), it SHOULD do the following: 450 1. Send an unsolicited response block containing an idle timeout 451 error (see 'idle-timeout' in Section 7.3) with the connection- 452 closing bit in the block header (Section 6) set to a value of 0. 454 2. Close the TCP connection. 456 9. Use over TLS 458 XPC may be tunneled over TLS [5] by establishing a TLS session 459 immediately after a TCP session is opened and before any blocks are 460 to be sent. This type of session is known as XPCS. 462 When using TLS, a convention must be established to allow a client to 463 authenticate the validity of a server. XPCS uses the same convention 464 as described by IRIS-BEEP [2]. 466 10. Update to RFC 3981 468 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 469 the default transport for IRIS. This document revises RFC 3981 and 470 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 471 known port registration is specified in Section 13.5. 473 11. IRIS Transport Mapping Definitions 475 This section lists the definitions required by IRIS [1] for transport 476 mappings. 478 11.1 URI Scheme 480 See Section 13.1 and Section 13.2. 482 11.2 Application Protocol Label 484 See Section 13.3 and Section 13.4. 486 12. Internationalization Considerations 488 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 489 encodings. Use of the XML defined by [10] MUST NOT use any other 490 character encodings other than UTF-8 or UTF-16. 492 13. IANA Considerations 494 13.1 XPC URI Scheme Registration 496 URL scheme name: iris.xpc 498 URL scheme syntax: defined in [1]. 500 Character encoding considerations: as defined in RFC2396 [7]. 502 Intended usage: identifies IRIS XML using chunks over TCP 504 Applications using this scheme: defined in IRIS [1]. 506 Interoperability considerations: n/a 508 Security Considerations: defined in Section 14. 510 Relevant Publications: IRIS [1]. 512 Contact Information: Andrew Newton 514 Author/Change controller: the IESG 516 13.2 XPCS URI Scheme Registration 518 URL scheme name: iris.xpcs 520 URL scheme syntax: defined in [1]. 522 Character encoding considerations: as defined in RFC2396 [7]. 524 Intended usage: identifies IRIS XML using chunks over TLS 526 Applications using this scheme: defined in IRIS [1]. 528 Interoperability considerations: n/a 530 Security Considerations: defined in Section 14. 532 Relevant Publications: IRIS [1]. 534 Contact Information: Andrew Newton 536 Author/Change controller: the IESG 538 13.3 S-NAPTR XPC Registration 540 Application Protocol Label (see [6]): iris.xpc 542 Intended usage: identifies an IRIS server using XPC 544 Interoperability considerations: n/a 546 Security Considerations: defined in Section 14. 548 Relevant Publications: IRIS [1]. 550 Contact Information: Andrew Newton 552 Author/Change controller: the IESG 554 13.4 S-NAPTR XPCS Registration 556 Application Protocol Label (see [6]): iris.xpcs 558 Intended usage: identifies an IRIS server using secure XPCS 560 Interoperability considerations: n/a 562 Security Considerations: defined in Section 14. 564 Relevant Publications: IRIS [1]. 566 Contact Information: Andrew Newton 568 Author/Change controller: the IESG 570 13.5 Well-known TCP Port Registration 572 Protocol Number: TCP 574 Message Formats, Types, Opcodes, and Sequences: defined in Section 5, 575 Section 3, and Section 4. 577 Functions: defined in IRIS [1]. 579 Use of Broadcast/Multicast: none 581 Proposed Name: IRIS over XPC 583 Short name: iris.xpc 585 Contact Information: Andrew Newton 587 14. Security Considerations 589 Implementers should be fully aware of the security considerations 590 given by IRIS [1] and TLS [5]. With respect to server authentication 591 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 593 Clients SHOULD be prepared to use the following security mechanisms 594 in the following manner: 596 o SASL/DIGEST-MD5 - for user authentication without the need of 597 session encryption. 599 o SASL/OTP - for user authentication without the need of session 600 encryption. 602 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 603 encryption. 605 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 606 side certificates - for encryption and user authentication. 608 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 609 encryption. See [8]. 611 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 612 certificates - for encryption and user authentication. See [8]. 614 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 615 encryption. See [8]. 617 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 618 certificates - for encryption and user authentication. See [8]. 620 Anonymous client access SHOULD be considered in one of two methods: 622 1. When no authentication has been used. 624 2. Using the SASL anonymous profile: SASL/ANONYMOUS 626 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 627 mechanism without first encrypting the TCP session (e.g. such as with 628 TLS). 630 15. Normative References 632 [1] Newton, A. and M. Sanz, "Internet Registry Information 633 Service", RFC 3891, January 2004. 635 [2] Newton, A. and M. Sanz, "Using the Internet Registry 636 Information Service over the Blocks Extensible Exchange 637 Protocol", RFC 3893, January 2004. 639 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 640 ISBN 0-201-61633-5, 2000, . 642 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 643 RFC 2222, October 1997. 645 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 646 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 647 January 1999. 649 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 650 Location Using SRV RRs and the Dynamic Delegation Discovery 651 Service (DDDS)", RFC 3958, January 2005. 653 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 654 Resource Identifiers (URI): Generic Syntax", RFC 2396, 655 August 1998. 657 [8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 658 Transport Layer Security (TLS)", RFC 3268, June 2002. 660 [9] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", RFC 2119, BCP 14, March 1997. 663 [10] Newton, A., "A Common Schema for Internet Registry Information 664 Service Transfer Protocols", 665 draft-ietf-crips-iris-common-transport-00 (work in progress), 666 April 2005. 668 Author's Address 670 Andrew L. Newton 671 VeriSign, Inc. 672 21345 Ridgetop Circle 673 Sterling, VA 20166 674 USA 676 Phone: +1 703 948 3382 677 Email: anewton@verisignlabs.com; andy@hxr.us 678 URI: http://www.verisignlabs.com/ 680 Appendix A. Examples 682 This section gives examples of IRIS-XPC sessions. Lines beginning 683 with "C:" denote data sent by the client to the server, and lines 684 beginning with "S:" denote data sent by the server to the client. 685 Following the "C:" or "S:", the line either contains octet values in 686 hexadecimal notation with comments or XML fragments. No line 687 contains both octet values with comments and XML fragments. Comments 688 are contained within parenthesis. 690 It should also be noted that flag values of "yes" and "no" do not 691 reflect binary values 1 and 0. Instead they represent the associated 692 positive or negative assertion of the meaning of the flag. For 693 instance, for the connection-closing or CC flag to have a value of 0 694 means that the connection is closing, thus CC=yes. 696 The following example demonstrates an IRIS client issuing two 697 requests in one XPC session. In the first request, the client is 698 requesting status information for "example.com". This request and 699 its response are transfered with one chunk. In the second request, 700 the client is requesting status information for "milo.example.com", 701 "felix.example.com", and "hobbes.exmaple.com". This request and its 702 response are transfered with three chunks. 704 S: (connection response block) 705 S: 0x10 (block header: V=0,KO=no,CC=no) 706 S: (chunk 1) 707 S: 0x01 (LC=yes,DC=yes,CT=vi) 708 S: 0x01 0xBE (chunk length=446) 709 S: (Version Information) 710 S: 711 S: 712 S: 714 S: 716 S: 717 S: 718 S: 719 S: 720 S: 722 C: (request block) 723 C: 0x20 (block header: V=0,KO=yes,CC=yes) 724 C: 0x0B (authority length=11) 725 C: (authority="example.com") 726 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 727 C: (chunk 1) 728 C: 0x07 (LC=yes,DC=yes,CT=ad) 729 C: 0x01 0x53 (chunk length=339) 730 C: (IRIS XML request) 731 C: 733 C: 734 C: 738 C: 739 C: 741 S: (response block) 742 S: 0x10 (block header: V=0,KO=no,CC=no) 743 S: (chunk 1) 744 S: 0x07 (LC=yes,DC=yes,CT=ad) 745 S: 0x01 0xE0 (chunk length=480) 746 S: (IRIS XML response) 747 S: 748 S: 749 S: 750 S: 754 S: example.com 755 S: 756 S: 757 S: 758 S: 759 S: 760 S: 761 S: 763 C: (request block) 764 C: 0x00 (block header: V=0,KO=no,CC=yes) 765 C: 0x0B (authority length=11) 766 C: (authority="example.com") 767 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 768 C: (chunk 1) 769 C: 0xC7 (LC=no,DC=no,CT=ad) 770 C: 0x01 0x4E (chunk length=339) 771 C: (IRIS XML request) 772 C: 775 C: 776 C: 780 C: 781 C: (chunk 2) 782 C: 0xC7 (LC=no,DC=no,CT=ad) 783 C: 0x00 0xA9 (chunk length=169) 784 C: (IRIS XML request) 785 C: 786 C: 790 C: 791 C: (chunk 3) 792 C: 0x07 (LC=yes,DC=yes,CT=ad) 793 C: 0x00 0xB5 (chunk length=181) 794 C: (IRIS XML request) 795 C: 796 C: 800 C: 801 C: 803 S: (response block) 804 S: 0x00 (block header: V=0,KO=no,CC=yes) 805 S: (chunk 1) 806 S: 0xC7 (LC=no,DC=no,CT=ad) 807 S: 0x01 0xDA (chunk length=474) 808 S: (IRIS XML response) 809 S: 810 S: 811 S: 812 S: 816 S: milo.example.com 817 S: 818 S: 819 S: 820 S: 821 S: 822 S: 823 S: (chunk 2) 824 S: 0xC7 (LC=no,DC=no,CT=ad) 825 S: 0x01 0xA2 (chunk length=418) 826 S: (IRIS XML response) 827 S: 828 S: 829 S: 833 S: felix.example.com 834 S: 835 S: 836 S: 837 S: 838 S: 839 S: 840 S: (chunk 3) 841 S: 0x07 (LC=yes,DC=yes,CT=ad) 842 S: 0x01 0xB5 (chunk length=437) 843 S: (IRIS XML response) 844 S: 845 S: 846 S: 851 S: hobbes.example.com 852 S: 853 S: 854 S: 855 S: 856 S: 857 S: 858 S: 860 Figure 5: Example 1 862 In the following example, an IRIS client requests domain status 863 information for "milo.example.com", "felix.example.com", and 864 "hobbes.example.com" in one request. The request is sent with one 865 chunk, however the answer is returned in three chunks. 867 S: (connection response block) 868 S: 0x10 (block header: V=0,KO=no,CC=no) 869 S: (chunk 1) 870 S: 0x01 (LC=yes,DC=yes,CT=vi) 871 S: 0x01 0xBE (chunk length=446) 872 S: (Version Information) 873 S: 874 S: 875 S: 877 S: 879 S: 880 S: 881 S: 882 S: 883 S: 885 C: (request block) 886 C: 0x00 (block header: V=0,KO=no,CC=yes) 887 C: 0x0B (authority length=11) 888 C: (authority="example.com") 889 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 890 C: (chunk 1) 891 C: 0x07 (LC=yes,DC=yes,CT=ad) 892 C: 0x02 0xAB (chunk length=683) 893 C: (IRIS XML request) 894 C: 897 C: 898 C: 902 C: 903 C: 904 C: 908 C: 909 C: 910 C: 914 C: 915 C: 917 S: (response block) 918 S: 0x00 (block header: V=0,KO=no,CC=yes) 919 S: (chunk 1) 920 S: 0xC7 (LC=no,DC=no,CT=ad) 921 S: 0x01 0xDA (chunk length=474) 922 S: (IRIS XML response) 923 S: 924 S: 925 S: 926 S: 930 S: milo.example.com 931 S: 932 S: 933 S: 934 S: 935 S: 936 S: 937 S: (chunk 2) 938 S: 0xC7 (LC=no,DC=no,CT=ad) 939 S: 0x01 0xA2 (chunk length=418) 940 S: (IRIS XML response) 941 S: 942 S: 943 S: 947 S: felix.example.com 948 S: 949 S: 950 S: 951 S: 952 S: 953 S: 954 S: (chunk 3) 955 S: 0x07 (LC=yes,DC=yes,CT=ad) 956 S: 0x01 0xB5 (chunk length=437) 957 S: (IRIS XML response) 958 S: 959 S: 960 S: 965 S: hobbes.example.com 966 S: 967 S: 968 S: 969 S: 970 S: 971 S: 972 S: 974 Figure 6: Example 2 976 In the following example, an IRIS client sends a request containg 977 SASL/PLAIN authentication data and a domain status check for 978 "example.com". The server responds with authentication succss 979 information and the domain status of "example.com". Note that the 980 client requests that the connection stay open for further requests, 981 but that the server does not honor this request. 983 S: (connection response block) 984 S: 0x10 (block header: V=0,KO=no,CC=no) 985 S: (chunk 1) 986 S: 0x01 (LC=yes,DC=yes,CT=vi) 987 S: 0x01 0xBE (chunk length=446) 988 S: (Version Information) 989 S: 990 S: 991 S: 993 S: 995 S: 996 S: 997 S: 998 S: 999 S: 1001 C: (request block) 1002 C: 0x20 (block header: V=0,KO=yes,CC=yes) 1003 C: 0x0B (authority length=11) 1004 C: (authority="example.com") 1005 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1006 C: (chunk 1) 1007 C: 0x84 (LC=no,DC=yes,CT=sd) 1008 C: 0x00 0x11 (chunk length=11) 1009 C: (SASL data) 1010 C: 0x05 (mechanism length=5) 1011 C: (mechanism name="PLAIN") 1012 C: 0x50 0x4C 0x41 0x49 0x43 1013 C: 0x0A (sasl PLAIN data length=10) 1014 C: (sasl PLAIN data: authcid="bob") 1015 C: (sasl PLAIN data: authzid=NULL) 1016 C: (sasl PLAIN data: password="kEw1") 1017 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1018 C: (chunk 2) 1019 C: 0x07 (LC=yes,DC=yes,CT=ad) 1020 C: 0x01 0x53 (chunk length=339) 1021 C: (IRIS XML request) 1022 C: 1024 C: 1025 C: 1029 C: 1030 C: 1032 S: (response block) 1033 S: 0x00 (block header: V=0,KO=no,CC=yes) 1034 S: (chunk 1) 1035 S: 0x85 (LC=no,DC=yes,CT=as) 1036 S: 0x00 0xD0 (chunk length=208) 1037 S: (authentication success response) 1038 S: 1039 S: 1041 S: 1042 S: user 'bob' authenticates via password 1043 S: 1044 S: 1045 S: (chunk 2) 1046 S: 0x07 (LC=yes,DC=yes,CT=ad) 1047 S: 0x01 0xE0 (chunk length=480) 1048 S: (IRIS XML response) 1049 S: 1050 S: 1051 S: 1052 S: 1056 S: example.com 1057 S: 1058 S: 1059 S: 1060 S: 1061 S: 1062 S: 1063 S: 1064 Figure 7: Example 3 1066 Intellectual Property Statement 1068 The IETF takes no position regarding the validity or scope of any 1069 Intellectual Property Rights or other rights that might be claimed to 1070 pertain to the implementation or use of the technology described in 1071 this document or the extent to which any license under such rights 1072 might or might not be available; nor does it represent that it has 1073 made any independent effort to identify any such rights. Information 1074 on the procedures with respect to rights in RFC documents can be 1075 found in BCP 78 and BCP 79. 1077 Copies of IPR disclosures made to the IETF Secretariat and any 1078 assurances of licenses to be made available, or the result of an 1079 attempt made to obtain a general license or permission for the use of 1080 such proprietary rights by implementers or users of this 1081 specification can be obtained from the IETF on-line IPR repository at 1082 http://www.ietf.org/ipr. 1084 The IETF invites any interested party to bring to its attention any 1085 copyrights, patents or patent applications, or other proprietary 1086 rights that may cover technology that may be required to implement 1087 this standard. Please address the information to the IETF at 1088 ietf-ipr@ietf.org. 1090 Disclaimer of Validity 1092 This document and the information contained herein are provided on an 1093 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1094 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1095 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1096 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1097 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1100 Copyright Statement 1102 Copyright (C) The Internet Society (2005). This document is subject 1103 to the rights, licenses and restrictions contained in BCP 78, and 1104 except as set forth therein, the authors retain all their rights. 1106 Acknowledgment 1108 Funding for the RFC Editor function is currently provided by the 1109 Internet Society.