[要約] RFC 4992は、インターネットレジストリ情報サービスのためのXMLパイプライン処理をチャンクで行う方法についての規格です。このRFCの目的は、大容量のデータを効率的に処理するためのXMLパイプライン処理の手法を提供することです。
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
インターネットレジストリ情報サービスのチャンク付き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）The IETF Trust（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.
このドキュメントでは、インターネットレジストリ情報サービス（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
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を送信するための簡単なフレーミングを定義します。このドキュメントは、チャンク（XPC）を使用したこのXMLパイプラインとIRIS-XPCとしてのIRISでの使用を呼び出しています。
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）を送信します。このリクエストでは、クライアントは、このリクエストへの応答に続いて、サーバーが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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 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]の規則に従って示されています。フィールド全体の左端ビットは最も重要なビットです。マルチオクテット数量が送信されると、最も重要なオクテットが最初に送信されます。オクテットのフラグを意味するビットには、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
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 当局の長さ - この要求ブロックの当局フィールドの長さ。
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 権限 - この要求が実行される権限を説明するオクテットの文字列。権限の定義と説明については、[1]を参照してください。この文字列のオクテットの数は、当局の長さによって指定された数値以上でなければなりません。
o chunks 1..n - the request data broken into chunks (Section 6).
o チャンク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.
サーバーがクライアントに応答するために使用されるブロックには2つのタイプがあります。最初のタイプは、セクション4.1で定義された応答ブロック（RSB）です。サーバーが要求ブロック（RQBS）に応答するために使用されます。2番目のタイプは、セクション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
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 チャンク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）。唯一の違いは、2つの方法のいずれかに制約されていることです。
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.2を参照）を含むチャンク（セクション6を参照）のみが含まれており、ブロックヘッダーのキープオープン（KO）フラグ（セクション5を参照）の値は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.4の「システムエラー」を参照）を含む1つのチャンク（セクション6を参照）のみが含まれ、ブロックヘッダーのキープオープン（KO）フラグ（セクション5を参照）の値は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:
各データブロックは、ブロックヘッダーと呼ばれる1オクセットヘッダーから始まります。このヘッダーには、リクエストデータブロックと応答データブロックの両方に対して同じ形式がありますが、ヘッダー内のビットの一部は、あるタイプのデータブロックでのみ意味があります。ビットは、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
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つのチャンクが必要です。各チャンクには、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は最も重要なビットです。Chunk Decruptor Octetのビットには、次の意味があります。
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-アプリケーションデータまたは「広告」タイプ（セクション6.8を参照）
+------------+---------------+----------+------------+
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）（タイプ110）が1つ以下ではありません。これらのチャンクを使用したセキュリティメカニズムのセットアップ中、クライアントは、認証の成功または失敗チャンクのいずれかを受け取るまで、後続の要求を送信してはなりません。
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.
ブロックには、上記のチャンクの少なくとも1つのタイプが必要です。
The format for a chunk is as follows:
チャンクの形式は次のとおりです。
+-----------+------------+--------+
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が含まれており、ルート要素として<バージョン>要素が必要です。
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 <アプリケーション> -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 [10]によって定義されたIANA SASLメカニズムレジストリに見られるSASLメカニズム名です。
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.
<tranferprotocol>要素の「requestsizeoctets」および「responseSizeoctets」属性のオクテットサイズは、セクション6.3で定義されています。
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>の「タイプ」属性の値は次のとおりです。
'block-error' - indicates there was an error decoding a block. Servers SHOULD send a block error in the following cases:
'block -error' - ブロックの解読エラーがあったことを示します。サーバーは、次の場合にブロックエラーを送信する必要があります。
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セッションがアイドル状態になった場合（つまり、データブロックが受信されましたが、データブロックの終了チャンクは受信されていません）。このタイムアウト値には2分をお勧めします。注意してください後者については、セクション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).
「Data -Error」 - アプリケーションまたは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.
'System -error' - このプロトコルに関連していない条件のために、受信者が要求を処理できないことを示します。サーバーは、リクエストに応答できますが、リクエストを処理できない場合にシステムエラーを送信する必要があります。
'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.
「Authority -Error」 - 対応する要求で指定された意図された権限が受信者によって提供されないことを示します。サーバーは、サービス以外の当局に向けられた要求を受け取ったときに、権限のエラーを送信する必要があります。
'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
SASL Authentication
SASL認証
These fields have the following meaning:
これらのフィールドには次の意味があります。
o mechanism name length - the length of the SASL mechanism name.
o メカニズム名の長さ - SASLメカニズム名の長さ。
o mechanism name - the name of the SASL mechanism as registered in the IANA SASL mechanism registry defined by [10].
o メカニズム名 - [10]で定義されたIANA SASLメカニズムレジストリに登録されているSASLメカニズムの名前。
o mechanism data length - the length of the SASL data.
o メカニズムデータの長さ - 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プロファイル名の長さを引いたマイナス1マイナス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メカニズムの初期チャレンジ応答として使用する場合、メカニズムデータの長さは65,535の小数値に設定して、初期応答がないことを示します。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>子要素を使用して、任意のバイナリデータをベース64バイナリとして渡すことができます。この要素がないことは、そのようなデータがないことを示しています。このデータでは、コンテンツのない要素の存在が空のデータセットを示します。
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.
これらのチャンクにはアプリケーションデータが含まれています。虹彩の場合、これらは虹彩[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. ブロックヘッダー（セクション5）にキープオープン（KO）フラグが0に設定された、キープオープン（KO）フラグを使用して、アイドルタイムアウトエラー（セクション6.4の「アイドルタイムアウト」を参照）を含む未承諾応答ブロックを送信します。
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を参照）を含むブロックエラーまたはデータエラー（セクション6.4を参照）を含む応答ブロックを送信します。。
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アプリケーションプロトコルラベルがあるが、両方ともバージョン情報チャンクで同じ<転送プロトコル>値で識別されることに注意する必要があります（セクション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のデフォルトトランスポートとして指定しています。TCPよく知られているポート登録は、セクション13.5で指定されています。
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の両方のエンコーディングを認識する義務があります。[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].
このスキームを使用したアプリケーション：虹彩で定義されています[1]。
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: defined in Section 14.
セキュリティ上の考慮事項：セクション14で定義されています。
Relevant Publications: IRIS [1].
関連する出版物：IRIS [1]。
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].
このスキームを使用したアプリケーション：虹彩で定義されています[1]。
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: defined in Section 14.
セキュリティ上の考慮事項：セクション14で定義されています。
Relevant Publications: IRIS [1].
関連する出版物：IRIS [1]。
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
相互運用性の考慮事項：n/a
Security Considerations: defined in Section 14.
セキュリティ上の考慮事項：セクション14で定義されています。
Relevant Publications: IRIS [1].
関連する出版物：IRIS [1]。
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.
相互運用性の考慮事項：n/aセキュリティに関する考慮事項：セクション14で定義されています。
Relevant Publications: IRIS [1].
関連する出版物：IRIS [1]。
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].
機能：虹彩で定義されています[1]。
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの使用：なし
Proposed Name: IRIS over XPC
提案された名前：XPCを介したIris
Short name: iris.xpc
短い名前：iris.xpc
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].
機能：虹彩で定義されています[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>
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_RSA_WITH_3DES_EDE_CBC_SHA CIPHEを使用したTLS -暗号化用。
o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates - for encryption and user authentication.
o TLS_RSA_WITH_3DES_EDE_CBC_SHAクライアント側の証明書を使用したTLS - 暗号化とユーザー認証のために。
o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for encryption. See [7].
o TLS_RSA_WITH_AES_128_CBC_SHA CIPHEを使用したTLS -暗号化用。[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_RSA_WITH_AES_128_CBC_SHAクライアント側の証明書を使用したTLS - 暗号化とユーザー認証のために。[7]を参照してください。
o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for encryption. See [7].
o TLS_RSA_WITH_AES_256_CBC_SHA CIPHEを使用したTLS -暗号化用。[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_RSA_WITH_AES_256_CBC_SHAクライアント側の証明書を使用したTLS - 暗号化とユーザー認証のために。[7]を参照してください。
Anonymous client access SHOULD be considered in one of two methods:
匿名のクライアントアクセスは、2つの方法のいずれかで考慮する必要があります。
1. When no authentication has been used.
1. 認証が使用されていない場合。
2. Using the SASL anonymous profile: SASL/ANONYMOUS
2. SASL匿名プロファイルの使用：SASL/匿名
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/プレーンメカニズムを使用してはなりません。クライアントは、TLS_RSA_WITH_3DES_EDE_CBC_SHA CIPHEを使用して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で指定されているように、SASLで使用するためのIRIS-XPCのコンプライアンスが詳述されています。
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内で使用される非空白認証IDINTING文字列は、RFC 4013 [11]に従って正規化する必要があります。空ではない認証Identity文字列のセマンティクスはサーバーに依存しており、クライアントは構成またはユーザーによって与えられたこれらの文字列の値を使用する必要があります。
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と組み合わせて使用されている場合、SASL認証の前にTLS認証が発生する必要があります。
[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：The Internet Registry Information Service（IRIS）Core Protocol」、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、「ブロック拡張可能な交換プロトコルを介してインターネットレジストリ情報サービスを使用」、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 Consortium、「Unicode Standard、バージョン3」、ISBN 0-201-61633-5、2000、<Unicode Standard、バージョン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、「The Transport Layer Security（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。and A. Newton、「SRV RRSおよびDynamic Deligation Discovery Service（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）：Generic Syntax」、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）ciphersuites」、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] ニュートン、A。、「インターネットレジストリ情報サービス転送プロトコルの一般的なスキーマ」、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、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[11] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[11] Zeilenga、K。、「SASLPREP：ユーザー名とパスワードのStringPrepプロファイル」、RFC 4013、2005年2月。
[12] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[12] Kirkpatrick、S.、Stahl、M。、およびM. Recker、「インターネット番号」、RFC 1166、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フラグメントを使用した16進表のオクテット値のいずれかが含まれます。コメントとXMLフラグメントを含むOctet値の両方を含む行はありません。コメントは括弧内に含まれています。
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.
次の例は、1つのXPCセッションで2つのリクエストを発行するIRISクライアントを示しています。最初のリクエストでは、クライアントは「embles.com」のステータス情報を要求しています。このリクエストとその応答は、1つのチャンクで転送されます。2番目のリクエストでは、クライアントは「Milo.example.com」、「Felix.example.com」、および「Hobbes.example.com」のステータス情報を要求しています。このリクエストとその応答は、3つのチャンクで転送されます。
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 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>
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>
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>
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クライアントは、1つのリクエストで「Milo.example.com」、「Felix.example.com」、および「Hobbes.example.com」のドメインステータス情報を要求します。リクエストは1つのチャンクで送信されます。ただし、答えは3つのチャンクで返されます。
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: 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: <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>
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/プレーン認証データを含むリクエストと「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>
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>
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の鮮明なワーキンググループ、特にロバート・マーティン・ラゲーン、ミレナ・ケア、デビッド・ブラッカのメンバーによって提供されています。
Author's Address
著者の連絡先
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew L. Newton Verisign、Inc。21345 Ridgetop Circle Sterling、VA 20166 USA
Phone: +1 703 948 3382
EMail: andy@hxr.us
URI: http://www.verisignlabs.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。