Network Working Group A. Newton
Request for Comments: 4992 VeriSign, Inc.
Updates: 3981 August 2007
Category: Standards Track
Network Working Group A. Newton
Request for Comments: 4992 VeriSign, Inc.
Updates: 3981 August 2007
Category: Standards Track
XML Pipelining with Chunks for the Internet Registry Information Service
用于Internet注册表信息服务的带块的XML管道
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining.
本文档描述了Internet注册表信息服务（IRIS）的简单TCP传输协议。使用数据块在客户端和服务器之间传输数据，以实现管道化。
Table of Contents
目录
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Request Block (RQB) .............................................4
4. Response Blocks .................................................4
4.1. Response Block (RSB) .......................................5
4.2. Connection Response Block (CRB) ............................5
5. Block Header ....................................................6
6. Chunks ..........................................................7
6.1. No Data Types ..............................................9
6.2. Version Information Types ..................................9
6.3. Size Information Types .....................................9
6.4. Other Information Types ...................................10
6.5. SASL Types ................................................11
6.6. Authentication Success Information Types ..................12
6.7. Authentication Failure Information Types ..................12
6.8. Application Data Types ....................................12
7. Idle Sessions ..................................................13
8. Closing Sessions Due to an Error ...............................13
9. Use over TLS ...................................................13
10. Update to RFC 3981 ............................................13
11. IRIS Transport Mapping Definitions ............................14
11.1. URI Scheme ...............................................14
11.2. Application Protocol Label ...............................14
12. Internationalization Considerations ...........................14
13. IANA Considerations ...........................................14
13.1. XPC URI Scheme Registration ..............................14
13.2. XPCS URI Scheme Registration .............................15
13.3. S-NAPTR XPC Registration .................................15
13.4. S-NAPTR XPCS Registration ................................15
13.5. Well-Known TCP Port Registration for XPC .................16
13.6. Well-Known TCP Port Registration for XPCS ................16
14. Security Considerations .......................................17
14.1. Security Mechanisms ......................................17
14.2. SASL Compliance ..........................................18
15. References ....................................................19
15.1. Normative References .....................................19
15.2. Informative References ...................................19
Appendix A. Examples ..............................................20
Appendix B. Contributors ..........................................28
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Request Block (RQB) .............................................4
4. Response Blocks .................................................4
4.1. Response Block (RSB) .......................................5
4.2. Connection Response Block (CRB) ............................5
5. Block Header ....................................................6
6. Chunks ..........................................................7
6.1. No Data Types ..............................................9
6.2. Version Information Types ..................................9
6.3. Size Information Types .....................................9
6.4. Other Information Types ...................................10
6.5. SASL Types ................................................11
6.6. Authentication Success Information Types ..................12
6.7. Authentication Failure Information Types ..................12
6.8. Application Data Types ....................................12
7. Idle Sessions ..................................................13
8. Closing Sessions Due to an Error ...............................13
9. Use over TLS ...................................................13
10. Update to RFC 3981 ............................................13
11. IRIS Transport Mapping Definitions ............................14
11.1. URI Scheme ...............................................14
11.2. Application Protocol Label ...............................14
12. Internationalization Considerations ...........................14
13. IANA Considerations ...........................................14
13.1. XPC URI Scheme Registration ..............................14
13.2. XPCS URI Scheme Registration .............................15
13.3. S-NAPTR XPC Registration .................................15
13.4. S-NAPTR XPCS Registration ................................15
13.5. Well-Known TCP Port Registration for XPC .................16
13.6. Well-Known TCP Port Registration for XPCS ................16
14. Security Considerations .......................................17
14.1. Security Mechanisms ......................................17
14.2. SASL Compliance ..........................................18
15. References ....................................................19
15.1. Normative References .....................................19
15.2. Informative References ...................................19
Appendix A. Examples ..............................................20
Appendix B. Contributors ..........................................28
Using S-NAPTR [5], IRIS has the ability to define the use of multiple application transports (or transfer protocols) for different types of registry services, all at the discretion of the server operator. The TCP transfer protocol defined in this document is completely modular and may be used by any registry types.
通过使用S-NAPTR[5]，IRIS能够为不同类型的注册表服务定义多个应用程序传输（或传输协议）的使用，所有这些都由服务器运营商自行决定。本文档中定义的TCP传输协议是完全模块化的，可由任何注册表类型使用。
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.
这个传输协议定义了简单的分块发送XML的框架，以便在接收整个XML实例之前对XML片段进行处理（或流水线处理）。本文档将此XML带块流水线（XPC）及其与IRIS的使用称为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.
XPC用于客户端和服务器之间的简单请求和响应交互。客户端以数据块的形式向服务器发送一系列请求。服务器将使用相应的数据块单独响应每个数据块，但通过相同的连接。请求和响应数据块使用TCP发送功能发送，使用TCP接收功能接收。
The lifecycle of an XPC session has the following phases:
XPC会话的生命周期有以下几个阶段：
1. A client establishes a TCP connection with a server.
1. 客户端与服务器建立TCP连接。
2. The server sends a connection response block (CRB).
2. 服务器发送连接响应块（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.
3. 客户端发送一个请求块（RQB）。在该请求中，客户机可以设置一个“keep open”标志，请求服务器在响应该请求后保持XPC会话打开。
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.
4. 服务器使用响应块（RSB）进行响应。在该响应中，服务器可以向客户端指示XPC会话是否将关闭。
5. If the XPC session is not to be terminated, then the lifecycle repeats from step 3.
5. 如果不终止XPC会话，则生命周期从步骤3开始重复。
6. The TCP connection is closed.
6. TCP连接已关闭。
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 RFC 2119 [8].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[8]中所述进行解释。
Octet fields with numeric values are given according to the conventions in RFC 1166 [12]: the leftmost bit of the whole field is the most significant bit; when a multi-octet quantity is transmitted
根据RFC 1166[12]中的约定给出具有数值的八位字段：整个字段最左边的位是最高有效位；当传输多个八位组数量时
the most significant octet is transmitted first. Bits signifying flags in an octet are numbered according to the conventions of RFC 1166 [12]: bit 0 is the most significant bit and bit 7 is the least significant bit. When a diagram describes a group of octets, the order of transmission for the octets starts from the left.
最重要的八位字节首先传输。表示八位字节中标志的位根据RFC 1166[12]的约定进行编号：位0为最高有效位，位7为最低有效位。当图表描述一组八位字节时，八位字节的传输顺序从左边开始。
The format for the request block (RQB) is as follows:
请求块（RQB）的格式如下：
+--------+-----------+-----------+-------------+
field | header | authority | authority | chunks 1..n |
| | length | | |
+--------+-----------+-----------+-------------+
octets 1 1 0..255 variable
+--------+-----------+-----------+-------------+
field | header | authority | authority | chunks 1..n |
| | length | | |
+--------+-----------+-----------+-------------+
octets 1 1 0..255 variable
Request Block
请求块
These fields have the following meanings:
这些字段具有以下含义：
o header - as described in Section 5.
o 标题-如第5节所述。
o authority length - the length of the authority field in this request block.
o authority length—此请求块中权限字段的长度。
o authority - a string of octets describing the authority against which 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 authority（权限）-描述要针对其执行此请求的权限的八进制字符串。有关权限的定义和说明，请参见[1]。此字符串中的八位字节数不得大于或小于权限长度指定的数字。
o chunks 1..n - the request data broken into chunks (Section 6).
o chunks 1..n—请求数据被分成块（第6节）。
There are two types of blocks used by a server to respond to a client. The first type is a response block (RSB) defined in Section 4.1. It is used by a server to respond to request blocks (RQBs). The second type is a specialized version of a response block called a connection response block (CRB) defined in Section 4.2. It is sent by a server to a client when a connection is established to initiate protocol negotiation. Conceptually, a CRB is a type of RQB; they share the same format, but a CRB is constrained in conveying only specific information and is only sent at the beginning of the session lifecycle.
服务器使用两种类型的块来响应客户端。第一种类型是第4.1节中定义的响应块（RSB）。服务器使用它来响应请求块（RQB）。第二种类型是第4.2节中定义的称为连接响应块（CRB）的响应块的专用版本。当建立连接以启动协议协商时，它由服务器发送到客户端。从概念上讲，CRB是RQB的一种类型；它们共享相同的格式，但CRB仅限于传输特定信息，并且仅在会话生命周期的开始时发送。
The format for the response block (RSB) is as follows:
响应块（RSB）的格式如下：
+--------+-------------+
field | header | chunks 1..n |
| | |
+--------+-------------+
octets 1 variable
+--------+-------------+
field | header | chunks 1..n |
| | |
+--------+-------------+
octets 1 variable
Response Block
响应块
These fields have the following meanings:
这些字段具有以下含义：
o header - as described in Section 5.
o 标题-如第5节所述。
o chunks 1..n - the response data broken into chunks (Section 6).
o chunks 1..n-分为块的响应数据（第6节）。
Servers SHOULD NOT send an RSB to a client until they have received the entire RQB. Servers that do begin sending an RSB before the reception of the entire RQB must consider that clients will not be expected to start processing the RSB until they have fully sent the RQB, and that the RSB may fill the client's TCP buffers.
服务器在收到整个RQB之前不应向客户端发送RSB。在接收到整个RQB之前，确实开始发送RSB的服务器必须考虑到在完全发送RQB之前，客户端不会被期望开始处理RSB，并且RSB可以填充客户端的TCP缓冲器。
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.1). The only difference is that it is constrained in one of two ways:
连接响应块（CRB）是服务器向客户机发送的响应块，以响应客户机启动会话。连接响应块的格式与响应块（RSB）相同（第4.1节）。唯一的区别是，它通过以下两种方式之一受到约束：
1. It contains only one chunk (see Section 6) containing version information (see Section 6.2) and the keep-open (KO) flag in the block header (see Section 5) has a value of 1 (meaning the connection is not closing). Servers MUST use this type of CRB to indicate service availability.
1. 它只包含一个包含版本信息的块（参见第6节）（参见第6.2节），块头（参见第5节）中的keep open（KO）标志的值为1（表示连接未关闭）。服务器必须使用这种类型的CRB来指示服务可用性。
2. It contains only one chunk (see Section 6) containing a system error (see 'system-error' under Section 6.4) and the keep-open (KO) flag in the block header (see Section 5) 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.
2. 它只包含一个包含系统错误的块（参见第6节）（参见第6.4节下的“系统错误”），并且块头（参见第5节）中的保持打开（KO）标志的值为0（表示服务器在发送CRB后将立即关闭连接）。当服务器可以接受连接但无法处理请求时，必须使用这种类型的CRB。
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. The bits are ordered according to the convention given in RFC 1166 [12], where bit 0 is the most significant bit and bit 7 is the least significant bit. Each bit in the block header has the following meaning:
每个数据块都以一个称为块头的八位字节头开始。该报头对于请求和响应数据块具有相同的格式，尽管报头中的某些位仅在一种类型的数据块中具有意义。位按照RFC 1166[12]中给出的约定进行排序，其中位0为最高有效位，位7为最低有效位。块头中的每个位具有以下含义：
o bits 0 and 1 - version (V field) - 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. If a server receives a request for a version it does not support, it SHOULD follow the behavior described in Section 8.
o 位0和1-版本（V字段）-如果0（两位均为零），则协议为本文档中定义的版本。否则，报头和块中的其余位可能被解释为另一个版本。如果服务器收到对其不支持的版本的请求，则应遵循第8节中描述的行为。
o bit 2 - keep open (KO flag) - This flag is used to request that a connection stay open by a client and to indicate that a connection will stay open by a server, depending on the type of block. In a request block (RQB): a value of 1 indicates that a client is requesting that the server not close the TCP session, and a value of 0 indicates the client will expect their server to close the TCP session immediately after sending the corresponding response. In a response block (RSB) or a connection response block (CRB): a value of 1 indicates that the server expects the client to keep the TCP session open for the server to receive another request, and a value of 0 indicates that the server expects the client to close the TCP session immediately following this block.
o 位2-保持打开（KO标志）-此标志用于请求客户端保持连接打开，并指示服务器保持连接打开，具体取决于块的类型。在请求块（RQB）中：值1表示客户端请求服务器不关闭TCP会话，值0表示客户端希望其服务器在发送相应响应后立即关闭TCP会话。在响应块（RSB）或连接响应块（CRB）中：值1表示服务器希望客户端保持TCP会话打开，以便服务器接收另一个请求，值0表示服务器希望客户端在该块之后立即关闭TCP会话。
o bits 3, 4, 5, 6, and 7 - reserved - These MUST be 0. If a server receives a request in which any of these bits is set to 1 and the server does not understand the purpose for the value, the server SHOULD follow the behavior described in Section 8.
o 位3、4、5、6和7-保留-它们必须为0。如果服务器收到一个请求，其中这些位中的任何一位被设置为1，并且服务器不了解该值的用途，则服务器应遵循第8节中描述的行为。
+---------+-----------+----------+
field | Version | Keep Open | reserved |
| (V) | (KO) | |
+---------+-----------+----------+
bits 0 and 1 2 3 - 7
+---------+-----------+----------+
field | Version | Keep Open | reserved |
| (V) | (KO) | |
+---------+-----------+----------+
bits 0 and 1 2 3 - 7
Block Header
块头
Request and response blocks break down the request and response XML data into chunks. Request and response blocks MUST always have a minimum of 1 chunk. Each chunk has a one-octet descriptor. The first bit of the descriptor determines if the chunk is the last chunk in the block.
请求和响应块将请求和响应XML数据分解为块。请求和响应块必须始终至少有1个块。每个块都有一个八位组描述符。描述符的第一位确定块是否是块中的最后一个块。
The bits of the chunk descriptor octet are ordered according to the convention given in RFC 1166 [12], where bit 0 is the most significant bit and bit 7 is the least significant bit. The bits of the chunk descriptor octet have the following meaning:
区块描述符八位字节的位根据RFC 1166[12]中给出的约定进行排序，其中位0为最高有效位，位7为最低有效位。区块描述符八位字节的位具有以下含义：
o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk in the block.
o 位0-最后一个块（LC标志）-如果为1，则此块是块中的最后一个块。
o bit 1 - data complete (DC flag) - If 1, the data in this chunk represents the end of the data for the chunk type given. If this bit is never set to 1 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 without signaling completion of the data, clients and servers MUST assume that the remaining data will not be sent in a remaining chunk.
o 位1-数据完成（DC标志）-如果为1，则此区块中的数据表示给定区块类型的数据结束。如果在块中相同类型的块的任何块描述符中，此位从未设置为1，则客户端和服务器不得假定数据将在另一个块中继续。如果块从一种类型的块转换到另一种类型的块，而不发出数据完成的信号，则客户端和服务器必须假定剩余数据不会在剩余块中发送。
o bits 2, 3, and 4 - reserved - These MUST be 0.
o 位2、3和4-保留-它们必须为0。
o bits 5, 6, and 7 - chunk type (CT field) - determines the type of data carried in the chunk. These are the binary values for the chunk types:
o 第5、6和7位-块类型（CT字段）-确定块中携带的数据类型。以下是区块类型的二进制值：
* 000 - no data or 'nd' type (see Section 6.1)
* 000-无数据或“nd”类型（见第6.1节）
* 001 - version information or 'vi' type (see Section 6.2)
* 001-版本信息或“vi”类型（见第6.2节）
* 010 - size information or 'si' type (see Section 6.3)
* 010-尺寸信息或“si”型（见第6.3节）
* 011 - other information or 'oi' type (see Section 6.4)
* 011-其他信息或“oi”类型（见第6.4节）
* 100 - SASL (Simple Authentication and Security Layer) data or 'sd' type (see Section 6.5)
* 100-SASL（简单认证和安全层）数据或“sd”类型（见第6.5节）
* 101 - authentication success information or 'as' type (see Section 6.6)
* 101-认证成功信息或“as”类型（见第6.6节）
* 110 - authentication failure information or 'af' type (see Section 6.7)
* 110-认证失败信息或“af”类型（见第6.7节）
* 111 - application data or 'ad' type (see Section 6.8)
* 111-应用数据或“ad”类型（见第6.8节）
+------------+---------------+----------+------------+
field | Last Chunk | Data Complete | reserved | Chunk Type |
| (LC) | (DC) | | (CT) |
+------------+---------------+----------+------------+
bits 0 1 2 - 4 5 - 7
+------------+---------------+----------+------------+
field | Last Chunk | Data Complete | reserved | Chunk Type |
| (LC) | (DC) | | (CT) |
+------------+---------------+----------+------------+
bits 0 1 2 - 4 5 - 7
Chunk Descriptor
块描述符
A block MAY have multiple types of chunks, but all chunks of the same type MUST be contiguous in a block and MUST be ordered in the block in the order in which their data is to be interpreted. Contiguous chunks must be 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. During the setup of security mechanisms using these chunks, clients MUST NOT send subsequent requests until they have received either an authentication success or failure chunk.
1. 与身份验证相关的块—SASL数据块（类型100）、身份验证成功信息块（类型101）或身份验证失败信息块（类型110），但不能超过一种类型。在使用这些区块设置安全机制期间，客户端在收到身份验证成功或失败区块之前，不得发送后续请求。
2. data chunks - either no data chunks (type 000) or application data chunks (type 111), but not both.
2. 数据块-没有数据块（类型000）或应用程序数据块（类型111），但不能两者都有。
3. information chunks - either version information (type 001) or other information (type 011), but not both.
3. 信息块-版本信息（类型001）或其他信息（类型011），但不是两者都有。
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
+-----------+------------+--------+
field | chunk | chunk data | chunk |
| descriptor| length | data |
+-----------+------------+--------+
octets 1 2 variable
chunk
大块
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.
o 区块描述符-如上所述。o区块数据长度-区块数据的长度。o区块数据-区块的数据。
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 6.4).
服务器和客户端必须忽略标记为“无数据”的块类型中的数据。这些类型的块不要求长度为零。客户端可能会向服务器发送“无数据”，服务器必须以相同类型的数据块或其他信息进行响应（第6.4节）。
Chunks of this type contain XML conformant to the schema specified in [9] and MUST have the <versions> element as the root element.
这种类型的块包含符合[9]中指定的模式的XML，并且必须将<versions>元素作为根元素。
In the context of IRIS-XPC, the protocol identifiers for these elements are as follows:
在IRIS-XPC的上下文中，这些元素的协议标识符如下所示：
o <transferProtocol> - the value "iris.xpc1" to indicate the protocol specified in this document.
o <transferProtocol>-值“iris.xpc1”表示本文档中指定的协议。
o <application> - the XML namespace identifier for IRIS [1].
o <application>-IRIS的XML命名空间标识符[1]。
o <dataModel> - the XML namespace identifier for IRIS registries.
o <dataModel>-IRIS注册表的XML命名空间标识符。
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 4422 [10].
在IRIS-XPC的上下文中，身份验证机制标识符是在RFC 4422定义的IANA SASL机制注册表中找到的SASL机制名称[10]。
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. This interchange allows a client to query the version information of a server.
客户端可以向服务器发送具有这种类型块的块。这些数据块的长度应该为零，服务器必须忽略其中的任何数据。当服务器接收到此类型的块时，它必须使用此类型的块进行响应。此交换允许客户端查询服务器的版本信息。
The octet sizes for the 'requestSizeOctets' and 'responseSizeOctets' attributes of the <tranferProtocol> element are defined in Section 6.3.
第6.3节定义了<TransferProtocol>元素的“requestSizeOctets”和“responseSizeOctets”属性的八位字节大小。
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <size> element as the root element.
这种类型的块包含符合RFC 4991[9]中指定的模式的XML，并且必须将<size>元素作为根元素。
Octet counts provided by this information are defined as the sum of the count of all chunk data of a particular chunk type. For instance, if an XML instance is broken up into chunks of 20, 30, and 40 octets, the octet count would be 90 (20 + 30 + 40).
此信息提供的八位字节计数定义为特定块类型的所有块数据的计数之和。例如，如果一个XML实例被分成20、30和40个八位字节的块，那么八位字节数将是90（20+30+40）。
Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received.
客户端不能发送这种类型的块，如果收到这种类型的块，服务器可以使用第8节中的过程关闭会话。
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <other> element as the root element.
这种类型的块包含符合RFC 4991[9]中指定的模式的XML，并且必须将<other>元素作为根元素。
The values for the 'type' attribute of <other> are as follows:
<other>的“type”属性的值如下所示：
'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.
1. 当接收到包含此类型块的请求块时。
2. When a request block is received containing authentication success (see Section 6.6) or authentication failure (see Section 6.7) information.
2. 当接收到包含认证成功（见第6.6节）或认证失败（见第6.7节）信息的请求块时。
3. When a request block is received containing size information (see Section 6.3).
3. 收到包含尺寸信息的请求块时（参见第6.3节）。
4. When reserved bits in the request block are 1.
4. 当请求块中的保留位为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 (i.e., a data block has been received but no terminating chunk for the data block has been received). Two minutes is RECOMMENDED for this timeout value. Note, there is a difference between an idle condition due to the incomplete reception of a data block and an idle condition between request/response transactions associated with keeping the session open. For the latter, see Section 7.
5. 当一个数据块尚未全部接收，并且TCP会话已空闲一段特定时间（即，已接收到一个数据块，但未接收到该数据块的终止数据块）时。建议此超时值为两分钟。注意，由于未完全接收数据块而导致的空闲状态和与保持会话打开相关联的请求/响应事务之间的空闲状态之间存在差异。后者见第7节。
'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).
“数据错误”-表示在分析包含应用程序或SASL数据的数据块时出错（例如，XML在应用程序数据中无效）。
'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 7. Note, there is a difference between an idle condition due to the incomplete reception of a data block and an idle condition between request/response transactions associated with keeping the session open. For the former, see 'block-error' above.
“空闲超时”-表示XPC会话空闲时间过长。第7节定义了该值的用法。注意，由于未完全接收数据块而导致的空闲状态和与保持会话打开相关联的请求/响应事务之间的空闲状态之间存在差异。对于前者，请参见上面的“块错误”。
Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received.
客户端不能发送这种类型的块，如果收到这种类型的块，服务器可以使用第8节中的过程关闭会话。
The SASL chunk type allows clients and servers to exchange SASL data.
SASL区块类型允许客户端和服务器交换SASL数据。
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
+-----------+-----------+-----------+-----------+
field | mechanism | mechanism | mechanism | mechanism |
| name | name | data | data |
| length | | length | |
+-----------+-----------+-----------+-----------+
octets 1 variable 2 variable
SASL Authentication
SASL认证
These fields have the following meaning:
这些字段具有以下含义：
o mechanism name length - the length of the SASL mechanism name.
o mechanism name length—SASL机制名称的长度。
o mechanism name - the name of the SASL mechanism as registered in the IANA SASL mechanism registry defined by [10].
o 机制名称-在IANA SASL机制注册表中注册的SASL机制名称，由[10]定义。
o mechanism data length - the length of the SASL data.
o mechanism data length—SASL数据的长度。
o mechanism data - the data used for SASL.
o 机制数据-用于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.
这些字段不能跨越多个块。因此，应该注意，SASL数据长度超过数据块长度减去SASL概要文件名称长度减去1是一个错误。
Depending on the nature of the SASL mechanism 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 success information (see Section 6.6) or authentication failure information (see Section 6.7).
根据所使用的SASL机制的性质，SASL数据从客户端发送到服务器，从服务器发送到客户端，可能需要多个请求/响应事务才能完成。但是，一旦SASL交换完成并且服务器可以确定身份验证状态，服务器必须发送身份验证成功信息（参见第6.6节）或身份验证失败信息（参见第6.7节）。
When used as an initial challenge response for SASL mechanisms that support such a feature, the mechanism data length may be set to a decimal value of 65,535 to indicate an absent initial response. A value of 0 indicates an empty initial response.
当用作支持此类功能的SASL机制的初始质询响应时，机制数据长度可设置为十进制值65535，以指示缺少初始响应。值0表示初始响应为空。
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <authenticationSuccess> element as the root element.
此类型的块包含符合RFC 4991[9]中指定的模式的XML，并且必须具有<authenticationSuccess>元素作为根元素。
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 6.4). The usage of this chunk type is defined in Section 6.5. A server MAY close down a session due to reception of this type of chunk using the procedure in Section 8.
这种类型的区块仅从服务器发送到客户端。如果客户端将其发送到服务器，这将导致块错误（请参阅第6.4节中的“块错误”）。第6.5节定义了该块类型的用法。服务器可以使用第8节中的过程，由于接收到这种类型的块而关闭会话。
SASL mechanisms may use the <data> child element to pass back arbitrary binary data as base 64 binary. The absence of this element indicates the absence of such data, where as the presence of the element with no content indicates an empty data set.
SASL机制可以使用<data>子元素将任意二进制数据作为base64二进制文件传回。缺少此元素表示缺少此类数据，而没有内容的元素表示空数据集。
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <authenticationFailure> element as the root element.
此类型的块包含符合RFC 4991[9]中指定的模式的XML，并且必须将<authenticationFailure>元素作为根元素。
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 6.4). The usage of this chunk type is defined in Section 6.5. A server MAY close down a session due to reception of this type of chunk using the procedure in Section 8.
这种类型的区块仅从服务器发送到客户端。如果客户端将其发送到服务器，这将导致块错误（请参阅第6.4节中的“块错误”）。第6.5节定义了该块类型的用法。服务器可以使用第8节中的过程，由于接收到这种类型的块而关闭会话。
These chunks contain application data. For IRIS, these are IRIS [1] XML instances.
这些块包含应用程序数据。对于IRIS，这些是IRIS[1]XML实例。
If a server needs to close a connection due to it being idle, it SHOULD do the following:
如果服务器因空闲而需要关闭连接，则应执行以下操作：
1. Send an unsolicited response block containing an idle timeout error (see 'idle-timeout' in Section 6.4) with the keep-open (KO) flag in the block header (Section 5) set to a value of 0.
1. 发送包含空闲超时错误（参见第6.4节中的“空闲超时”）的非请求响应块，块头（第5节）中的keep open（KO）标志设置为0。
2. Close the TCP connection.
2. 关闭TCP连接。
If a server is to close a session due to an error, it SHOULD do the following:
如果服务器由于错误而要关闭会话，则应执行以下操作：
1. Send a response block containing either a block-error or data-error (see Section 6.4) or version information (see Section 6.2) with the keep-open (KO) flag in the block header (Section 5) set to a value of 0.
1. 发送包含块错误或数据错误（见第6.4节）或版本信息（见第6.2节）的响应块，块头（第5节）中的keep open（KO）标志设置为0。
2. Close the TCP connection.
2. 关闭TCP连接。
XPC may be tunneled over TLS [4] by establishing a TLS session immediately after a TCP session is opened and before any blocks are sent. This type of session is known as XPCS.
XPC可以通过在TCP会话打开之后和发送任何块之前立即建立TLS会话，在TLS[4]上进行隧道传输。这种类型的会话称为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].
使用TLS时，必须建立一个约定，以允许客户端验证服务器的有效性。XPCS使用IRIS-BEEP[2]所述的相同约定。
TLS enables authentication and confidentiality.
TLS支持身份验证和机密性。
Implementers should note that while XPC and XPCS have separate URI scheme names and S-NAPTR application protocol labels, both are identified with the same <transferProtocol> value in version information chunks (see Section 6.2).
实现者应该注意，虽然XPC和XPC有单独的URI方案名称和S-NAPTR应用程序协议标签，但在版本信息块中，两者都用相同的<transferProtocol>值标识（参见第6.2节）。
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.
RFC 3981[1]（IRIS-CORE）第6.2节规定IRIS-BEEP[2]是IRIS的默认传输。本文档修订了RFC 3981，并指定IRIS-XPC作为IRIS的默认传输。第13.5节规定了TCP已知端口注册。
This section lists the definitions required by IRIS [1] for transport mappings.
本节列出了IRIS[1]对传输映射所需的定义。
See Section 13.1 and Section 13.2.
见第13.1节和第13.2节。
See Section 13.3 and Section 13.4.
见第13.3节和第13.4节。
XML processors are obliged to recognize both UTF-8 and UTF-16 [3] encodings. Use of the XML defined by [9] MUST NOT use any other character encodings other than UTF-8 or UTF-16.
XML处理器必须同时识别UTF-8和UTF-16[3]编码。使用[9]定义的XML不得使用UTF-8或UTF-16以外的任何其他字符编码。
URL scheme name: iris.xpc
URL方案名称：iris.xpc
Status: permanent
地位：永久
URL scheme syntax: defined in [1].
URL方案语法：在[1]中定义。
Character encoding considerations: as defined in RFC 3986 [6].
字符编码注意事项：如RFC 3986[6]中所定义。
Intended usage: identifies IRIS XML using chunks over TCP
预期用途：通过TCP使用块标识IRIS XML
Applications using this scheme: defined in IRIS [1].
使用此方案的应用程序：在IRIS[1]中定义。
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 14.
安全注意事项：定义见第14节。
Relevant Publications: IRIS [1].
相关出版物：IRIS[1]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
URL scheme name: iris.xpcs
URL方案名称：iris.xpcs
Status: permanent
地位：永久
URL scheme syntax: defined in [1].
URL方案语法：在[1]中定义。
Character encoding considerations: as defined in RFC 3986 [6].
字符编码注意事项：如RFC 3986[6]中所定义。
Intended usage: identifies IRIS XML using chunks over TLS
预期用途：通过TLS使用块标识IRIS XML
Applications using this scheme: defined in IRIS [1].
使用此方案的应用程序：在IRIS[1]中定义。
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 14.
安全注意事项：定义见第14节。
Relevant Publications: IRIS [1].
相关出版物：IRIS[1]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
Application Protocol Label (see [5]): iris.xpc
应用协议标签（见[5]）：iris.xpc
Intended usage: identifies an IRIS server using XPC
预期用途：使用XPC识别IRIS服务器
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 14.
安全注意事项：定义见第14节。
Relevant Publications: IRIS [1].
相关出版物：IRIS[1]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
Application Protocol Label (see [5]): iris.xpcs
应用程序协议标签（见[5]）：iris.xpcs
Intended usage: identifies an IRIS server using secure XPCS
预期用途：使用安全XPCS标识IRIS服务器
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: defined in Section 14.
安全注意事项：定义见第14节。
Relevant Publications: IRIS [1].
相关出版物：IRIS[1]。
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
Protocol Number: TCP
协议编号：TCP
TCP Port Number: 713
TCP端口号：713
Message Formats, Types, Opcodes, and Sequences: defined in Section 4.2, Section 3, and Section 4.1.
消息格式、类型、操作码和序列：在第4.2节、第3节和第4.1节中定义。
Functions: defined in IRIS [1].
功能：在IRIS[1]中定义。
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: IRIS over XPC
建议名称：IRIS over XPC
Short name: iris.xpc
简称：iris.xpc
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Protocol Number: TCP
协议编号：TCP
TCP Port Number: 714
TCP端口号：714
Message Formats, Types, Opcodes, and Sequences: defined in Sections 9, 4.2, 3, and 4.1.
消息格式、类型、操作码和序列：在第9、4.2、3和4.1节中定义。
Functions: defined in IRIS [1].
功能：在IRIS[1]中定义。
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: IRIS over XPCS
建议名称：基于XPCS的IRIS
Short name: iris.xpcs
简称：iris.xpcs
Contact Information: Andrew Newton <andy@hxr.us>
Contact Information: Andrew Newton <andy@hxr.us>
Implementers should be fully aware of the security considerations given by IRIS [1] and TLS [4]. With respect to server authentication with the use of TLS, see Section 6 of IRIS-BEEP [2].
实施者应充分了解IRIS[1]和TLS[4]给出的安全注意事项。关于使用TLS的服务器身份验证，请参阅IRIS-BEEP[2]第6节。
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/DIGEST-MD5-用于无需会话加密的用户身份验证。
o SASL/OTP - for user authentication without the need of session encryption.
o SASL/OTP-用于用户身份验证，无需会话加密。
o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for encryption.
o TLS使用TLS_RSA_和_3DES_EDE_CBC_SHA密码-用于加密。
o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates - for encryption and user authentication.
o TLS使用TLS_RSA_和_3DES_EDE_CBC_SHA密码以及客户端证书-用于加密和用户身份验证。
o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for encryption. See [7].
o TLS使用TLS_RSA_和_AES_128_CBC_SHA密码-用于加密。见[7]。
o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [7].
o TLS使用TLS_RSA_和_AES_128_CBC_SHA密码以及客户端证书-用于加密和用户身份验证。见[7]。
o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for encryption. See [7].
o TLS使用TLS_RSA_和_AES_256_CBC_SHA密码-用于加密。见[7]。
o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [7].
o TLS使用TLS_RSA_和_AES_256_CBC_SHA密码以及客户端证书-用于加密和用户身份验证。见[7]。
Anonymous client access SHOULD be considered in one of two methods:
应采用以下两种方法之一考虑匿名客户端访问：
1. When no authentication has been used.
1. 未使用身份验证时。
2. Using the SASL anonymous profile: SASL/ANONYMOUS
2. 使用SASL匿名配置文件：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). Clients MUST implement SASL/PLAIN and TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher.
按照SASL/PLAIN的规定，客户机在未首先加密TCP会话（例如，使用TLS）之前不得使用SASL/PLAIN机制。客户端必须使用TLS\u RSA\u和\u 3DES\u EDE\u CBC\u SHA密码实现SASL/PLAIN和TLS。
The following list details the compliance of IRIS-XPC for use with SASL, as specified by RFC 4422 [10], Section 4.
以下列表详细说明了按照RFC 4422[10]第4节的规定，IRIS-XPC与SASL一起使用的合规性。
1. The SASL service name to be used by IRIS-XPC is "iris-xpc".
1. IRIS-XPC使用的SASL服务名称为“IRIS XPC”。
2. Section 6.2 describes the negotiation facility used to determine the available security mechanisms. This facility may be used both before the initiation of SASL exchanges and after the installation of security mechanisms.
2. 第6.2节描述了用于确定可用安全机制的协商机制。该设施可在启动SASL交换之前和安装安全机制之后使用。
3.
3.
a) Section 6.5 describes the mechanism to initiate authentication exchanges.
a) 第6.5节描述了发起身份验证交换的机制。
b) Section 6.5 describes the mechanism to transfer server challenges and client responses.
b) 第6.5节描述了传输服务器挑战和客户端响应的机制。
c) Section 6.6 and Section 6.7 describe the mechanisms to indicate the outcome of an authentication exchange. Section 6.6 describes how additional data may be carried with this message.
c) 第6.6节和第6.7节描述了指示身份验证交换结果的机制。第6.6节描述了如何随此消息携带附加数据。
4. Non-empty authorization identity strings used within IRIS-XPC MUST be normalized according to RFC 4013 [11]. The semantics of the non-empty authorization identity strings is server dependent, and clients MUST use the values for these strings as given by configuration or the user.
4. IRIS-XPC中使用的非空授权标识字符串必须根据RFC 4013[11]进行规范化。非空授权标识字符串的语义依赖于服务器，客户端必须使用配置或用户给定的这些字符串的值。
5. Clients or servers wishing to abort an ongoing authentication exchange MUST close the connection.
5. 希望中止正在进行的身份验证交换的客户端或服务器必须关闭连接。
6. After new security layers are negotiated, they take effect on the first octet following the authentication success (as) (Section 6.6) chunk sent by the server and on the first octet sent after receipt of the authentication success (as) chunk sent by the client.
6. 协商新的安全层后，它们在服务器发送的身份验证成功（as）（第6.6节）区块之后的第一个八位组上生效，并在收到客户端发送的身份验证成功（as）区块之后发送的第一个八位组上生效。
7. IRIS-XPC can be used with both TLS and SASL. When used in combination, TLS MUST always be applied before any SASL mechanism.
7. IRIS-XPC可用于TLS和SASL。当组合使用时，TLS必须始终在任何SASL机制之前应用。
8. IRIS-XPC does not support multiple SASL authentications. However, if TLS is being used in combination with SASL, TLS authentication MUST occur before any SASL authentication.
8. IRIS-XPC不支持多个SASL身份验证。但是，如果TLS与SASL结合使用，则TLS身份验证必须在任何SASL身份验证之前进行。
[1] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[1] Newton，A.和M.Sanz，“IRIS：互联网注册信息服务（IRIS）核心协议”，RFC 3981，2005年1月。
[2] Newton, A. and M. Sanz, "Using the Internet Registry Information Service over the Blocks Extensible Exchange Protocol", RFC 3983, January 2005.
[2] Newton，A.和M.Sanz，“通过块可扩展交换协议使用Internet注册表信息服务”，RFC 3983，2005年1月。
[3] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[3] Unicode联盟，“Unicode标准，第3版”，ISBN 0-201-61633-52000，<Unicode标准，第3版>。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[4] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[5] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[5] Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[6] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[9] Newton, A., "A Common Schema for Internet Registry Information Service Transfer Protocols", RFC 4991, August 2007.
[9] Newton，A.，“Internet注册表信息服务传输协议的通用模式”，RFC 4991，2007年8月。
[10] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[10] Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC4422006年6月。
[11] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[11] Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC4013，2005年2月。
[12] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[12] Kirkpatrick，S.，Stahl，M.和M.Recker，“互联网号码”，RFC1166，1990年7月。
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 contains either 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 parentheses.
本节给出了IRIS-XPC会话的示例。以“C:”开头的行表示客户机发送到服务器的数据，以“S:”开头的行表示服务器发送到客户机的数据。在“C:”或“S:”之后，该行包含十六进制注释的八位字节值或XML片段。没有一行同时包含带注释的八位字节值和XML片段。注释包含在括号内。
It should also be noted that flag values of "yes" and "no" reflect binary values 1 and 0.
还应注意，“是”和“否”的标志值反映二进制值1和0。
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 transferred with one chunk. In the second request, the client is requesting status information for "milo.example.com", "felix.example.com", and "hobbes.example.com". This request and its response are transferred with three chunks.
下面的示例演示一个IRIS客户端在一个XPC会话中发出两个请求。在第一个请求中，客户端请求“example.com”的状态信息。此请求及其响应通过一个块传输。在第二个请求中，客户端请求“milo.example.com”、“felix.example.com”和“hobbes.example.com”的状态信息。此请求及其响应通过三个块传输。
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.xpc1"
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>
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.xpc1"
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)
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=yes,DC=yes,CT=ad)
C: 0x01 0x53 (chunk length=339)
C: (IRIS XML request)
C: (request block)
C: 0x20 (block header: V=0,KO=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=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>
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: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC7 (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>
S: (response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC7 (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)
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=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>
C: <lookupEntity
C: registryType="urn:ietf:params:xml:ns:dchk1"
C: entityClass="domain-name"
C: (request block)
C: 0x00 (block header: V=0,KO=no)
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=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>
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: 0x07 (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: 0xC7 (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>
C: entityName="milo.example.com" />
C: </searchSet>
C: (chunk 2)
C: 0x07 (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: 0xC7 (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)
S: (chunk 1)
S: 0x07 (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: 0x07 (LC=no,DC=no,CT=ad)
S: 0x01 0xA2 (chunk length=418)
S: (IRIS XML response)
S: (response block)
S: 0x00 (block header: V=0,KO=no)
S: (chunk 1)
S: 0x07 (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: 0x07 (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: 0xC7 (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>
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: 0xC7 (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>
Example 1
例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.
在下面的示例中，IRIS客户端在一个请求中请求“milo.example.com”、“felix.example.com”和“hobbes.example.com”的域状态信息。请求与一个块一起发送；但是，答案将分三个部分返回。
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.xpc1"
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>
S: <transferProtocol protocolId="iris.xpc1"
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)
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=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>
C: (request block)
C: 0x00 (block header: V=0,KO=no)
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=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)
S: (chunk 1)
S: 0x07 (LC=no,DC=no,CT=ad)
S: 0x01 0xDA (chunk length=474)
S: (IRIS XML response)
S: (response block)
S: 0x00 (block header: V=0,KO=no)
S: (chunk 1)
S: 0x07 (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: 0x07 (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: 0xC7 (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: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: 0x07 (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: 0xC7 (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>
S: </iris:resultSet>
S: </iris:response>
Example 2
例2
In the following example, an IRIS client sends a request containing SASL/PLAIN authentication data and a domain status check for "example.com". The server responds with authentication success information and the domain status of "example.com". Note that the client requests that the connection stay open for further requests, but the server does not honor this request.
在下面的示例中，IRIS客户端发送一个包含SASL/PLAIN身份验证数据和“example.com”域状态检查的请求。服务器响应身份验证成功信息和域状态“example.com”。请注意，客户端请求连接保持打开状态，以便进一步请求，但服务器不接受此请求。
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.xpc1"
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>
S: (connection response block)
S: 0x20 (block header: V=0,KO=yes)
S: (chunk 1)
S: 0xC1 (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S: (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.xpc1"
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)
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: 0x44 (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: 0x00 0x0A (sasl PLAIN data length=10)
C: (sasl PLAIN data: authcid="bob")
C: (sasl PLAIN data: authzid=NULL)
C: (sasl PLAIN data: password="kEw1")
C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31
C: (chunk 2)
C: (request block)
C: 0x00 (block header: V=0,KO=no)
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: 0x44 (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: 0x00 0x0A (sasl PLAIN data length=10)
C: (sasl PLAIN data: authcid="bob")
C: (sasl PLAIN data: authzid=NULL)
C: (sasl PLAIN data: password="kEw1")
C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31
C: (chunk 2)
C: 0xC7 (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>
C: 0xC7 (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)
S: (chunk 1)
S: 0x45 (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: 0xC7 (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>
S: (response block)
S: 0x00 (block header: V=0,KO=no)
S: (chunk 1)
S: 0x45 (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: 0xC7 (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>
Example 3
例3
Substantive contributions to this document have been provided by the members of the IETF's CRISP Working Group, especially Robert Martin-Legene, Milena Caires, and David Blacka.
IETF CRISP工作组成员，特别是Robert Martin Legene、Milena Caires和David Black，对本文件做出了实质性贡献。
Author's Address
作者地址
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew L.Newton VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345，邮编20166
Phone: +1 703 948 3382
EMail: andy@hxr.us
URI: http://www.verisignlabs.com/
Phone: +1 703 948 3382
EMail: andy@hxr.us
URI: http://www.verisignlabs.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。