idnits 2.17.1 draft-ietf-crisp-iris-xpc-02.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 1173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1163. ** 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 (July 12, 2005) is 6863 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' ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '11') Summary: 8 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) July 12, 2005 5 Expires: January 13, 2006 7 XML Pipelining with Chunks for the Information Registry Information 8 Service 9 draft-ietf-crisp-iris-xpc-02 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 January 13, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a simple TCP transfer protocol for the 43 Internet Registry Information Service (IRIS). Data is transfered 44 between clients and servers using chunks to achieve pipelining. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 50 3. Request Block (RQB) . . . . . . . . . . . . . . . . . . . . 5 51 4. Response Blocks . . . . . . . . . . . . . . . . . . . . . . 6 52 4.1 Response Block (RSB) . . . . . . . . . . . . . . . . . . . 6 53 4.2 Connection Response Block (CRB) . . . . . . . . . . . . . 6 54 5. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 10 57 6.2 Version Information Types . . . . . . . . . . . . . . . . 10 58 6.3 Size Information Types . . . . . . . . . . . . . . . . . . 11 59 6.4 Other Information Types . . . . . . . . . . . . . . . . . 11 60 6.5 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 13 61 6.6 Authentication Succss Information Types . . . . . . . . . 13 62 6.7 Authentication Failure Information Types . . . . . . . . . 14 63 6.8 Application Data Types . . . . . . . . . . . . . . . . . . 14 64 7. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . 15 65 8. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 16 66 9. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . 17 67 10. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 18 68 10.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 18 69 10.2 Application Protocol Label . . . . . . . . . . . . . . . 18 70 11. Internationalization Considerations . . . . . . . . . . . . 19 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 72 12.1 XPC URI Scheme Registration . . . . . . . . . . . . . . 20 73 12.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . 20 74 12.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . 21 75 12.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . 21 76 12.5 Well-known TCP Port Registration . . . . . . . . . . . . 21 77 13. Security Considerations . . . . . . . . . . . . . . . . . . 22 78 14. Normative References . . . . . . . . . . . . . . . . . . . . 22 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 80 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 82 Intellectual Property and Copyright Statements . . . . . . . 34 84 1. Introduction 86 Using S-NAPTR [6], IRIS has the ability to define the use of multiple 87 application transports (or transfer protocols) for different types of 88 registry services, all at the descretion of the server operator. The 89 TCP transfer protocol defined in this document is completely modular 90 and may be used by any registry types. 92 This transfer protocol defines simple framing for sending XML in 93 chunks so that XML fragments may be acted upon (or pipelined) before 94 the reception of the entire XML instance. This document calls this 95 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 97 XPC is for use with simple request and response interactions between 98 clients and servers. Clients send a series of requests to a server 99 in data blocks. The server will respond to each data block 100 individually with a corresponding data block, but through the same 101 connection. Request and response data blocks are sent using the TCP 102 SEND function and received using the TCP RECEIVE function. 104 The lifecycle of an XPC session has the following phases: 106 1. A client establishes a TCP connection with a server. 108 2. The server sends a connection response block (CRB). 110 3. The client sends a request block (RQB). In this request, the 111 client can set a "keep open" flag requesting that the server keep 112 the XPC session open following the response to this request. 114 4. The server responds with a response block (RSB). In this 115 response, the server can indicate to the client whether or not 116 the XPC session will be closed. 118 5. If the XPC session is not to be terminated, then the lifecycle 119 repeats from step 3. 121 6. The TCP connection is closed. 123 2. Document Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC2119 [9]. 129 Octet fields with numberic values are given according to the 130 conventions in RFC 1166 [11]: the left most bit of the whole field is 131 the most significant bit; when a multi-octet quantity is transmitted 132 the most significant octet is transmitted first. Bits signifying 133 flags in an octet are numbered according to the conventions of RFC 134 1166 [11]: bit 0 is the most significant bit and bit 7 is the least 135 significant bit. When a diagram describes a group of octets, the 136 order of tranmission for the octets starts from the left. 138 3. Request Block (RQB) 140 The format for the request block (RQB) is as follows: 142 +--------+-----------+-----------+-------------+ 143 field | header | authority | authority | chunks 1..n | 144 | | length | | | 145 +--------+-----------+-----------+-------------+ 146 octets 1 1 0..255 variable 148 These fields have the following meanings: 150 o header - as described in Section 5. 152 o authority length - the length of the authority field in this 153 request block 155 o authority - a string of octets describing the authority against 156 which this request is to be executed. See [1] for the definition 157 and description of an authority. The number of octets in this 158 string MUST be no more and no less than the number specified by 159 the authority length. 161 o chunks 1..n - the request data broken into chunks (Section 6). 163 4. Response Blocks 165 There are two types of blocks used by a server to respond to a 166 client. The first type is a response block (RSB) defined in 167 Section 4.1. It is used by a server to respond to request blocks 168 (RQB). The second type is a specialized version of a response block 169 called a connection response block (CRB) defined in Section 4.2. It 170 is sent by a server to a client when a connection is established to 171 initiate protocol negotiation. Conceptually, a CRB is a type of RQB; 172 they share the same format, but a CRB is constrained in conveying 173 only specific information and is only sent at the beginning of the 174 session lifecycle. 176 4.1 Response Block (RSB) 178 The format for the response block (RSB) is as follows: 180 +--------+-------------+ 181 field | header | chunks 1..n | 182 | | | 183 +--------+-------------+ 184 octets 1 variable 186 These fields have the following meanings: 188 o header - as described in Section 5. 190 o chunks 1..n - the response data broken into chunks (Section 6). 192 Servers SHOULD NOT send an RSB to a client until they have received 193 the entire RQB. Servers that do begin sending an RSB before the 194 reception of the entire RQB must consider that clients will not be 195 expected to start processing the RSB until they have fully sent the 196 RQB, and that the RSB will may fill the clients TCP buffers. 198 4.2 Connection Response Block (CRB) 200 A connection response block (CRB) is a response block sent by a 201 server to a client in response to the client initiating a session. A 202 connection response block has the same format as a response block 203 (RSB) (Section 4.1). The only difference is that it is constrained 204 in one of two ways: 206 1. It contains only one chunk (see Section 6) containing version 207 information (see Section 6.2) and the keep-open (or KO) flag in 208 the block header (see Section 5) has a value of 1 (meaning the 209 connection is not closing). Servers MUST use this type of CRB to 210 indicate service availability. 212 2. It contains only one chunk (see Section 6) containing a system 213 error (see 'system-error' under Section 6.4) and the keep-open 214 (or KO) flag in the block header (see Section 5) has a value of 0 215 (meaning the server will close the connection immediately after 216 sending the CRB). Servers MUST use this type of CRB when they 217 can accept connections but cannot process requests. 219 5. Block Header 221 Each data block starts with a one octet header called the block 222 header. This header has the same format for both request and 223 response data blocks, though some of the bits in the header only have 224 meaning in one type of data block. The bits are ordered according to 225 the convention given in RFC 1166 [11], where bit 0 is the most 226 significant bit and bit 7 is the least significant bit. Each bit in 227 the block header has the following meaning: 229 o bits 0 and 1 - version (V field) - If 0 (both bits are zero), the 230 protocol is the version defined in this document. Otherwise, the 231 rest of the bits in the header and the block may be interpreted as 232 another version. 234 o bits 2 - keep open (KO flag) - This flag is used to request that a 235 connection stay open by a client and to indicate that a connection 236 will stay open by a server, depending on the type of block. In a 237 request block (RQB): a value of 1 indicates that a client is 238 requesting that the server not close the TCP session, and a value 239 of 0 indicates the client will expect ther server to close the TCP 240 session immediately after sending the corresponding response. In 241 a response block (RSB) or a connection response block (CRB): a 242 value of 1 indicates that the server will keep the TCP session 243 open to receive another request, and a value of 0 indicates that 244 the server will close the TCP session immediately following this 245 block. 247 o bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0. 249 6. Chunks 251 Request and response blocks break the request and response XML data 252 down into chunks. Request and response blocks MUST always have a 253 minimum of 1 chunk. Each chunk has a one octet descriptor. The 254 seventh bit of the descriptor determines if chunk is the last chunk 255 in the block. 257 The bits of the chunk descriptor octet are ordered according to 258 convention given in RFC 1166 [11], where bit 0 is the most 259 significant bit and bit 7 is the least significant bit. The bits of 260 the chunk descriptor octet have the following meaning: 262 o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk 263 in the block. 265 o bit 1 - data complete (DC flag) - If 1, the data in this chunk 266 represents the end of the data for the chunk type given. If this 267 bit is never set to 1 in any chunk descriptor for chunks of the 268 same type in a block, clients and servers MUST NOT assume the data 269 will continue in another block. If the block transitions from one 270 type of chunk to another with out signaling completion of the 271 data, clients and servers MUST assume that the remaining data will 272 not be sent in a remaining chunk. 274 o bits 2, 3, and 4 - reserved - These MUST be 0. 276 o bit 5, 6, and 7 - chunk type (CT field) - determines the type of 277 data carried in the chunk. These are the binary values for the 278 chunk types: 280 * 000 - no data or 'nd' type (see Section 6.1) 282 * 001 - version information or 'vi' type (see Section 6.2) 284 * 010 - size information or 'si' type (see Section 6.3) 286 * 011 - other information or 'oi type (see Section 6.4) 288 * 100 - SASL data or 'sd' type (see Section 6.5) 290 * 101 - authentication success information or 'as' type (see 291 Section 6.6) 293 * 110 - authentication failure information or 'af' type (see 294 Section 6.7) 296 * 111 - application data or 'ad' type (see Section 6.8) 298 A block MAY have multiple types of chunks, but all chunks of the same 299 type MUST be contingous in a block and MUST be ordered in the block 300 in the order in which their data is to be intepretted. Contiguous 301 chunks must by ordered by type within a block in the following way: 303 1. authentication related chunks - either SASL data chunks (type 304 100), authentication success information chunks (type 101) or 305 authentication failure information chunks (type 110), but not 306 more than one type 308 2. data chunks - either no data chunks (type 000) or application 309 data chunks (type 111), but not both. 311 3. information chunks - either version information (type 001) or 312 other information (type 011), but not both. 314 A block MUST have at least one type of the above chunks. 316 The format for a chunk is as follows: 318 +-----------+------------+--------+ 319 field | chunk | chunk data | chunk | 320 | descriptor| length | data | 321 +-----------+------------+--------+ 322 octets 1 2 variable 324 These fields have the following meanings: 326 o chunk descriptor - as described above. 328 o chunk data length - the length of the data of the chunk 330 o chunk data - the data of the chunk 332 6.1 No Data Types 334 Servers and clients MUST ignore data in chunk types labeled no data. 335 There is no requirement for these types of chunks to be zero length. 336 A client MAY send "no data" to a server, and the server MUST respond 337 with either a chunk of the same type or other information 338 (Section 6.4). 340 6.2 Version Information Types 342 Chunks of this type contain XML conformant to the schema specified in 344 [10] and MUST have the element as the root element. 346 In the context of IRIS-XPC, the protocol identifiers for these 347 elements are as follows: 349 o - the value "iris.xpc1" to indicate the 350 protocol specified in this document. 352 o - the XML namespace identifier for IRIS [1]. 354 o - the XML namespace identifier for IRIS registries. 356 In the context of IRIS-XPC, the authentication mechanism identifiers 357 are the SASL mechanism names found in the IANA SASL mechanism 358 registry defined by RFC 2222 [4]. 360 This document defines no extension identifiers. 362 Clients MAY send a block with this type of chunk to a server. These 363 chunks SHOULD be zero length and servers MUST ignore any data in 364 them. When a server receives a chunk of this type, it MUST respond 365 with a chunk of this type. This interchange allows a client to query 366 the version information of a server. 368 The definition of octet size for the 'requestSizeOctets' and 369 'responseSizeOctets' attributes of the element are 370 defined in Section 6.3. 372 6.3 Size Information Types 374 Chunks of this type contain XML conformant to the schema specified in 375 IRIS-COMMON [10] and MUST have the element as the root 376 element. 378 Octet counts provided by this information are defined as the sum of 379 the count of all chunk data of a particular chunk type. For 380 instance, if a XML instance is broken up into chunks of 20, 30, and 381 40 octets, the octet count would be 90 (20 + 30 + 40). 383 6.4 Other Information Types 385 Chunks of this type contain XML conformant to the schema specified in 386 IRIS-COMMON [10] and MUST have the element as the root 387 element. 389 The values for the 'type' attribute of are as follows: 391 'block-error' - indicates there was an error decoding a block. 392 Servers SHOULD send a block error in the following cases: 394 1. When a request block is received containing a chunk of this 395 type. 397 2. When a request block is received containing authentication 398 success (see Section 6.6) or authentication failure (see 399 Section 6.7) information. 401 3. When a request block is received containing size information 402 (see Section 6.3). 404 4. When reserved bits in the request block are 1. 406 5. When a block has not been received in its entirety and the TCP 407 session has been idle for a specific period of time (i.e. a 408 data block has been received but no terminating chunk for the 409 data block has been recieved). Two minutes is RECOMMENDED for 410 this timeout value. Note, there is a difference between an 411 idle condition due to the incomplete reception of a data block 412 and an idle condition between request/response transactions 413 associated with keeping the session open. For the latter, see 414 Section 7. 416 'data-error' - indicates there was an error parsing data in chunks 417 containing application or SASL data (e.g. XML is not valid in 418 application data). 420 'system-error' - indicates that the receiver cannot process the 421 request due to a condition not related to this protocol. Servers 422 SHOULD send a system-error when they are capable of responding to 423 requests but not capable of processing requests. 425 'authority-error' - indicates that the intended authority 426 specified in the corresponding request is not served by the 427 receiver. Servers SHOULD send an authority error when they 428 receive a request directed to an authority other than those they 429 serve. 431 'idle-timeout' - indicates that an XPC session has been idle for 432 too long. Usage of this value is defined in Section 7. Note, 433 there is a difference between an idle condition due to the 434 incomplete reception of a data block and an idle condition between 435 request/response transactions associated with keeping the session 436 open. For the former, see 'block-error' above. 438 6.5 SASL Types 440 The SASL chunk type allows clients and servers to exchange SASL data. 442 The format for the data of this type of chunk is as follows: 444 +-----------+-----------+-----------+-----------+ 445 field | mechanism | mechanism | mechanism | mechanism | 446 | name | name | data | data | 447 | length | | length | | 448 +-----------+-----------+-----------+-----------+ 449 octets 1 variable 2 variable 451 These fields have the following meaning: 453 o mechanism name length - the length of the SASL mechanism name 455 o mechanism - the name of the SASL mechanism as registered in the 456 IANA SASL mechanism registry defined by [4]. 458 o mechanism data length - the length of the SASL data 460 o mechanism data - the data used for SASL 462 These fields MUST NOT span multiple chunks. Therefore it should be 463 noted that SASL data length exceeding the length of the chunk minus 464 the length of SASL profile name minus one is an error. 466 Depending on the nature of the SASL mechansim being used, SASL data 467 is sent from clients to servers and from servers to clients and may 468 require multiple request/response transactions to complete. However, 469 once a SASL exchange is complete and a server can determine 470 authentication status, the server MUST send either authentication 471 success information (see Section 6.6) or authentication failure 472 information (see Section 6.7). 474 6.6 Authentication Succss Information Types 476 Chunks of this type contain XML conformant to the schema specified in 477 IRIS-COMMON [10] and MUST have the element as 478 the root element. 480 This type of chunk is only sent from a server to a client. If a 481 client sends it to a server, this will result in a block error (see 482 'block-error' in Section 6.4). The usage of this chunk type is 483 defined in Section 6.5. 485 6.7 Authentication Failure Information Types 487 Chunks of this type contain XML conformant to the schema specified in 488 IRIS-COMMON [10] and MUST have the element as 489 the root element. 491 This type of chunk is only sent from a server to a client. If a 492 client sends it to a server, this will result in a block error (see 493 'block-error' in Section 6.4). The usage of this chunk type is 494 defined in Section 6.5. 496 6.8 Application Data Types 498 These chunks contain application data. For IRIS, these are IRIS [1] 499 XML instances. 501 7. Idle Sessions 503 An XPC session may become idle between request/response transactions. 504 This can occur when a server honors a client's request to keep the 505 TCP connection running (see the keep-open or KO flag in the block 506 header (Section 5)). Servers are not expected to allow XPC sessions 507 remain idle between requests indefinitely. 509 Clients MUST send no less than 1 request every 2 minutes. This can 510 be any type of request specified by this document. If a client has 511 no need to send a specific type of request but must send a request to 512 fulfill this obligation, sending a request block containing one chunk 513 of "no data" (see Section 6.1) with a length of zero is RECOMMENDED. 515 If a server has not received a request block 5 minutes after sending 516 a response block (either RSB or CRB), it SHOULD do the following: 518 1. Send an unsolicited response block containing an idle timeout 519 error (see 'idle-timeout' in Section 6.4) with the keep-open (or 520 KO) flag in the block header (Section 5) set to a value of 0. 522 2. Close the TCP connection. 524 8. Use over TLS 526 XPC may be tunneled over TLS [5] by establishing a TLS session 527 immediately after a TCP session is opened and before any blocks are 528 to be sent. This type of session is known as XPCS. 530 When using TLS, a convention must be established to allow a client to 531 authenticate the validity of a server. XPCS uses the same convention 532 as described by IRIS-BEEP [2]. 534 9. Update to RFC 3981 536 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 537 the default transport for IRIS. This document revises RFC 3981 and 538 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 539 known port registration is specified in Section 12.5. 541 10. IRIS Transport Mapping Definitions 543 This section lists the definitions required by IRIS [1] for transport 544 mappings. 546 10.1 URI Scheme 548 See Section 12.1 and Section 12.2. 550 10.2 Application Protocol Label 552 See Section 12.3 and Section 12.4. 554 11. Internationalization Considerations 556 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 557 encodings. Use of the XML defined by [10] MUST NOT use any other 558 character encodings other than UTF-8 or UTF-16. 560 12. IANA Considerations 562 12.1 XPC URI Scheme Registration 564 URL scheme name: iris.xpc 566 URL scheme syntax: defined in [1]. 568 Character encoding considerations: as defined in RFC2396 [7]. 570 Intended usage: identifies IRIS XML using chunks over TCP 572 Applications using this scheme: defined in IRIS [1]. 574 Interoperability considerations: n/a 576 Security Considerations: defined in Section 13. 578 Relevant Publications: IRIS [1]. 580 Contact Information: Andrew Newton 582 Author/Change controller: the IESG 584 12.2 XPCS URI Scheme Registration 586 URL scheme name: iris.xpcs 588 URL scheme syntax: defined in [1]. 590 Character encoding considerations: as defined in RFC2396 [7]. 592 Intended usage: identifies IRIS XML using chunks over TLS 594 Applications using this scheme: defined in IRIS [1]. 596 Interoperability considerations: n/a 598 Security Considerations: defined in Section 13. 600 Relevant Publications: IRIS [1]. 602 Contact Information: Andrew Newton 604 Author/Change controller: the IESG 606 12.3 S-NAPTR XPC Registration 608 Application Protocol Label (see [6]): iris.xpc 610 Intended usage: identifies an IRIS server using XPC 612 Interoperability considerations: n/a 614 Security Considerations: defined in Section 13. 616 Relevant Publications: IRIS [1]. 618 Contact Information: Andrew Newton 620 Author/Change controller: the IESG 622 12.4 S-NAPTR XPCS Registration 624 Application Protocol Label (see [6]): iris.xpcs 626 Intended usage: identifies an IRIS server using secure XPCS 628 Interoperability considerations: n/a 630 Security Considerations: defined in Section 13. 632 Relevant Publications: IRIS [1]. 634 Contact Information: Andrew Newton 636 Author/Change controller: the IESG 638 12.5 Well-known TCP Port Registration 640 Protocol Number: TCP 642 Message Formats, Types, Opcodes, and Sequences: defined in 643 Section 4.2, Section 3, and Section 4.1. 645 Functions: defined in IRIS [1]. 647 Use of Broadcast/Multicast: none 649 Proposed Name: IRIS over XPC 651 Short name: iris.xpc 653 Contact Information: Andrew Newton 655 13. Security Considerations 657 Implementers should be fully aware of the security considerations 658 given by IRIS [1] and TLS [5]. With respect to server authentication 659 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 661 Clients SHOULD be prepared to use the following security mechanisms 662 in the following manner: 664 o SASL/DIGEST-MD5 - for user authentication without the need of 665 session encryption. 667 o SASL/OTP - for user authentication without the need of session 668 encryption. 670 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 671 encryption. 673 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 674 side certificates - for encryption and user authentication. 676 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 677 encryption. See [8]. 679 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 680 certificates - for encryption and user authentication. See [8]. 682 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 683 encryption. See [8]. 685 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 686 certificates - for encryption and user authentication. See [8]. 688 Anonymous client access SHOULD be considered in one of two methods: 690 1. When no authentication has been used. 692 2. Using the SASL anonymous profile: SASL/ANONYMOUS 694 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 695 mechanism without first encrypting the TCP session (e.g. such as with 696 TLS). 698 14. Normative References 700 [1] Newton, A. and M. Sanz, "Internet Registry Information 701 Service", RFC 3891, January 2004. 703 [2] Newton, A. and M. Sanz, "Using the Internet Registry 704 Information Service over the Blocks Extensible Exchange 705 Protocol", RFC 3893, January 2004. 707 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 708 ISBN 0-201-61633-5, 2000, . 710 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 711 RFC 2222, October 1997. 713 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 714 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 715 January 1999. 717 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 718 Location Using SRV RRs and the Dynamic Delegation Discovery 719 Service (DDDS)", RFC 3958, January 2005. 721 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 722 Resource Identifiers (URI): Generic Syntax", RFC 2396, 723 August 1998. 725 [8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 726 Transport Layer Security (TLS)", RFC 3268, June 2002. 728 [9] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", RFC 2119, BCP 14, March 1997. 731 [10] Newton, A., "A Common Schema for Internet Registry Information 732 Service Transfer Protocols", 733 draft-ietf-crips-iris-common-transport-00 (work in progress), 734 April 2005. 736 [11] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 737 RFC 1166, July 1990. 739 Author's Address 741 Andrew L. Newton 742 VeriSign, Inc. 743 21345 Ridgetop Circle 744 Sterling, VA 20166 745 USA 747 Phone: +1 703 948 3382 748 Email: anewton@verisignlabs.com; andy@hxr.us 749 URI: http://www.verisignlabs.com/ 751 Appendix A. Examples 753 This section gives examples of IRIS-XPC sessions. Lines beginning 754 with "C:" denote data sent by the client to the server, and lines 755 beginning with "S:" denote data sent by the server to the client. 756 Following the "C:" or "S:", the line either contains octet values in 757 hexadecimal notation with comments or XML fragments. No line 758 contains both octet values with comments and XML fragments. Comments 759 are contained within parenthesis. 761 It should also be noted that flag values of "yes" and "no" reflect 762 binary values 1 and 0. 764 The following example demonstrates an IRIS client issuing two 765 requests in one XPC session. In the first request, the client is 766 requesting status information for "example.com". This request and 767 its response are transfered with one chunk. In the second request, 768 the client is requesting status information for "milo.example.com", 769 "felix.example.com", and "hobbes.example.com". This request and its 770 response are transfered with three chunks. 772 S: (connection response block) 773 S: 0x20 (block header: V=0,KO=yes) 774 S: (chunk 1) 775 S: 0xC1 (LC=yes,DC=yes,CT=vi) 776 S: 0x01 0xBE (chunk length=446) 777 S: (Version Information) 778 S: 779 S: 780 S: 782 S: 784 S: 785 S: 786 S: 787 S: 788 S: 790 C: (request block) 791 C: 0x20 (block header: V=0,KO=yes) 792 C: 0x0B (authority length=11) 793 C: (authority="example.com") 794 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 795 C: (chunk 1) 796 C: 0xC7 (LC=yes,DC=yes,CT=ad) 797 C: 0x01 0x53 (chunk length=339) 798 C: (IRIS XML request) 799 C: 801 C: 802 C: 806 C: 807 C: 809 S: (response block) 810 S: 0x20 (block header: V=0,KO=yes) 811 S: (chunk 1) 812 S: 0xC7 (LC=yes,DC=yes,CT=ad) 813 S: 0x01 0xE0 (chunk length=480) 814 S: (IRIS XML response) 815 S: 816 S: 817 S: 818 S: 822 S: example.com 823 S: 824 S: 825 S: 826 S: 827 S: 828 S: 829 S: 831 C: (request block) 832 C: 0x00 (block header: V=0,KO=no) 833 C: 0x0B (authority length=11) 834 C: (authority="example.com") 835 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 836 C: (chunk 1) 837 C: 0x07 (LC=no,DC=no,CT=ad) 838 C: 0x01 0x4E (chunk length=339) 839 C: (IRIS XML request) 840 C: 843 C: 844 C: 848 C: 849 C: (chunk 2) 850 C: 0x07 (LC=no,DC=no,CT=ad) 851 C: 0x00 0xA9 (chunk length=169) 852 C: (IRIS XML request) 853 C: 854 C: 858 C: 859 C: (chunk 3) 860 C: 0xC7 (LC=yes,DC=yes,CT=ad) 861 C: 0x00 0xB5 (chunk length=181) 862 C: (IRIS XML request) 863 C: 864 C: 868 C: 869 C: 871 S: (response block) 872 S: 0x00 (block header: V=0,KO=no) 873 S: (chunk 1) 874 S: 0x07 (LC=no,DC=no,CT=ad) 875 S: 0x01 0xDA (chunk length=474) 876 S: (IRIS XML response) 877 S: 878 S: 879 S: 880 S: 884 S: milo.example.com 885 S: 886 S: 887 S: 888 S: 889 S: 890 S: 891 S: (chunk 2) 892 S: 0x07 (LC=no,DC=no,CT=ad) 893 S: 0x01 0xA2 (chunk length=418) 894 S: (IRIS XML response) 895 S: 896 S: 897 S: 901 S: felix.example.com 902 S: 903 S: 904 S: 905 S: 906 S: 907 S: 908 S: (chunk 3) 909 S: 0xC7 (LC=yes,DC=yes,CT=ad) 910 S: 0x01 0xB5 (chunk length=437) 911 S: (IRIS XML response) 912 S: 913 S: 914 S: 919 S: hobbes.example.com 920 S: 921 S: 922 S: 923 S: 924 S: 925 S: 926 S: 928 Figure 5: Example 1 930 In the following example, an IRIS client requests domain status 931 information for "milo.example.com", "felix.example.com", and 932 "hobbes.example.com" in one request. The request is sent with one 933 chunk, however the answer is returned in three chunks. 935 S: (connection response block) 936 S: 0x20 (block header: V=0,KO=yes) 937 S: (chunk 1) 938 S: 0xC1 (LC=yes,DC=yes,CT=vi) 939 S: 0x01 0xBE (chunk length=446) 940 S: (Version Information) 941 S: 942 S: 943 S: 945 S: 947 S: 948 S: 949 S: 950 S: 951 S: 953 C: (request block) 954 C: 0x00 (block header: V=0,KO=no) 955 C: 0x0B (authority length=11) 956 C: (authority="example.com") 957 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 958 C: (chunk 1) 959 C: 0xC7 (LC=yes,DC=yes,CT=ad) 960 C: 0x02 0xAB (chunk length=683) 961 C: (IRIS XML request) 962 C: 965 C: 966 C: 970 C: 971 C: 972 C: 976 C: 977 C: 978 C: 982 C: 983 C: 985 S: (response block) 986 S: 0x00 (block header: V=0,KO=no) 987 S: (chunk 1) 988 S: 0x07 (LC=no,DC=no,CT=ad) 989 S: 0x01 0xDA (chunk length=474) 990 S: (IRIS XML response) 991 S: 992 S: 993 S: 994 S: 998 S: milo.example.com 999 S: 1000 S: 1001 S: 1002 S: 1003 S: 1004 S: 1005 S: (chunk 2) 1006 S: 0x07 (LC=no,DC=no,CT=ad) 1007 S: 0x01 0xA2 (chunk length=418) 1008 S: (IRIS XML response) 1009 S: 1010 S: 1011 S: 1015 S: felix.example.com 1016 S: 1017 S: 1018 S: 1019 S: 1020 S: 1021 S: 1022 S: (chunk 3) 1023 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1024 S: 0x01 0xB5 (chunk length=437) 1025 S: (IRIS XML response) 1026 S: 1027 S: 1028 S: 1033 S: hobbes.example.com 1034 S: 1035 S: 1036 S: 1037 S: 1038 S: 1039 S: 1040 S: 1042 Figure 6: Example 2 1044 In the following example, an IRIS client sends a request containg 1045 SASL/PLAIN authentication data and a domain status check for 1046 "example.com". The server responds with authentication succss 1047 information and the domain status of "example.com". Note that the 1048 client requests that the connection stay open for further requests, 1049 but that the server does not honor this request. 1051 S: (connection response block) 1052 S: 0x20 (block header: V=0,KO=yes) 1053 S: (chunk 1) 1054 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1055 S: 0x01 0xBE (chunk length=446) 1056 S: (Version Information) 1057 S: 1058 S: 1059 S: 1061 S: 1063 S: 1064 S: 1065 S: 1066 S: 1067 S: 1069 C: (request block) 1070 C: 0x00 (block header: V=0,KO=no) 1071 C: 0x0B (authority length=11) 1072 C: (authority="example.com") 1073 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1074 C: (chunk 1) 1075 C: 0x44 (LC=no,DC=yes,CT=sd) 1076 C: 0x00 0x11 (chunk length=11) 1077 C: (SASL data) 1078 C: 0x05 (mechanism length=5) 1079 C: (mechanism name="PLAIN") 1080 C: 0x50 0x4C 0x41 0x49 0x43 1081 C: 0x00 0x0A (sasl PLAIN data length=10) 1082 C: (sasl PLAIN data: authcid="bob") 1083 C: (sasl PLAIN data: authzid=NULL) 1084 C: (sasl PLAIN data: password="kEw1") 1085 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1086 C: (chunk 2) 1087 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1088 C: 0x01 0x53 (chunk length=339) 1089 C: (IRIS XML request) 1090 C: 1092 C: 1093 C: 1097 C: 1098 C: 1100 S: (response block) 1101 S: 0x00 (block header: V=0,KO=no) 1102 S: (chunk 1) 1103 S: 0x45 (LC=no,DC=yes,CT=as) 1104 S: 0x00 0xD0 (chunk length=208) 1105 S: (authentication success response) 1106 S: 1107 S: 1109 S: 1110 S: user 'bob' authenticates via password 1111 S: 1112 S: 1113 S: (chunk 2) 1114 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1115 S: 0x01 0xE0 (chunk length=480) 1116 S: (IRIS XML response) 1117 S: 1118 S: 1119 S: 1120 S: 1124 S: example.com 1125 S: 1126 S: 1127 S: 1128 S: 1129 S: 1130 S: 1131 S: 1133 Figure 7: Example 3 1135 Appendix B. Contributors 1137 Substantive contributions to this document have been provided by the 1138 members of the IETF's CRISP Working Group, especially Robert Martin- 1139 Legene, Milena Caires, and David Blacka. 1141 Intellectual Property Statement 1143 The IETF takes no position regarding the validity or scope of any 1144 Intellectual Property Rights or other rights that might be claimed to 1145 pertain to the implementation or use of the technology described in 1146 this document or the extent to which any license under such rights 1147 might or might not be available; nor does it represent that it has 1148 made any independent effort to identify any such rights. Information 1149 on the procedures with respect to rights in RFC documents can be 1150 found in BCP 78 and BCP 79. 1152 Copies of IPR disclosures made to the IETF Secretariat and any 1153 assurances of licenses to be made available, or the result of an 1154 attempt made to obtain a general license or permission for the use of 1155 such proprietary rights by implementers or users of this 1156 specification can be obtained from the IETF on-line IPR repository at 1157 http://www.ietf.org/ipr. 1159 The IETF invites any interested party to bring to its attention any 1160 copyrights, patents or patent applications, or other proprietary 1161 rights that may cover technology that may be required to implement 1162 this standard. Please address the information to the IETF at 1163 ietf-ipr@ietf.org. 1165 Disclaimer of Validity 1167 This document and the information contained herein are provided on an 1168 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1169 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1170 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1171 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1172 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1173 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1175 Copyright Statement 1177 Copyright (C) The Internet Society (2005). This document is subject 1178 to the rights, licenses and restrictions contained in BCP 78, and 1179 except as set forth therein, the authors retain all their rights. 1181 Acknowledgment 1183 Funding for the RFC Editor function is currently provided by the 1184 Internet Society.