idnits 2.17.1 draft-ietf-crisp-iris-xpc-04.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 1215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1205. ** 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 (May 25, 2006) is 6545 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) May 25, 2006 5 Expires: November 26, 2006 7 XML Pipelining with Chunks for the Information Registry Information 8 Service 9 draft-ietf-crisp-iris-xpc-04 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 November 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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. Closing Sessions Due To An Error . . . . . . . . . . . . . . . 16 66 9. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 10. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . . 18 68 11. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 19 69 11.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 19 70 11.2. Application Protocol Label . . . . . . . . . . . . . . . . 19 71 12. Internationalization Considerations . . . . . . . . . . . . . 20 72 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 13.1. XPC URI Scheme Registration . . . . . . . . . . . . . . . 21 74 13.2. XPCS URI Scheme Registration . . . . . . . . . . . . . . . 21 75 13.3. S-NAPTR XPC Registration . . . . . . . . . . . . . . . . . 22 76 13.4. S-NAPTR XPCS Registration . . . . . . . . . . . . . . . . 22 77 13.5. Well-known TCP Port Registration for XPC . . . . . . . . . 22 78 13.6. Well-known TCP Port Registration for XPCS . . . . . . . . 23 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 15. Normative References . . . . . . . . . . . . . . . . . . . . . 24 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 82 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 34 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 Intellectual Property and Copyright Statements . . . . . . . . . . 36 86 1. Introduction 88 Using S-NAPTR [6], IRIS has the ability to define the use of multiple 89 application transports (or transfer protocols) for different types of 90 registry services, all at the descretion of the server operator. The 91 TCP transfer protocol defined in this document is completely modular 92 and may be used by any registry types. 94 This transfer protocol defines simple framing for sending XML in 95 chunks so that XML fragments may be acted upon (or pipelined) before 96 the reception of the entire XML instance. This document calls this 97 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 99 XPC is for use with simple request and response interactions between 100 clients and servers. Clients send a series of requests to a server 101 in data blocks. The server will respond to each data block 102 individually with a corresponding data block, but through the same 103 connection. Request and response data blocks are sent using the TCP 104 SEND function and received using the TCP RECEIVE function. 106 The lifecycle of an XPC session has the following phases: 108 1. A client establishes a TCP connection with a server. 110 2. The server sends a connection response block (CRB). 112 3. The client sends a request block (RQB). In this request, the 113 client can set a "keep open" flag requesting that the server keep 114 the XPC session open following the response to this request. 116 4. The server responds with a response block (RSB). In this 117 response, the server can indicate to the client whether or not 118 the XPC session will be closed. 120 5. If the XPC session is not to be terminated, then the lifecycle 121 repeats from step 3. 123 6. The TCP connection is closed. 125 2. Document Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC2119 [9]. 131 Octet fields with numberic values are given according to the 132 conventions in RFC 1166 [11]: the left most bit of the whole field is 133 the most significant bit; when a multi-octet quantity is transmitted 134 the most significant octet is transmitted first. Bits signifying 135 flags in an octet are numbered according to the conventions of RFC 136 1166 [11]: bit 0 is the most significant bit and bit 7 is the least 137 significant bit. When a diagram describes a group of octets, the 138 order of tranmission for the octets starts from the left. 140 3. Request Block (RQB) 142 The format for the request block (RQB) is as follows: 144 +--------+-----------+-----------+-------------+ 145 field | header | authority | authority | chunks 1..n | 146 | | length | | | 147 +--------+-----------+-----------+-------------+ 148 octets 1 1 0..255 variable 150 These fields have the following meanings: 152 o header - as described in Section 5. 154 o authority length - the length of the authority field in this 155 request block 157 o authority - a string of octets describing the authority against 158 which this request is to be executed. See [1] for the definition 159 and description of an authority. The number of octets in this 160 string MUST be no more and no less than the number specified by 161 the authority length. 163 o chunks 1..n - the request data broken into chunks (Section 6). 165 4. Response Blocks 167 There are two types of blocks used by a server to respond to a 168 client. The first type is a response block (RSB) defined in 169 Section 4.1. It is used by a server to respond to request blocks 170 (RQB). The second type is a specialized version of a response block 171 called a connection response block (CRB) defined in Section 4.2. It 172 is sent by a server to a client when a connection is established to 173 initiate protocol negotiation. Conceptually, a CRB is a type of RQB; 174 they share the same format, but a CRB is constrained in conveying 175 only specific information and is only sent at the beginning of the 176 session lifecycle. 178 4.1. Response Block (RSB) 180 The format for the response block (RSB) is as follows: 182 +--------+-------------+ 183 field | header | chunks 1..n | 184 | | | 185 +--------+-------------+ 186 octets 1 variable 188 These fields have the following meanings: 190 o header - as described in Section 5. 192 o chunks 1..n - the response data broken into chunks (Section 6). 194 Servers SHOULD NOT send an RSB to a client until they have received 195 the entire RQB. Servers that do begin sending an RSB before the 196 reception of the entire RQB must consider that clients will not be 197 expected to start processing the RSB until they have fully sent the 198 RQB, and that the RSB will may fill the clients TCP buffers. 200 4.2. Connection Response Block (CRB) 202 A connection response block (CRB) is a response block sent by a 203 server to a client in response to the client initiating a session. A 204 connection response block has the same format as a response block 205 (RSB) (Section 4.1). The only difference is that it is constrained 206 in one of two ways: 208 1. It contains only one chunk (see Section 6) containing version 209 information (see Section 6.2) and the keep-open (or KO) flag in 210 the block header (see Section 5) has a value of 1 (meaning the 211 connection is not closing). Servers MUST use this type of CRB to 212 indicate service availability. 214 2. It contains only one chunk (see Section 6) containing a system 215 error (see 'system-error' under Section 6.4) and the keep-open 216 (or KO) flag in the block header (see Section 5) has a value of 0 217 (meaning the server will close the connection immediately after 218 sending the CRB). Servers MUST use this type of CRB when they 219 can accept connections but cannot process requests. 221 5. Block Header 223 Each data block starts with a one octet header called the block 224 header. This header has the same format for both request and 225 response data blocks, though some of the bits in the header only have 226 meaning in one type of data block. The bits are ordered according to 227 the convention given in RFC 1166 [11], where bit 0 is the most 228 significant bit and bit 7 is the least significant bit. Each bit in 229 the block header has the following meaning: 231 o bits 0 and 1 - version (V field) - If 0 (both bits are zero), the 232 protocol is the version defined in this document. Otherwise, the 233 rest of the bits in the header and the block may be interpreted as 234 another version. 236 o bits 2 - keep open (KO flag) - This flag is used to request that a 237 connection stay open by a client and to indicate that a connection 238 will stay open by a server, depending on the type of block. In a 239 request block (RQB): a value of 1 indicates that a client is 240 requesting that the server not close the TCP session, and a value 241 of 0 indicates the client will expect ther server to close the TCP 242 session immediately after sending the corresponding response. In 243 a response block (RSB) or a connection response block (CRB): a 244 value of 1 indicates that the server will keep the TCP session 245 open to receive another request, and a value of 0 indicates that 246 the server will close the TCP session immediately following this 247 block. 249 o bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0. 251 6. Chunks 253 Request and response blocks break the request and response XML data 254 down into chunks. Request and response blocks MUST always have a 255 minimum of 1 chunk. Each chunk has a one octet descriptor. The 256 first bit of the descriptor determines if chunk is the last chunk in 257 the block. 259 The bits of the chunk descriptor octet are ordered according to 260 convention given in RFC 1166 [11], where bit 0 is the most 261 significant bit and bit 7 is the least significant bit. The bits of 262 the chunk descriptor octet have the following meaning: 264 o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk 265 in the block. 267 o bit 1 - data complete (DC flag) - If 1, the data in this chunk 268 represents the end of the data for the chunk type given. If this 269 bit is never set to 1 in any chunk descriptor for chunks of the 270 same type in a block, clients and servers MUST NOT assume the data 271 will continue in another block. If the block transitions from one 272 type of chunk to another with out signaling completion of the 273 data, clients and servers MUST assume that the remaining data will 274 not be sent in a remaining chunk. 276 o bits 2, 3, and 4 - reserved - These MUST be 0. 278 o bit 5, 6, and 7 - chunk type (CT field) - determines the type of 279 data carried in the chunk. These are the binary values for the 280 chunk types: 282 * 000 - no data or 'nd' type (see Section 6.1) 284 * 001 - version information or 'vi' type (see Section 6.2) 286 * 010 - size information or 'si' type (see Section 6.3) 288 * 011 - other information or 'oi type (see Section 6.4) 290 * 100 - SASL data or 'sd' type (see Section 6.5) 292 * 101 - authentication success information or 'as' type (see 293 Section 6.6) 295 * 110 - authentication failure information or 'af' type (see 296 Section 6.7) 298 * 111 - application data or 'ad' type (see Section 6.8) 300 A block MAY have multiple types of chunks, but all chunks of the same 301 type MUST be contingous in a block and MUST be ordered in the block 302 in the order in which their data is to be intepretted. Contiguous 303 chunks must by ordered by type within a block in the following way: 305 1. authentication related chunks - either SASL data chunks (type 306 100), authentication success information chunks (type 101) or 307 authentication failure information chunks (type 110), but not 308 more than one type 310 2. data chunks - either no data chunks (type 000) or application 311 data chunks (type 111), but not both. 313 3. information chunks - either version information (type 001) or 314 other information (type 011), but not both. 316 A block MUST have at least one type of the above chunks. 318 The format for a chunk is as follows: 320 +-----------+------------+--------+ 321 field | chunk | chunk data | chunk | 322 | descriptor| length | data | 323 +-----------+------------+--------+ 324 octets 1 2 variable 326 These fields have the following meanings: 328 o chunk descriptor - as described above. 330 o chunk data length - the length of the data of the chunk 332 o chunk data - the data of the chunk 334 6.1. No Data Types 336 Servers and clients MUST ignore data in chunk types labeled no data. 337 There is no requirement for these types of chunks to be zero length. 338 A client MAY send "no data" to a server, and the server MUST respond 339 with either a chunk of the same type or other information 340 (Section 6.4). 342 6.2. Version Information Types 344 Chunks of this type contain XML conformant to the schema specified in 345 [10] and MUST have the element as the root element. 347 In the context of IRIS-XPC, the protocol identifiers for these 348 elements are as follows: 350 o - the value "iris.xpc1" to indicate the 351 protocol specified in this document. 353 o - the XML namespace identifier for IRIS [1]. 355 o - the XML namespace identifier for IRIS registries. 357 In the context of IRIS-XPC, the authentication mechanism identifiers 358 are the SASL mechanism names found in the IANA SASL mechanism 359 registry defined by RFC 2222 [4]. 361 This document defines no extension identifiers. 363 Clients MAY send a block with this type of chunk to a server. These 364 chunks SHOULD be zero length and servers MUST ignore any data in 365 them. When a server receives a chunk of this type, it MUST respond 366 with a chunk of this type. This interchange allows a client to query 367 the version information of a server. 369 The definition of octet size for the 'requestSizeOctets' and 370 'responseSizeOctets' attributes of the element are 371 defined in Section 6.3. 373 6.3. Size Information Types 375 Chunks of this type contain XML conformant to the schema specified in 376 IRIS-COMMON [10] and MUST have the element as the root 377 element. 379 Octet counts provided by this information are defined as the sum of 380 the count of all chunk data of a particular chunk type. For 381 instance, if a XML instance is broken up into chunks of 20, 30, and 382 40 octets, the octet count would be 90 (20 + 30 + 40). 384 Clients MUST NOT send chunks of this type, and servers MAY close down 385 a session using the procedure in Section 8 if a chunk of this type is 386 received. 388 6.4. Other Information Types 390 Chunks of this type contain XML conformant to the schema specified in 391 IRIS-COMMON [10] and MUST have the element as the root 392 element. 394 The values for the 'type' attribute of are as follows: 396 'block-error' - indicates there was an error decoding a block. 397 Servers SHOULD send a block error in the following cases: 399 1. When a request block is received containing a chunk of this 400 type. 402 2. When a request block is received containing authentication 403 success (see Section 6.6) or authentication failure (see 404 Section 6.7) information. 406 3. When a request block is received containing size information 407 (see Section 6.3). 409 4. When reserved bits in the request block are 1. 411 5. When a block has not been received in its entirety and the TCP 412 session has been idle for a specific period of time (i.e. a 413 data block has been received but no terminating chunk for the 414 data block has been recieved). Two minutes is RECOMMENDED for 415 this timeout value. Note, there is a difference between an 416 idle condition due to the incomplete reception of a data block 417 and an idle condition between request/response transactions 418 associated with keeping the session open. For the latter, see 419 Section 7. 421 'data-error' - indicates there was an error parsing data in chunks 422 containing application or SASL data (e.g. XML is not valid in 423 application data). 425 'system-error' - indicates that the receiver cannot process the 426 request due to a condition not related to this protocol. Servers 427 SHOULD send a system-error when they are capable of responding to 428 requests but not capable of processing requests. 430 'authority-error' - indicates that the intended authority 431 specified in the corresponding request is not served by the 432 receiver. Servers SHOULD send an authority error when they 433 receive a request directed to an authority other than those they 434 serve. 436 'idle-timeout' - indicates that an XPC session has been idle for 437 too long. Usage of this value is defined in Section 7. Note, 438 there is a difference between an idle condition due to the 439 incomplete reception of a data block and an idle condition between 440 request/response transactions associated with keeping the session 441 open. For the former, see 'block-error' above. 443 Clients MUST NOT send chunks of this type, and servers MAY close down 444 a session using the procedure in Section 8 if a chunk of this type is 445 received. 447 6.5. SASL Types 449 The SASL chunk type allows clients and servers to exchange SASL data. 451 The format for the data of this type of chunk is as follows: 453 +-----------+-----------+-----------+-----------+ 454 field | mechanism | mechanism | mechanism | mechanism | 455 | name | name | data | data | 456 | length | | length | | 457 +-----------+-----------+-----------+-----------+ 458 octets 1 variable 2 variable 460 These fields have the following meaning: 462 o mechanism name length - the length of the SASL mechanism name 464 o mechanism - the name of the SASL mechanism as registered in the 465 IANA SASL mechanism registry defined by [4]. 467 o mechanism data length - the length of the SASL data 469 o mechanism data - the data used for SASL 471 These fields MUST NOT span multiple chunks. Therefore it should be 472 noted that SASL data length exceeding the length of the chunk minus 473 the length of SASL profile name minus one is an error. 475 Depending on the nature of the SASL mechansim being used, SASL data 476 is sent from clients to servers and from servers to clients and may 477 require multiple request/response transactions to complete. However, 478 once a SASL exchange is complete and a server can determine 479 authentication status, the server MUST send either authentication 480 success information (see Section 6.6) or authentication failure 481 information (see Section 6.7). 483 6.6. Authentication Succss Information Types 485 Chunks of this type contain XML conformant to the schema specified in 486 IRIS-COMMON [10] and MUST have the element as 487 the root element. 489 This type of chunk is only sent from a server to a client. If a 490 client sends it to a server, this will result in a block error (see 491 'block-error' in Section 6.4). The usage of this chunk type is 492 defined in Section 6.5. A server MAY close down a session due to 493 reception of this type of chunk using the procedure in Section 8. 495 6.7. Authentication Failure Information Types 497 Chunks of this type contain XML conformant to the schema specified in 498 IRIS-COMMON [10] and MUST have the element as 499 the root element. 501 This type of chunk is only sent from a server to a client. If a 502 client sends it to a server, this will result in a block error (see 503 'block-error' in Section 6.4). The usage of this chunk type is 504 defined in Section 6.5. A server MAY close down a session due to 505 reception of this type of chunk using the procedure in Section 8. 507 6.8. Application Data Types 509 These chunks contain application data. For IRIS, these are IRIS [1] 510 XML instances. 512 7. Idle Sessions 514 An XPC session may become idle between request/response transactions. 515 This can occur when a server honors a client's request to keep the 516 TCP connection running (see the keep-open or KO flag in the block 517 header (Section 5)). Servers are not expected to allow XPC sessions 518 remain idle between requests indefinitely. 520 Clients MUST send no less than 1 request every 2 minutes. This can 521 be any type of request specified by this document. If a client has 522 no need to send a specific type of request but must send a request to 523 fulfill this obligation, sending a request block containing one chunk 524 of "no data" (see Section 6.1) with a length of zero is RECOMMENDED. 526 If a server has not received a request block 5 minutes after sending 527 a response block (either RSB or CRB), it SHOULD do the following: 529 1. Send an unsolicited response block containing an idle timeout 530 error (see 'idle-timeout' in Section 6.4) with the keep-open (or 531 KO) flag in the block header (Section 5) set to a value of 0. 533 2. Close the TCP connection. 535 8. Closing Sessions Due To An Error 537 If a server is to close a session due to an error, it SHOULD do the 538 following: 540 1. Send a response block containing either a block-error or data- 541 error (see Section 6.4) with the keep-open (or KO) flag in the 542 block header (Section 5) set to a value of 0. 544 2. Close the TCP connection. 546 9. Use over TLS 548 XPC may be tunneled over TLS [5] by establishing a TLS session 549 immediately after a TCP session is opened and before any blocks are 550 to be sent. This type of session is known as XPCS. 552 When using TLS, a convention must be established to allow a client to 553 authenticate the validity of a server. XPCS uses the same convention 554 as described by IRIS-BEEP [2]. 556 10. Update to RFC 3981 558 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 559 the default transport for IRIS. This document revises RFC 3981 and 560 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 561 known port registration is specified in Section 13.5. 563 11. IRIS Transport Mapping Definitions 565 This section lists the definitions required by IRIS [1] for transport 566 mappings. 568 11.1. URI Scheme 570 See Section 13.1 and Section 13.2. 572 11.2. Application Protocol Label 574 See Section 13.3 and Section 13.4. 576 12. Internationalization Considerations 578 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 579 encodings. Use of the XML defined by [10] MUST NOT use any other 580 character encodings other than UTF-8 or UTF-16. 582 13. IANA Considerations 584 13.1. XPC URI Scheme Registration 586 URL scheme name: iris.xpc 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 TCP 594 Applications using this scheme: defined in IRIS [1]. 596 Interoperability considerations: n/a 598 Security Considerations: defined in Section 14. 600 Relevant Publications: IRIS [1]. 602 Contact Information: Andrew Newton 604 Author/Change controller: the IESG 606 13.2. XPCS URI Scheme Registration 608 URL scheme name: iris.xpcs 610 URL scheme syntax: defined in [1]. 612 Character encoding considerations: as defined in RFC2396 [7]. 614 Intended usage: identifies IRIS XML using chunks over TLS 616 Applications using this scheme: defined in IRIS [1]. 618 Interoperability considerations: n/a 620 Security Considerations: defined in Section 14. 622 Relevant Publications: IRIS [1]. 624 Contact Information: Andrew Newton 626 Author/Change controller: the IESG 628 13.3. S-NAPTR XPC Registration 630 Application Protocol Label (see [6]): iris.xpc 632 Intended usage: identifies an IRIS server using XPC 634 Interoperability considerations: n/a 636 Security Considerations: defined in Section 14. 638 Relevant Publications: IRIS [1]. 640 Contact Information: Andrew Newton 642 Author/Change controller: the IESG 644 13.4. S-NAPTR XPCS Registration 646 Application Protocol Label (see [6]): iris.xpcs 648 Intended usage: identifies an IRIS server using secure XPCS 650 Interoperability considerations: n/a 652 Security Considerations: defined in Section 14. 654 Relevant Publications: IRIS [1]. 656 Contact Information: Andrew Newton 658 Author/Change controller: the IESG 660 13.5. Well-known TCP Port Registration for XPC 662 Protocol Number: TCP 664 TCP Port Number: TBD by IANA 666 Message Formats, Types, Opcodes, and Sequences: defined in 667 Section 4.2, Section 3, and Section 4.1. 669 Functions: defined in IRIS [1]. 671 Use of Broadcast/Multicast: none 673 Proposed Name: IRIS over XPC 675 Short name: iris.xpc 676 Contact Information: Andrew Newton 678 13.6. Well-known TCP Port Registration for XPCS 680 Protocol Number: TCP 682 TCP Port Number: TBD by IANA 684 Message Formats, Types, Opcodes, and Sequences: defined in Section 9, 685 Section 4.2, Section 3, and Section 4.1. 687 Functions: defined in IRIS [1]. 689 Use of Broadcast/Multicast: none 691 Proposed Name: IRIS over XPCS 693 Short name: iris.xpcs 695 Contact Information: Andrew Newton 697 14. Security Considerations 699 Implementers should be fully aware of the security considerations 700 given by IRIS [1] and TLS [5]. With respect to server authentication 701 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 703 Clients SHOULD be prepared to use the following security mechanisms 704 in the following manner: 706 o SASL/DIGEST-MD5 - for user authentication without the need of 707 session encryption. 709 o SASL/OTP - for user authentication without the need of session 710 encryption. 712 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 713 encryption. 715 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 716 side certificates - for encryption and user authentication. 718 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 719 encryption. See [8]. 721 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 722 certificates - for encryption and user authentication. See [8]. 724 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 725 encryption. See [8]. 727 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 728 certificates - for encryption and user authentication. See [8]. 730 Anonymous client access SHOULD be considered in one of two methods: 732 1. When no authentication has been used. 734 2. Using the SASL anonymous profile: SASL/ANONYMOUS 736 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 737 mechanism without first encrypting the TCP session (e.g. such as with 738 TLS). 740 15. Normative References 742 [1] Newton, A. and M. Sanz, "Internet Registry Information 743 Service", RFC 3981, January 2004. 745 [2] Newton, A. and M. Sanz, "Using the Internet Registry 746 Information Service over the Blocks Extensible Exchange 747 Protocol", RFC 3983, January 2004. 749 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 750 ISBN 0-201-61633-5, 2000, . 752 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 753 RFC 2222, October 1997. 755 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 756 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 757 January 1999. 759 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 760 Location Using SRV RRs and the Dynamic Delegation Discovery 761 Service (DDDS)", RFC 3958, January 2005. 763 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 764 Resource Identifiers (URI): Generic Syntax", RFC 2396, 765 August 1998. 767 [8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 768 Transport Layer Security (TLS)", RFC 3268, June 2002. 770 [9] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", RFC 2119, BCP 14, March 1997. 773 [10] Newton, A., "A Common Schema for Internet Registry Information 774 Service Transfer Protocols", 775 draft-ietf-crips-iris-common-transport-00 (work in progress), 776 April 2005. 778 [11] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 779 RFC 1166, July 1990. 781 Appendix A. Examples 783 This section gives examples of IRIS-XPC sessions. Lines beginning 784 with "C:" denote data sent by the client to the server, and lines 785 beginning with "S:" denote data sent by the server to the client. 786 Following the "C:" or "S:", the line either contains octet values in 787 hexadecimal notation with comments or XML fragments. No line 788 contains both octet values with comments and XML fragments. Comments 789 are contained within parenthesis. 791 It should also be noted that flag values of "yes" and "no" reflect 792 binary values 1 and 0. 794 The following example demonstrates an IRIS client issuing two 795 requests in one XPC session. In the first request, the client is 796 requesting status information for "example.com". This request and 797 its response are transfered with one chunk. In the second request, 798 the client is requesting status information for "milo.example.com", 799 "felix.example.com", and "hobbes.example.com". This request and its 800 response are transfered with three chunks. 802 S: (connection response block) 803 S: 0x20 (block header: V=0,KO=yes) 804 S: (chunk 1) 805 S: 0xC1 (LC=yes,DC=yes,CT=vi) 806 S: 0x01 0xBF (chunk length=447) 807 S: (Version Information) 808 S: 809 S: 810 S: 812 S: 814 S: 815 S: 816 S: 817 S: 818 S: 820 C: (request block) 821 C: 0x20 (block header: V=0,KO=yes) 822 C: 0x0B (authority length=11) 823 C: (authority="example.com") 824 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 825 C: (chunk 1) 826 C: 0xC7 (LC=yes,DC=yes,CT=ad) 827 C: 0x01 0x53 (chunk length=339) 828 C: (IRIS XML request) 829 C: 831 C: 832 C: 836 C: 837 C: 839 S: (response block) 840 S: 0x20 (block header: V=0,KO=yes) 841 S: (chunk 1) 842 S: 0xC7 (LC=yes,DC=yes,CT=ad) 843 S: 0x01 0xE0 (chunk length=480) 844 S: (IRIS XML response) 845 S: 846 S: 847 S: 848 S: 852 S: example.com 853 S: 854 S: 855 S: 856 S: 857 S: 858 S: 859 S: 861 C: (request block) 862 C: 0x00 (block header: V=0,KO=no) 863 C: 0x0B (authority length=11) 864 C: (authority="example.com") 865 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 866 C: (chunk 1) 867 C: 0x07 (LC=no,DC=no,CT=ad) 868 C: 0x01 0x4E (chunk length=339) 869 C: (IRIS XML request) 870 C: 873 C: 874 C: 878 C: 879 C: (chunk 2) 880 C: 0x07 (LC=no,DC=no,CT=ad) 881 C: 0x00 0xA9 (chunk length=169) 882 C: (IRIS XML request) 883 C: 884 C: 888 C: 889 C: (chunk 3) 890 C: 0xC7 (LC=yes,DC=yes,CT=ad) 891 C: 0x00 0xB5 (chunk length=181) 892 C: (IRIS XML request) 893 C: 894 C: 898 C: 899 C: 901 S: (response block) 902 S: 0x00 (block header: V=0,KO=no) 903 S: (chunk 1) 904 S: 0x07 (LC=no,DC=no,CT=ad) 905 S: 0x01 0xDA (chunk length=474) 906 S: (IRIS XML response) 907 S: 908 S: 909 S: 910 S: 914 S: milo.example.com 915 S: 916 S: 917 S: 918 S: 919 S: 920 S: 921 S: (chunk 2) 922 S: 0x07 (LC=no,DC=no,CT=ad) 923 S: 0x01 0xA2 (chunk length=418) 924 S: (IRIS XML response) 925 S: 926 S: 927 S: 931 S: felix.example.com 932 S: 933 S: 934 S: 935 S: 936 S: 937 S: 938 S: (chunk 3) 939 S: 0xC7 (LC=yes,DC=yes,CT=ad) 940 S: 0x01 0xB5 (chunk length=437) 941 S: (IRIS XML response) 942 S: 943 S: 944 S: 949 S: hobbes.example.com 950 S: 951 S: 952 S: 953 S: 954 S: 955 S: 956 S: 958 Figure 5: Example 1 960 In the following example, an IRIS client requests domain status 961 information for "milo.example.com", "felix.example.com", and 962 "hobbes.example.com" in one request. The request is sent with one 963 chunk, however the answer is returned in three chunks. 965 S: (connection response block) 966 S: 0x20 (block header: V=0,KO=yes) 967 S: (chunk 1) 968 S: 0xC1 (LC=yes,DC=yes,CT=vi) 969 S: 0x01 0xBF (chunk length=447) 970 S: (Version Information) 971 S: 972 S: 973 S: 975 S: 977 S: 978 S: 979 S: 980 S: 981 S: 983 C: (request block) 984 C: 0x00 (block header: V=0,KO=no) 985 C: 0x0B (authority length=11) 986 C: (authority="example.com") 987 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 988 C: (chunk 1) 989 C: 0xC7 (LC=yes,DC=yes,CT=ad) 990 C: 0x02 0xAB (chunk length=683) 991 C: (IRIS XML request) 992 C: 995 C: 996 C: 1000 C: 1001 C: 1002 C: 1006 C: 1007 C: 1008 C: 1012 C: 1013 C: 1015 S: (response block) 1016 S: 0x00 (block header: V=0,KO=no) 1017 S: (chunk 1) 1018 S: 0x07 (LC=no,DC=no,CT=ad) 1019 S: 0x01 0xDA (chunk length=474) 1020 S: (IRIS XML response) 1021 S: 1022 S: 1023 S: 1024 S: 1028 S: milo.example.com 1029 S: 1030 S: 1031 S: 1032 S: 1033 S: 1034 S: 1035 S: (chunk 2) 1036 S: 0x07 (LC=no,DC=no,CT=ad) 1037 S: 0x01 0xA2 (chunk length=418) 1038 S: (IRIS XML response) 1039 S: 1040 S: 1041 S: 1045 S: felix.example.com 1046 S: 1047 S: 1048 S: 1049 S: 1050 S: 1051 S: 1052 S: (chunk 3) 1053 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1054 S: 0x01 0xB5 (chunk length=437) 1055 S: (IRIS XML response) 1056 S: 1057 S: 1058 S: 1063 S: hobbes.example.com 1064 S: 1065 S: 1066 S: 1067 S: 1068 S: 1069 S: 1070 S: 1072 Figure 6: Example 2 1074 In the following example, an IRIS client sends a request containg 1075 SASL/PLAIN authentication data and a domain status check for 1076 "example.com". The server responds with authentication succss 1077 information and the domain status of "example.com". Note that the 1078 client requests that the connection stay open for further requests, 1079 but that the server does not honor this request. 1081 S: (connection response block) 1082 S: 0x20 (block header: V=0,KO=yes) 1083 S: (chunk 1) 1084 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1085 S: 0x01 0xBF (chunk length=447) 1086 S: (Version Information) 1087 S: 1088 S: 1089 S: 1091 S: 1093 S: 1094 S: 1095 S: 1096 S: 1097 S: 1099 C: (request block) 1100 C: 0x00 (block header: V=0,KO=no) 1101 C: 0x0B (authority length=11) 1102 C: (authority="example.com") 1103 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1104 C: (chunk 1) 1105 C: 0x44 (LC=no,DC=yes,CT=sd) 1106 C: 0x00 0x11 (chunk length=11) 1107 C: (SASL data) 1108 C: 0x05 (mechanism length=5) 1109 C: (mechanism name="PLAIN") 1110 C: 0x50 0x4C 0x41 0x49 0x43 1111 C: 0x00 0x0A (sasl PLAIN data length=10) 1112 C: (sasl PLAIN data: authcid="bob") 1113 C: (sasl PLAIN data: authzid=NULL) 1114 C: (sasl PLAIN data: password="kEw1") 1115 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1116 C: (chunk 2) 1117 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1118 C: 0x01 0x53 (chunk length=339) 1119 C: (IRIS XML request) 1120 C: 1122 C: 1123 C: 1127 C: 1128 C: 1130 S: (response block) 1131 S: 0x00 (block header: V=0,KO=no) 1132 S: (chunk 1) 1133 S: 0x45 (LC=no,DC=yes,CT=as) 1134 S: 0x00 0xD0 (chunk length=208) 1135 S: (authentication success response) 1136 S: 1137 S: 1139 S: 1140 S: user 'bob' authenticates via password 1141 S: 1142 S: 1143 S: (chunk 2) 1144 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1145 S: 0x01 0xE0 (chunk length=480) 1146 S: (IRIS XML response) 1147 S: 1148 S: 1149 S: 1150 S: 1154 S: example.com 1155 S: 1156 S: 1157 S: 1158 S: 1159 S: 1160 S: 1161 S: 1163 Figure 7: Example 3 1165 Appendix B. Contributors 1167 Substantive contributions to this document have been provided by the 1168 members of the IETF's CRISP Working Group, especially Robert Martin- 1169 Legene, Milena Caires, and David Blacka. 1171 Author's Address 1173 Andrew L. Newton 1174 VeriSign, Inc. 1175 21345 Ridgetop Circle 1176 Sterling, VA 20166 1177 USA 1179 Phone: +1 703 948 3382 1180 Email: andy@hxr.us 1181 URI: http://www.verisignlabs.com/ 1183 Intellectual Property Statement 1185 The IETF takes no position regarding the validity or scope of any 1186 Intellectual Property Rights or other rights that might be claimed to 1187 pertain to the implementation or use of the technology described in 1188 this document or the extent to which any license under such rights 1189 might or might not be available; nor does it represent that it has 1190 made any independent effort to identify any such rights. Information 1191 on the procedures with respect to rights in RFC documents can be 1192 found in BCP 78 and BCP 79. 1194 Copies of IPR disclosures made to the IETF Secretariat and any 1195 assurances of licenses to be made available, or the result of an 1196 attempt made to obtain a general license or permission for the use of 1197 such proprietary rights by implementers or users of this 1198 specification can be obtained from the IETF on-line IPR repository at 1199 http://www.ietf.org/ipr. 1201 The IETF invites any interested party to bring to its attention any 1202 copyrights, patents or patent applications, or other proprietary 1203 rights that may cover technology that may be required to implement 1204 this standard. Please address the information to the IETF at 1205 ietf-ipr@ietf.org. 1207 Disclaimer of Validity 1209 This document and the information contained herein are provided on an 1210 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1211 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1212 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1213 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1214 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1215 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1217 Copyright Statement 1219 Copyright (C) The Internet Society (2006). This document is subject 1220 to the rights, licenses and restrictions contained in BCP 78, and 1221 except as set forth therein, the authors retain all their rights. 1223 Acknowledgment 1225 Funding for the RFC Editor function is currently provided by the 1226 Internet Society.