Network Working Group A. Newton Internet-Draft VeriSign, Inc. Updates: 3981 (if approved) April 29, 2005 Expires: October 31, 2005 XML Pipelining with Chunks for the Information Registry Information Service draft-ietf-crisp-iris-xpc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 31, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a simple TCP transport binding for the Internet Registry Information Service (IRIS). Newton Expires October 31, 2005 [Page 1]
Internet-Draft iris-xpc April 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 3. Request Block . . . . . . . . . . . . . . . . . . . . . . . 5 4. Response Block . . . . . . . . . . . . . . . . . . . . . . . 6 5. Connection Response Block . . . . . . . . . . . . . . . . . 7 6. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 10 7.2 Version Information Types . . . . . . . . . . . . . . . . 10 7.3 Other Information Types . . . . . . . . . . . . . . . . . 11 7.4 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 12 7.5 Authentication Succss Information Types . . . . . . . . . 13 7.6 Authentication Failure Information Types . . . . . . . . . 13 7.7 Application Data Types . . . . . . . . . . . . . . . . . . 13 8. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . 14 9. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . 16 11. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 17 11.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 17 11.2 Application Protocol Label . . . . . . . . . . . . . . . 17 12. Internationalization Considerations . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 13.1 XPC URI Scheme Registration . . . . . . . . . . . . . . 19 13.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . 19 13.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . 20 13.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . 20 13.5 Well-known TCP Port Registration . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . 21 15. Normative References . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 32 Newton Expires October 31, 2005 [Page 2]
Internet-Draft iris-xpc April 2005 1. Introduction Using S-NAPTR [6], IRIS has the ability to define the use of multiple application transports (or transfer protocols) for different types of registry services, all at the descretion of the server operator. The TCP transfer protocol defined in this document is completely modular and may be used by any registry types. This transfer protocol defines simple framing for sending XML in chunks so that XML fragments may be acted upon (or pipelined) before the reception of the entire XML instance. This document calls this XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. XPC is for use with simple request and response interactions between clients and servers. Clients send a series of requests to a server in data blocks. The server will respond to each data block individually with a corresponding data block, but through the same connection. Request and response data blocks are sent using the TCP SEND function and received using the TCP RECEIVE function. The lifecycle of an XPC session has the following phases: 1. A client establishes a TCP connection with a server. 2. The server sends a connection response block (CRB). 3. The client sends a request block (RQB). In this request, the client can set a "keep open" flag requesting that the server keep the XPC session open following the response to this request. 4. The server responds with a response block (RSB). In this response, the server can indicate to the client whether or not the XPC session will be closed using a "connection closing" flag. 5. If the XPC session is not to be terminated, then the lifecycle repeats from step 3. 6. The TCP connection is closed. Newton Expires October 31, 2005 [Page 3]
Internet-Draft iris-xpc April 2005 2. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [9]. Newton Expires October 31, 2005 [Page 4]
Internet-Draft iris-xpc April 2005 3. Request Block The format for the request block (RQB) is as follows: +--------+-----------+-----------+-------------+ field | header | authority | authority | chunks 1..n | | | length | | | +--------+-----------+-----------+-------------+ octets 1 1 0..255 variable These fields have the following meanings: o header - as described in Section 6. o authority length - the length of the authority field in this request block. o authority - a string of octets describing the authority against wich this request is to be executed. See [1] for the definition and description of an authority. The number of octets in this string MUST be no more and no less than the number specified by the authority length. o chunks 1..n - the request data broken into chunks (Section 7). Newton Expires October 31, 2005 [Page 5]
Internet-Draft iris-xpc April 2005 4. Response Block The format for the response block (RSB) is as follows: +--------+-------------+ field | header | chunks 1..n | | | | +--------+-------------+ octets 1 variable These fields have the following meanings: o header - as described in Section 6. o chunks 1..n - the response data broken into chunks (Section 7). Newton Expires October 31, 2005 [Page 6]
Internet-Draft iris-xpc April 2005 5. Connection Response Block A connection response block (CRB) is a response block sent by a server to a client in response to the client initiating a session. A connection response block has the same format as a response block (RSB) (Section 4). The only difference is that it is constrained in one of two ways: 1. It contains only one chunk (see Section 7) containing version information (see Section 7.2) and the connection closing bit in the block header (see Section 6) has a value of 1 (meaning the connection is not closing). Servers MUST use this type of CRB to indicate service availability. 2. It contains only one chunk (see Section 7) containing a system error (see 'system-error' under Section 7.3) and the connection closing bit in the block header (see Section 6) has a value of 0 (meaning the server will close the connection immediately after sending the CRB). Servers MUST use this type of CRB when they can accept connections but cannot process requests. Newton Expires October 31, 2005 [Page 7]
Internet-Draft iris-xpc April 2005 6. Block Header Each data block starts with a one octet header called the block header. This header has the same format for both request and response data blocks, though some of the bits in the header only have meaning in one type of data block. Each bit in the block header has the following meaning: o bits 7 and 6 - version (V flag) - If 0 (both bits are zero), the protocol is the version defined in this document. Otherwise, the rest of the bits in the header and the block may be interpreted as another version. o bits 5 - keep open (KO flag)- If 1, the client is requesting the server not to close the TCP session. If 0, the client should expect the server to close the TCP session immediately after sending the corresponding response. This bit only has context in request blocks. o bit 4 - connection closing (CC flag)- If 0, the server will close the TCP session immediately following this block. This bit only has meaning in a response block. It MUST be 0 in a request block. o bit 3, 2, 1, and 0 - reserved - These MUST be 0. Newton Expires October 31, 2005 [Page 8]
Internet-Draft iris-xpc April 2005 7. Chunks Request and response blocks break the request and response XML data down into chunks. Request and response blocks MUST always have a minimum of 1 chunk. Each chunk has a one octet descriptor, and the first bit of the desciptor determines if a chunk is the last chunk. The bits of the chunk descriptor octet have the following meaning: o bit 7 - last chunk (LC flag) - If 0, this chuck is the last chunk in the block. o bit 6 - data completion (DC flag) - If 0, the data in this chunk represents the end of the data for the chunk type given. If this bit is never set to 0 in any chunk descriptor for chunks of the same type in a block, clients and servers MUST NOT assume the data will continue in another block. If the block transitions from one type of chunk to another with out signaling completion of the data, clients and servers MUST assume that the remaining data will not be sent in a remaining chunk. o bits 5, 4, and 3 - reserved - These MUST be 0. o bit 2, 1, and 0 - chunk type (CT flag) - determines the type of data carried in the chunk. These are the binary values for the chunk types: * 000 - no data or 'nd' type (see Section 7.1) * 001 - version information or 'vi' type (see Section 7.2) * 010 - reserved * 011 - other information or 'oi type (see Section 7.3) * 100 - SASL data or 'sd' type (see Section 7.4) * 101 - authentication success information or 'as' type (see Section 7.5) * 110 - authentication failure information or 'af' type (see Section 7.6) * 111 - application data or 'ad' type (see Section 7.7) A block MAY have multiple types of chunks, but all chunks of the same type MUST be contingous in a block and MUST be ordered in the block in the order in which their data is to be intepretted. Contiguous Newton Expires October 31, 2005 [Page 9]
Internet-Draft iris-xpc April 2005 chunks must by ordered by type within a block in the following way: 1. authentication related chunks - either SASL data chunks (type 100), authentication success information chunks (type 101) or authentication failure information chunks (type 110), but not more than one type 2. data chunks - either no data chunks (type 000) or application data chunks (type 111), but not both. 3. information chunks - either version information (type 001) or other information (type 011), but not both. A block MUST have at least one type of the above chunks. The format for a chunk is as follows: +-----------+------------+--------+ field | chunk | chunk data | chunk | | descriptor| length | data | +-----------+------------+--------+ octets 1 2 variable These fields have the following meanings: o chunk descriptor - as described above. o chunk data length - the length of the data of the chunk o chunk data - the data of the chunk 7.1 No Data Types Servers and clients MUST ignore data in chunk types labeled no data. There is no requirement for these types of chunks to be zero length. A client MAY send "no data" to a server, and the server MUST respond with either a chunk of the same type or other information (Section 7.3). 7.2 Version Information Types Chunks of this type contain XML conformant to the schema specified in [10] and MUST have the <versions> element as the root element. In the context of IRIS-XPC, the protocol identifiers for these elements are as follows: Newton Expires October 31, 2005 [Page 10]
Internet-Draft iris-xpc April 2005 o <transferProtocol> - the value "iris.xpc1" to indicate the protocol specified in this document. o <application> - the XML namespace identifier for IRIS [1]. o <dataModel> - the XML namespace identifier for IRIS registries. In the context of IRIS-XPC, the authentication mechanism identifiers are the SASL mechanism names found in the IANA SASL mechanism registry defined by RFC 2222 [4]. This document defines no extension identifiers. Clients MAY send a block with this type of chunk to a server. These chunks SHOULD be zero length and servers MUST ignore any data in them. When a server receives a chunk of this type, it MUST respond with a chunk of this type. 7.3 Other Information Types Chunks of this type contain XML conformant to the schema specified in IRIS-COMMON [10] and MUST have the <other> element as the root element. The values for the 'type' attribute of <other> are as follows: 'block-error' - indicates there was an error decoding a block. Servers SHOULD send a block error in the following cases: 1. When a request block is received containing a chunk of this type. 2. When a request block is received containing authentication success (see Section 7.5) or authentication failure (see Section 7.6) information. 3. When the connection-closing bit in the block header of a request block is 1. 4. When reserved bits in the request block are 1. 5. When a block has not been received in its entirety and the TCP session has been idle for a specific period of time. Two minutes is RECOMMENDED for this timeout value. 'data-error' - indicates there was an error parsing data in chunks containing application or SASL data (e.g. XML is not valid in application data). Newton Expires October 31, 2005 [Page 11]
Internet-Draft iris-xpc April 2005 'system-error' - indicates that the receiver cannot process the request due to a condition not related to this protocol. Servers SHOULD send a system-error when they are capable of responding to requests but not capable of processing requests. 'authority-error' - indicates that the intended authority specified in the corresponding request is not served by the receiver. Servers SHOULD send an authority error when they receive a request directed to an authority other than those they serve. 'idle-timeout' - indicates that an XPC session has been idle for too long. Usage of this value is defined in Section 8. 7.4 SASL Types The SASL chunk type allows clients and servers to exchange SASL data. The format for the data of this type of chunk is as follows: +-----------+-----------+-----------+-----------+ field | mechanism | mechanism | mechanism | mechanism | | name | name | data | data | | length | | length | | +-----------+-----------+-----------+-----------+ octets 1 variable 2 variable These fields have the following meaning: o mechanism name length - the length of the SASL mechanism name o mechanism - the name of the SASL mechanism as registered in the IANA SASL mechanism registry defined by [4]. o mechanism data length - the length of the SASL data o mechanism data - the data used for SASL These fields MUST NOT span multiple chunks. Therefore it should be noted that SASL data length exceeding the length of the chunk minus the length of SASL profile name minus one is an error. Depending on the nature of the SASL mechansim being used, SASL data is sent from clients to servers and from servers to clients and may require multiple request/response transactions to complete. However, once a SASL exchange is complete and a server can determine authentication status, the server MUST send either authentication Newton Expires October 31, 2005 [Page 12]
Internet-Draft iris-xpc April 2005 success information (see Section 7.5) or authentication failure information (see Section 7.6). 7.5 Authentication Succss Information Types Chunks of this type contain XML conformant to the schema specified in IRIS-COMMON [10] and MUST have the <authenticationSuccess> element as the root element. This type of chunk is only sent from a server to a client. If a client sends it to a server, this will result in a block error (see 'block-error' in Section 7.3). The usage of this chunk type is defined in Section 7.4. 7.6 Authentication Failure Information Types Chunks of this type contain XML conformant to the schema specified in IRIS-COMMON [10] and MUST have the <authenticationFailure> element as the root element. This type of chunk is only sent from a server to a client. If a client sends it to a server, this will result in a block error (see 'block-error' in Section 7.3). The usage of this chunk type is defined in Section 7.4. 7.7 Application Data Types These chunks contain application data. For IRIS, these are IRIS [1] XML instances. Newton Expires October 31, 2005 [Page 13]
Internet-Draft iris-xpc April 2005 8. Idle Sessions An XPC session may become idle between request/response transactions. This can occur when a server honors a client's request to keep the TCP connection running (see the keep-open and connection-closing bits in the block header (Section 6)). Servers are not expected to allow XPC sessions be idle between requests indefinitely. Clients MUST send no less than 1 request every 2 minutes. This can be any type of request specified by this document. If a client has no need to send a specific type of request but must send a request to fulfill this obligation, sending a request block containing one chunk of "no data" (see Section 7.1) with a length of zero is RECOMMENDED. If a server has not received a request block 5 minutes after sending a response block (either RSB or CRB), it SHOULD do the following: 1. Send an unsolicited response block containing an idle timeout error (see 'idle-timeout' in Section 7.3) with the connection- closing bit in the block header (Section 6) set to a value of 0. 2. Close the TCP connection. Newton Expires October 31, 2005 [Page 14]
Internet-Draft iris-xpc April 2005 9. Use over TLS XPC may be tunneled over TLS [5] by establishing a TLS session immediately after a TCP session is opened and before any blocks are to be sent. This type of session is known as XPCS. When using TLS, a convention must be established to allow a client to authenticate the validity of a server. XPCS uses the same convention as described by IRIS-BEEP [2]. Newton Expires October 31, 2005 [Page 15]
Internet-Draft iris-xpc April 2005 10. Update to RFC 3981 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is the default transport for IRIS. This document revises RFC 3981 and specifies IRIS-XPC as the default transport for IRIS. The TCP well- known port registration is specified in Section 13.5. Newton Expires October 31, 2005 [Page 16]
Internet-Draft iris-xpc April 2005 11. IRIS Transport Mapping Definitions This section lists the definitions required by IRIS [1] for transport mappings. 11.1 URI Scheme See Section 13.1 and Section 13.2. 11.2 Application Protocol Label See Section 13.3 and Section 13.4. Newton Expires October 31, 2005 [Page 17]
Internet-Draft iris-xpc April 2005 12. Internationalization Considerations XML processors are obliged to recognize both UTF-8 and UTF-16 [3] encodings. Use of the XML defined by [10] MUST NOT use any other character encodings other than UTF-8 or UTF-16. Newton Expires October 31, 2005 [Page 18]
Internet-Draft iris-xpc April 2005 13. IANA Considerations 13.1 XPC URI Scheme Registration URL scheme name: iris.xpc URL scheme syntax: defined in [1]. Character encoding considerations: as defined in RFC2396 [7]. Intended usage: identifies IRIS XML using chunks over TCP Applications using this scheme: defined in IRIS [1]. Interoperability considerations: n/a Security Considerations: defined in Section 14. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton <andy@hxr.us> Author/Change controller: the IESG 13.2 XPCS URI Scheme Registration URL scheme name: iris.xpcs URL scheme syntax: defined in [1]. Character encoding considerations: as defined in RFC2396 [7]. Intended usage: identifies IRIS XML using chunks over TLS Applications using this scheme: defined in IRIS [1]. Interoperability considerations: n/a Security Considerations: defined in Section 14. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton <andy@hxr.us> Author/Change controller: the IESG Newton Expires October 31, 2005 [Page 19]
Internet-Draft iris-xpc April 2005 13.3 S-NAPTR XPC Registration Application Protocol Label (see [6]): iris.xpc Intended usage: identifies an IRIS server using XPC Interoperability considerations: n/a Security Considerations: defined in Section 14. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton <andy@hxr.us> Author/Change controller: the IESG 13.4 S-NAPTR XPCS Registration Application Protocol Label (see [6]): iris.xpcs Intended usage: identifies an IRIS server using secure XPCS Interoperability considerations: n/a Security Considerations: defined in Section 14. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton <andy@hxr.us> Author/Change controller: the IESG 13.5 Well-known TCP Port Registration Protocol Number: TCP Message Formats, Types, Opcodes, and Sequences: defined in Section 5, Section 3, and Section 4. Functions: defined in IRIS [1]. Use of Broadcast/Multicast: none Proposed Name: IRIS over XPC Short name: iris.xpc Contact Information: Andrew Newton <andy@hxr.us> Newton Expires October 31, 2005 [Page 20]
Internet-Draft iris-xpc April 2005 14. Security Considerations Implementers should be fully aware of the security considerations given by IRIS [1] and TLS [5]. With respect to server authentication with the use of TLS, see Section 6 of IRIS-BEEP [2]. Clients SHOULD be prepared to use the following security mechanisms in the following manner: o SASL/DIGEST-MD5 - for user authentication without the need of session encryption. o SASL/OTP - for user authentication without the need of session encryption. o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for encryption. o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- side certificates - for encryption and user authentication. o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for encryption. See [8]. o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [8]. o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for encryption. See [8]. o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [8]. Anonymous client access SHOULD be considered in one of two methods: 1. When no authentication has been used. 2. Using the SASL anonymous profile: SASL/ANONYMOUS As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN mechanism without first encrypting the TCP session (e.g. such as with TLS). 15. Normative References [1] Newton, A. and M. Sanz, "Internet Registry Information Service", RFC 3891, January 2004. Newton Expires October 31, 2005 [Page 21]
Internet-Draft iris-xpc April 2005 [2] Newton, A. and M. Sanz, "Using the Internet Registry Information Service over the Blocks Extensible Exchange Protocol", RFC 3893, January 2004. [3] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>. [4] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [10] Newton, A., "A Common Schema for Internet Registry Information Service Transfer Protocols", draft-ietf-crips-iris-common-transport-00 (work in progress), April 2005. Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 Email: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/ Newton Expires October 31, 2005 [Page 22]
Internet-Draft iris-xpc April 2005 Appendix A. Examples This section gives examples of IRIS-XPC sessions. Lines beginning with "C:" denote data sent by the client to the server, and lines beginning with "S:" denote data sent by the server to the client. Following the "C:" or "S:", the line either contains octet values in hexadecimal notation with comments or XML fragments. No line contains both octet values with comments and XML fragments. Comments are contained within parenthesis. It should also be noted that flag values of "yes" and "no" do not reflect binary values 1 and 0. Instead they represent the associated positive or negative assertion of the meaning of the flag. For instance, for the connection-closing or CC flag to have a value of 0 means that the connection is closing, thus CC=yes. The following example demonstrates an IRIS client issuing two requests in one XPC session. In the first request, the client is requesting status information for "example.com". This request and its response are transfered with one chunk. In the second request, the client is requesting status information for "milo.example.com", "felix.example.com", and "hobbes.exmaple.com". This request and its response are transfered with three chunks. S: (connection response block) S: 0x10 (block header: V=0,KO=no,CC=no) S: (chunk 1) S: 0x01 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBE (chunk length=446) S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <transferProtocol protocolId="iris.lwz" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions> C: (request block) C: 0x20 (block header: V=0,KO=yes,CC=yes) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) Newton Expires October 31, 2005 [Page 23]
Internet-Draft iris-xpc April 2005 C: 0x07 (LC=yes,DC=yes,CT=ad) C: 0x01 0x53 (chunk length=339) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="example.com" /> C: </searchSet> C: </request> S: (response block) S: 0x10 (block header: V=0,KO=no,CC=no) S: (chunk 1) S: 0x07 (LC=yes,DC=yes,CT=ad) S: 0x01 0xE0 (chunk length=480) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response> C: (request block) C: 0x00 (block header: V=0,KO=no,CC=yes) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0xC7 (LC=no,DC=no,CT=ad) C: 0x01 0x4E (chunk length=339) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> Newton Expires October 31, 2005 [Page 24]
Internet-Draft iris-xpc April 2005 C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="milo.example.com" /> C: </searchSet> C: (chunk 2) C: 0xC7 (LC=no,DC=no,CT=ad) C: 0x00 0xA9 (chunk length=169) C: (IRIS XML request) C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="felix.example.com" /> C: </searchSet> C: (chunk 3) C: 0x07 (LC=yes,DC=yes,CT=ad) C: 0x00 0xB5 (chunk length=181) C: (IRIS XML request) C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="hobbes.example.com" /> C: </searchSet> C:</request> S: (response block) S: 0x00 (block header: V=0,KO=no,CC=yes) S: (chunk 1) S: 0xC7 (LC=no,DC=no,CT=ad) S: 0x01 0xDA (chunk length=474) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="milo.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>milo.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 2) Newton Expires October 31, 2005 [Page 25]
Internet-Draft iris-xpc April 2005 S: 0xC7 (LC=no,DC=no,CT=ad) S: 0x01 0xA2 (chunk length=418) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="felix.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>felix.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 3) S: 0x07 (LC=yes,DC=yes,CT=ad) S: 0x01 0xB5 (chunk length=437) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" S: entityName="hobbes.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>hobbes.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response> Figure 5: Example 1 In the following example, an IRIS client requests domain status information for "milo.example.com", "felix.example.com", and "hobbes.example.com" in one request. The request is sent with one chunk, however the answer is returned in three chunks. S: (connection response block) S: 0x10 (block header: V=0,KO=no,CC=no) S: (chunk 1) S: 0x01 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBE (chunk length=446) Newton Expires October 31, 2005 [Page 26]
Internet-Draft iris-xpc April 2005 S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <transferProtocol protocolId="iris.lwz" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions> C: (request block) C: 0x00 (block header: V=0,KO=no,CC=yes) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0x07 (LC=yes,DC=yes,CT=ad) C: 0x02 0xAB (chunk length=683) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="milo.example.com" /> C: </searchSet> C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="felix.example.com" /> C: </searchSet> C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="hobbes.example.com" /> C: </searchSet> C: </request> S: (response block) S: 0x00 (block header: V=0,KO=no,CC=yes) S: (chunk 1) Newton Expires October 31, 2005 [Page 27]
Internet-Draft iris-xpc April 2005 S: 0xC7 (LC=no,DC=no,CT=ad) S: 0x01 0xDA (chunk length=474) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="milo.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>milo.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 2) S: 0xC7 (LC=no,DC=no,CT=ad) S: 0x01 0xA2 (chunk length=418) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="felix.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>felix.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 3) S: 0x07 (LC=yes,DC=yes,CT=ad) S: 0x01 0xB5 (chunk length=437) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" S: entityName="hobbes.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>hobbes.example.com</domainName> S: <status> S: <assignedAndActive/> Newton Expires October 31, 2005 [Page 28]
Internet-Draft iris-xpc April 2005 S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response> Figure 6: Example 2 In the following example, an IRIS client sends a request containg SASL/PLAIN authentication data and a domain status check for "example.com". The server responds with authentication succss information and the domain status of "example.com". Note that the client requests that the connection stay open for further requests, but that the server does not honor this request. S: (connection response block) S: 0x10 (block header: V=0,KO=no,CC=no) S: (chunk 1) S: 0x01 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBE (chunk length=446) S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <transferProtocol protocolId="iris.lwz" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions> C: (request block) C: 0x20 (block header: V=0,KO=yes,CC=yes) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0x84 (LC=no,DC=yes,CT=sd) C: 0x00 0x11 (chunk length=11) C: (SASL data) C: 0x05 (mechanism length=5) C: (mechanism name="PLAIN") C: 0x50 0x4C 0x41 0x49 0x43 C: 0x0A (sasl PLAIN data length=10) C: (sasl PLAIN data: authcid="bob") C: (sasl PLAIN data: authzid=NULL) Newton Expires October 31, 2005 [Page 29]
Internet-Draft iris-xpc April 2005 C: (sasl PLAIN data: password="kEw1") C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 C: (chunk 2) C: 0x07 (LC=yes,DC=yes,CT=ad) C: 0x01 0x53 (chunk length=339) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="example.com" /> C: </searchSet> C: </request> S: (response block) S: 0x00 (block header: V=0,KO=no,CC=yes) S: (chunk 1) S: 0x85 (LC=no,DC=yes,CT=as) S: 0x00 0xD0 (chunk length=208) S: (authentication success response) S: <?xml version="1.0"?> S: <authenticationSuccess S: xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <description language="en"> S: user 'bob' authenticates via password S: </description> S: </authenticationSuccess> S: (chunk 2) S: 0x07 (LC=yes,DC=yes,CT=ad) S: 0x01 0xE0 (chunk length=480) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response> Newton Expires October 31, 2005 [Page 30]
Internet-Draft iris-xpc April 2005 Figure 7: Example 3 Newton Expires October 31, 2005 [Page 31]
Internet-Draft iris-xpc April 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Newton Expires October 31, 2005 [Page 32]
