[要約] RFC 4993は、インターネットレジストリ情報サービスのための軽量なUDP転送プロトコルに関するものです。このRFCの目的は、効率的で信頼性の高いデータ転送を提供することです。
Network Working Group A. Newton
Request for Comments: 4993 VeriSign, Inc.
Category: Standards Track August 2007
A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
インターネットレジストリ情報サービス向けの軽量UDP転送プロトコル
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 lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet.
このドキュメントでは、インターネットレジストリ情報サービス（IRIS）向けの軽量UDP転送プロトコルについて説明しています。この転送プロトコルは、リクエストと応答ごとに単一のパケットを使用し、オプションでパケットのコンテンツに圧縮を使用します。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Packet Format ...................................................4
3.1. Payload Descriptor .........................................4
3.1.1. Payload Request Descriptor ..........................4
3.1.2. Payload Response Descriptor .........................5
3.1.3. Payload Header ......................................6
3.1.4. Payload Types .......................................6
3.1.5. Version Information .................................7
3.1.6. Size Information ....................................8
3.1.7. Other Information ...................................8
4. Interactions ....................................................9
5. Internationalization Considerations ............................10
6. IRIS Transport Mapping Definitions .............................10
6.1. URI Scheme ................................................10
6.2. Application Protocol Label ................................10
7. IANA Considerations ............................................10
7.1. Registrations .............................................10
7.1.1. URI Scheme Registration ............................10
7.1.2. Well-known UDP Port Registration ...................11
7.1.3. S-NAPTR Registration ...............................11
8. Security Considerations ........................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Appendix A. Examples ..............................................14
Appendix B. Contributors ..........................................18
Using Straightforward Name Authority Pointers (S-NAPTR) [4], 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 UDP transfer protocol defined in this document is completely independent of the registry types for which it can carry data.
Starient Name Authority Pointers（S-NAPTR）[4]を使用して、IRISには、サーバーオペレーターの裁量で、さまざまなタイプのレジストリサービスに複数のアプリケーショントランスポートまたは転送プロトコルの使用を定義する機能があります。このドキュメントで定義されているUDP転送プロトコルは、データを運ぶことができるレジストリタイプとは完全に独立しています。
The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ (for IRIS Lightweight using Compression). Its message exchange pattern is simple: a client sends a request in one UDP packet, and a server responds with an answer in one UDP packet.
このUDP転送プロトコルのIRISへの結合は、IRIS-LWZと呼ばれます（圧縮を使用したIRIS軽量の場合）。メッセージ交換パターンは簡単です。クライアントは1つのUDPパケットでリクエストを送信し、サーバーは1つのUDPパケットで回答で応答します。
IRIS-LWZ packets are composed of two parts, a binary payload descriptor and a request/response transaction payload. The request/ response transaction payload may be compressed using the DEFLATE [1] algorithm.
IRIS-LWZパケットは、バイナリペイロード記述子とリクエスト/応答トランザクションペイロードの2つの部分で構成されています。要求/応答トランザクションペイロードは、DEFLATE [1]アルゴリズムを使用して圧縮される場合があります。
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 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [6]に記載されているように解釈される。
Octet fields with numeric values are given according to the conventions in RFC 1166 [10]: 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 [10]: 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 [10]の規則に従って示されています。フィールド全体の左端ビットは最も重要なビットです。マルチオクテット数量が送信されると、最も重要なオクテットが最初に送信されます。オクテットのフラグを意味するビットには、RFC 1166 [10]の規則に従って番号が付けられています。ビット0は最も重要なビットであり、ビット7は最も重要なビットです。図がオクテットのグループを説明すると、オクテットの伝送の順序が左から始まります。
The packet format for IRIS-LWZ is as follows:
IRIS-LWZのパケット形式は次のとおりです。
+------------+---------+
field | payload | payload |
| descriptor | |
+------------+---------+
octets 3 or 6..261* 0..n
* In request packets, the payload descriptor can vary in length from 6 to 261 octets (i.e., 6..261). In response packets, the payload descriptor is always 3 octets.
* リクエストパケットでは、ペイロード記述子の長さは6〜261オクテット（つまり、6..261）の長さを変えることができます。応答パケットでは、ペイロード記述子は常に3オクテットです。
IRIS-LWZ Packet
IRIS-LWZパケット
Each IRIS-LWZ query or response is contained in a single UDP packet. Servers MUST be prepared to accept packets as large as 4000 octets, and clients MUST NOT send packets larger than 4000 octets.
各IRIS-LWZクエリまたは応答は、単一のUDPパケットに含まれています。サーバーは、4000オクテットの大きなパケットを受け入れるように準備する必要があり、クライアントは4000オクテットを超えるパケットを送信してはなりません。
The payload descriptor has two different formats, one for a request and one for a response. However, each format shares a common 1-octet payload header described in Section 3.1.3.
ペイロード記述子には2つの異なる形式があります。1つはリクエスト用、もう1つは応答用です。ただし、各フォーマットは、セクション3.1.3で説明されている一般的な1オクテットのペイロードヘッダーを共有しています。
The payload descriptor for request packets varies from 6 to 261 octets in length and has the following format:
リクエストパケットのペイロード記述子の長さは6〜261オクテットで、次の形式があります。
+--------+-------------+----------+-----------+-----------+
field | header | transaction | maximum | authority | authority |
| | ID | response | length | |
| | | length | | |
+--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255
Request Payload Descriptor
ペイロード記述子をリクエストします
These fields have the following meanings:
これらのフィールドには次の意味があります。
o header - as described in Section 3.1.3.
o ヘッダー - セクション3.1.3で説明されています。
o transaction ID - a 16-bit value identifying the transaction. This value will be returned in the payload response descriptor (Section 3.1.2) and can be used by clients to match requests with responses. Clients SHOULD NOT use sequential values (see Section 8). Clients MUST NOT set all the bits in this value to 1 (i.e., use a value of 0xFFFF).
o トランザクションID-トランザクションを識別する16ビット値。この値はペイロード応答記述子（セクション3.1.2）で返され、クライアントがリクエストと応答を一致させるために使用できます。クライアントはシーケンシャル値を使用しないでください（セクション8を参照）。クライアントは、この値のすべてのビットを1に設定してはなりません（つまり、0xffffの値を使用してください）。
o maximum response length - the total length of the UDP packet (i.e., UDP header length + payload descriptor length + XML payload length) that should not be exceeded when responding to this request. If the server cannot provide a response that is equal to or less than this value, then it MUST respond with size information (Section 3.1.6).
o 最大応答長 - UDPパケットの全長（つまり、UDPヘッダー長ペイロード記述子長さXMLペイロード長）は、このリクエストに応答するときに超えてはなりません。サーバーがこの値以下の応答を提供できない場合、サイズ情報（セクション3.1.6）で応答する必要があります。
o authority length - the length of the authority field in this payload descriptor.
o 権限の長さ - このペイロード記述子の当局フィールドの長さ。
o authority - a string of octets describing the authority against which this request is to be executed. See [3] 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 権限 - この要求が実行される権限を説明するオクテットの文字列。権限の定義と説明については、[3]を参照してください。この文字列のオクテットの数は、当局の長さによって指定された数値以上でなければなりません。
The payload descriptor for response packets is always 3 octets and consists of a payload header (Section 3.1.3) and a transaction ID.
応答パケットのペイロード記述子は常に3オクテットで、ペイロードヘッダー（セクション3.1.3）とトランザクションIDで構成されています。
+--------+-------------+
field | header | transaction |
| | ID |
+--------+-------------+
octets 1 2
Payload Response Descriptor
ペイロード応答記述子
The purpose of the transaction ID is to allow clients to match requests to responses. A value of 0xFFFF is reserved for server use. The value of the transaction ID is as follows:
トランザクションIDの目的は、クライアントがリクエストを応答に一致させることを許可することです。0xffffの値は、サーバーの使用のために予約されています。トランザクションIDの値は次のとおりです。
1. If the transaction ID in the corresponding request could not be read due to truncation, servers MUST use a transaction ID with all bits set to 1 (i.e., a value of OxFFFF) and send a descriptor error (see Section 3.1.7).
1. 対応するリクエストのトランザクションIDを切り捨てのために読み取れなかった場合、サーバーはすべてのビットを1（つまり、OXFFFFの値）に設定したトランザクションIDを使用し、記述子エラーを送信する必要があります（セクション3.1.7を参照）。
2. If the transaction ID in the corresponding request is a value of 0xFFFF, servers MUST use a transaction ID of 0xFFFF and send a descriptor error (see Section 3.1.7).
2. 対応する要求のトランザクションIDが0xFFFFの値である場合、サーバーは0xFFFFのトランザクションIDを使用して記述子エラーを送信する必要があります（セクション3.1.7を参照）。
3. Otherwise, the transaction ID MUST be the value of the transaction ID of the corresponding request.
3. それ以外の場合、トランザクションIDは、対応するリクエストのトランザクションIDの値である必要があります。
The bits of the payload header are ordered according to RFC 1166 [10], where bit 0 is the most significant and bit 7 is the least significant. Each bit in the 1-octet payload header has the following meaning:
ペイロードヘッダーのビットは、RFC 1166 [10]に従って注文されます。ビット0は最も重要であり、ビット7は最も重要ではありません。1-OCTETペイロードヘッダーの各ビットには、次の意味があります。
o bits 0 and 1 - version number ('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 payload may be interpreted as another version.
o ビット0および1-バージョン番号（ 'V'フィールド） - 0（両方のビットがゼロの場合）の場合、プロトコルはこのドキュメントで定義されているバージョンです。それ以外の場合、ヘッダーとペイロードの残りの部分は別のバージョンとして解釈される場合があります。
o bit 2 - request/response flag ('RR' flag) - If 0, this packet is a request (Section 3.1.1) packet. If 1, this packet is a response (Section 3.1.2) packet.
o ビット2-リクエスト/応答フラグ（ 'rr'フラグ） - 0の場合、このパケットはリクエスト（セクション3.1.1）パケットです。1の場合、このパケットは応答（セクション3.1.2）パケットです。
o bits 3 - payload deflated ('PD' flag) - If 1, the payload is compressed using the DEFLATE [1] algorithm.
o ビット3-ペイロードデフレート（ 'PD'フラグ） - 1の場合、ペイロードはデフレート[1]アルゴリズムを使用して圧縮されます。
o bit 4 - deflate supported ('DS' flag) - If 1, the sender of this packet supports compression using the DEFLATE algorithm. When this bit is 0 in a request, the payload of the response MUST NOT be compressed with DEFLATE.
o ビット4 -DEFLATEサポート（ 'DS'フラグ）-1の場合、このパケットの送信者はDERLATEアルゴリズムを使用して圧縮をサポートします。リクエストでこのビットが0の場合、応答のペイロードをデフレートで圧縮してはなりません。
o bit 5 - reserved - This MUST be 0.
o ビット5-予約済み - これは0でなければなりません。
o bits 6 and 7 - The value of these bits indicates payload types (Section 3.1.4) ('PT' field).
o ビット6および7-これらのビットの値は、ペイロードタイプを示します（セクション3.1.4）（ 'PT'フィールド）。
A payload type indicates the type of content in the UDP packet following the payload descriptor. Some payload types have no meaning in request packets, and some payload types differ in meaning between requests and responses. Some payload types indicate an empty payload.
ペイロードタイプは、ペイロード記述子に続くUDPパケットのコンテンツのタイプを示します。一部のペイロードタイプには、リクエストパケットに意味がありません。また、一部のペイロードタイプは、リクエストと応答の意味が異なります。一部のペイロードタイプは、空のペイロードを示しています。
The payload type values in binary are as follows:
バイナリのペイロードタイプの値は次のとおりです。
00 - xml payload ('xml' type). The payload is either an IRIS-based XML request or an IRIS-based XML response.
00 -XMLペイロード（ 'XML'タイプ）。ペイロードは、IRISベースのXML要求またはIRISベースのXML応答のいずれかです。
01 - version info ('vi' type). In a request packet, this payload type indicates that the server is to respond with version information (Section 3.1.5), and that the payload is empty. In a response packet, this payload type indicates that the payload is version information (Section 3.1.5).
01-バージョン情報（ 'VI'タイプ）。リクエストパケットでは、このペイロードタイプは、サーバーがバージョン情報（セクション3.1.5）で応答すること、およびペイロードが空であることを示しています。応答パケットでは、このペイロードタイプは、ペイロードがバージョン情報であることを示しています（セクション3.1.5）。
10 - size info ('si' type). This payload type has no meaning in a request packet and is a descriptor error. In a response packet, this payload type indicates that the payload is size information (Section 3.1.6).
10-サイズ情報（ 'si'タイプ）。このペイロードタイプには、リクエストパケットには意味がなく、記述子エラーです。応答パケットでは、このペイロードタイプは、ペイロードがサイズ情報であることを示しています（セクション3.1.6）。
11 - other info ('oi' type). This payload type has no meaning in a request packet and is a descriptor error. In a response packet, this payload type indicates that the payload is other information (Section 3.1.7).
11-その他の情報（ 'oi'タイプ）。このペイロードタイプには、リクエストパケットには意味がなく、記述子エラーです。応答パケットでは、このペイロードタイプは、ペイロードが他の情報であることを示しています（セクション3.1.7）。
A payload type with version information ('vi') MUST be conformant to the XML defined in [8] and use the <versions> element as the root element.
バージョン情報（ 'VI'）を備えたペイロードタイプは、[8]で定義されているXMLに準拠し、<バージョン>要素をルート要素として使用する必要があります。
In the context of IRIS-LWZ, the protocol identifiers for these elements are as follows:
IRIS-LWZのコンテキストでは、これらの要素のプロトコル識別子は次のとおりです。
<transferProtocol> - the value "iris.lwz1" to indicate the protocol specified in this document.
<TransferProtoCol> -このドキュメントで指定されたプロトコルを示す値「IRIS.LWZ1」。
<application> - the XML namespace identifier for IRIS [3].
<アプリケーション> -IRISのXMLネームスペース識別子[3]。
<dataModel> - the XML namespace identifier for IRIS registries.
<DataModel> -IRISレジストリ用のXMLネームスペース識別子。
This document defines no extension identifiers and no authentication mechanism identifiers.
このドキュメントは、拡張識別子と認証メカニズム識別子を定義していません。
Servers SHOULD send version information in the following cases:
サーバーは、次の場合にバージョン情報を送信する必要があります。
1. In response to a version information request (i.e., the PT field is set to 'vi').
1. バージョン情報リクエストに応じて（つまり、PTフィールドは「VI」に設定されています）。
2. The version in a payload descriptor header does not match a version the server supports.
2. ペイロード記述子ヘッダーのバージョンは、サーバーがサポートするバージョンと一致しません。
3. The IRIS-based XML payload does not match a version the server supports.
3. IRISベースのXMLペイロードは、サーバーがサポートするバージョンと一致しません。
The protocols identified by the <transferProtocol> element MUST only indicate protocols running on the same socket as the sender of the corresponding response. In other words, while a server operator may also be running IRIS-XPC [9], this XML instance is only intended to describe version negotiation for IRIS-LWZ.
<TransferProtoCol>要素によって識別されるプロトコルは、対応する応答の送信者と同じソケットで実行されているプロトコルのみを示す必要があります。言い換えれば、サーバーオペレーターはIRIS-XPCを実行している可能性もありますが[9]、このXMLインスタンスはIRIS-LWZのバージョンネゴシエーションを記述することのみを目的としています。
The octet size for the 'requestSizeOctets' and 'responseSizeOctets' attributes of the <tranferProtocol> element are defined in Section 3.1.6.
<tranferprotocol>要素の「requestsizeoctets」および「ResponseSizeoctets」属性のオクテットサイズは、セクション3.1.6で定義されています。
A payload type with size information ('si') MUST be conformant to the XML defined in [8] and use the <size> element as the root element.
サイズ情報（ 'Si'）を備えたペイロードタイプは、[8]で定義されているXMLに準拠し、<size>要素をルート要素として使用する必要があります。
Octet counts provided by this information are defined as the total length of the UDP packet (i.e., UDP header length + payload descriptor length + XML payload length).
この情報によって提供されるオクテットカウントは、UDPパケットの全長（つまり、UDPヘッダー長ペイロード記述子長XMLペイロード長）として定義されます。
A payload type with other information ('oi') MUST be conformant to the XML defined in [8] and use the <other> element as the root element.
他の情報（「OI」）を使用したペイロードタイプ（[8]で定義されているXMLに準拠し、<other>要素をルート要素として使用する必要があります。
The values for the 'type' attribute of <other> are as follows:
<other>の「タイプ」属性の値は次のとおりです。
'descriptor-error' - indicates there was an error decoding the descriptor. Servers SHOULD send a descriptor error in the following cases:
「Decruptor -Error」 - 記述子のデコードがエラーがあったことを示します。サーバーは、次の場合に記述子エラーを送信する必要があります。
1. When a request is received with a payload type indicating size information (i.e., the PT field is 'si').
1. サイズ情報を示すペイロードタイプでリクエストを受信した場合（つまり、PTフィールドは「SI」です）。
2. When a request is received with a payload type indicating other information (i.e., the PT field is 'oi').
2. 他の情報を示すペイロードタイプでリクエストを受信した場合（つまり、PTフィールドは「OI」です）。
3. When a request is sent with a transaction ID of 0xFFFF (which is reserved for server use).
3. 0xffffのトランザクションIDでリクエストが送信される場合（サーバーの使用のために予約されています）。
4. When a request is received with an incomplete or truncated payload descriptor.
4. 不完全または切り捨てられたペイロード記述子でリクエストを受信した場合。
5. When reserved bits in the payload descriptor are set to values other than zero.
5. ペイロード記述子の予約ビットがゼロ以外の値に設定されている場合。
'payload-error' - indicates there was an error interpreting the payload. Servers MUST send a payload error if they receive XML (i.e., the PT field is set to 'xml') and the XML cannot be parsed.
「ペイロードエラー」 - ペイロードを解釈するエラーがあったことを示します。サーバーは、XMLを受信した場合（つまり、PTフィールドが「XML」に設定されている場合）、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」 - 対応する要求で指定された意図された権限が受信者によって提供されないことを示します。サーバーは、サービス以外の当局に向けられた要求を受け取ったときに、権限のエラーを送信する必要があります。
'no-inflation-support-error' - indicates that the receiver does not support payloads that have been compressed with DEFLATE [1]. Servers MUST send this error when they receive a request that has been compressed with DEFLATE but they do not support inflation.
「インフレなしサポートエラー」 - レシーバーがデフレートで圧縮されたペイロードをサポートしていないことを示します[1]。サーバーは、デフレートで圧縮されたがインフレをサポートしていないリクエストを受け取ったときに、このエラーを送信する必要があります。
The intent of IRIS-LWZ is to utilize UDP for IRIS requests and responses when UDP is appropriate. Not all IRIS requests and responses will be able to utilize UDP and may require the use of other transfer protocols (i.e., IRIS-XPC [9] and/or Blocks Extensible Exchange Protocol (BEEP)). The following strategy SHOULD be used:
IRIS-LWZの意図は、UDPが適切な場合、IRISリクエストと応答にUDPを利用することです。すべてのIRISリクエストと応答がUDPを利用できるわけではなく、他の転送プロトコル（つまり、IRIS-XPC [9]および/またはブロック拡張可能な交換プロトコル（BEEP））の使用が必要になる場合があります。次の戦略を使用する必要があります。
1. If a request requires authentication, confidentiality, or other security, use another transfer protocol. IRIS-XPC [9] is RECOMMENDED.
1. リクエストに認証、機密性、またはその他のセキュリティが必要な場合は、別の転送プロトコルを使用します。IRIS-XPC [9]が推奨されます。
2. The maximum packet size should be calculated as follows:
2. 最大パケットサイズは次のように計算する必要があります。
a. If the path MTU is unknown, the maximum packet size MUST be 1500 octets.
a. Path MTUが不明の場合、最大パケットサイズは1500オクテットでなければなりません。
b. If the path MTU is known, the maximum packet size MUST NOT exceed the path MTU and MUST NOT exceed 4000 octets.
b. PATH MTUがわかっている場合、最大パケットサイズはパスMTUを超えてはならず、4000オクテットを超えてはなりません。
3. If a request is less than or equal to the maximum packet size, send it uncompressed.
3. リクエストが最大パケットサイズよりも低い場合は、圧縮されていないことを送信します。
4. If a request can be compressed to a size less than or equal to the maximum packet size, send the request using compression. Otherwise, use another transfer protocol. In cases where another transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED.
4. リクエストを最大パケットサイズ以下のサイズに圧縮できる場合は、圧縮を使用してリクエストを送信します。それ以外の場合は、別の転送プロトコルを使用します。別の転送プロトコルが必要な場合、IRIS-XPC [9]が推奨されます。
5. If a request yields a size error, send the request with another transfer protocol. IRIS-XPC [9] is RECOMMENDED.
5. リクエストがサイズエラーを生成する場合は、別の転送プロトコルでリクエストを送信します。IRIS-XPC [9]が推奨されます。
For retransmission of requests considered to be unanswered, a client SHOULD retransmit using a timeout value initially set to 1 second. This timeout value SHOULD be doubled for every retransmission, and a client SHOULD NOT retransmit any request once the timeout value has reached 60 seconds.
未回答と見なされるリクエストの再送信のために、クライアントは最初に1秒に設定されたタイムアウト値を使用して再送信する必要があります。このタイムアウト値は、再送信ごとに2倍にする必要があります。クライアントは、タイムアウト値が60秒に達したら、リクエストを再送信しないでください。
Clients that use timeout values other than the recommendations above MUST allocate or have allocated dedicated network resources that will ensure fairness to other network packets and avoid network congestion.
上記の推奨事項以外のタイムアウト値を使用するクライアントは、他のネットワークパケットへの公平性を確保し、ネットワークの輻輳を回避する専用ネットワークリソースを割り当てるか、割り当てている必要があります。
Clients MUST NOT have more than one outstanding request (i.e., an unanswered request that has not timed out) at a time unless they allocate or have been allocated dedicated network bandwidth and resources reserved specifically for this purpose.
クライアントは、この目的のために特別に予約された専用のネットワーク帯域幅とリソースを割り当てたり割り当てられたりしない限り、一度に1つの未解決のリクエスト（つまり、タイミングを出していない未回答のリクエスト）を持っている必要はありません。
Finally, if a client intends multiple requests to the same server in a short amount of time, this protocol offers no real advantage over IRIS-XPC [9]. In such a case, IRIS-XPC is RECOMMENDED to be used as it would be similarly or more efficient and would offer greater response sizes and allow better security.
最後に、クライアントが短時間で同じサーバーへの複数のリクエストを意図している場合、このプロトコルはIRIS-XPCよりも実際の利点を提供しません[9]。このような場合、IRIS-XPCは、同様またはより効率的であり、より大きな応答サイズを提供し、セキュリティを向上させるため、使用することをお勧めします。
XML processors are obliged to recognize both UTF-8 and UTF-16 [2] encodings. Use of the XML defined by [8] MUST NOT use any other character encodings other than UTF-8 or UTF-16.
XMLプロセッサは、UTF-8とUTF-16 [2]の両方のエンコーディングを認識する義務があります。[8]で定義されたXMLの使用は、UTF-8またはUTF-16以外の他の文字エンコードを使用してはなりません。
This section lists the definitions required by IRIS [3] for transport mappings.
このセクションには、輸送マッピングにIRIS [3]が必要とする定義をリストします。
See Section 7.1.1.
セクション7.1.1を参照してください。
See Section 7.1.3.
セクション7.1.3を参照してください。
URL scheme name: iris.lwz
URLスキーム名：IRIS.LWZ
Status: permanent
ステータス：永続的
URL scheme syntax: defined in [3].
URLスキーム構文：[3]で定義されています。
Character encoding considerations: as defined in RFC 3986 [5].
考慮事項の文字エンコード：RFC 3986 [5]で定義されているように。
Intended usage: identifies an IRIS entity made available using XML over UDP
意図された使用法：XMLを使用してUDPを使用して利用可能になったIRISエンティティを識別します
Applications using this scheme: defined in IRIS [3].
このスキームを使用したアプリケーション：虹彩で定義されています[3]。
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: defined in Section 8.
セキュリティ上の考慮事項：セクション8で定義されています。
Relevant Publications: IRIS [3].
関連する出版物：IRIS [3]。
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
著者/変更コントローラー：IESG
Protocol Number: UDP
プロトコル番号：UDP
UDP Port Number: 715
UDPポート番号：715
Message Formats, Types, Opcodes, and Sequences: defined in Sections 3 and 3.1.
メッセージ形式、タイプ、オペコード、およびシーケンス：セクション3および3.1で定義されています。
Functions: defined in IRIS [3].
機能：虹彩で定義されています[3]。
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの使用：なし
Proposed Name: IRIS-LWZ
提案された名前：IRIS-LWZ
Short name: iris.lwz
短い名前：Iris.lwz
Contact Information: Andrew Newton <andy@hxr.us>
Application Protocol Label (see [4]): iris.lwz
アプリケーションプロトコルラベル（[4]を参照）：IRIS.LWZ
Intended usage: identifies an IRIS server using XML over UDP
意図された使用法：UDPを介してXMLを使用してIRISサーバーを識別します
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: defined in Section 8.
セキュリティ上の考慮事項：セクション8で定義されています。
Relevant Publications: IRIS [3].
関連する出版物：IRIS [3]。
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
IRIS-LWZ is intended for serving public data; it provides no in-band mechanisms for authentication or confidentiality. Any application with these needs must provide out-of-band mechanisms (e.g., IPsec), or use the IRIS transfer protocols that provide such capabilities, such as IRIS-XPC [9].
IRIS-LWZは、公開データの提供を目的としています。認証または機密性のための帯域内のメカニズムを提供しません。これらのニーズを備えたアプリケーションは、バンド外のメカニズム（IPSECなど）を提供するか、IRIS-XPCなどのそのような機能を提供するIRIS転送プロトコルを使用する必要があります[9]。
Due to this lack of security, it is possible for an attacker to alter IRIS-LWZ messages sent from the client to the server and from the server to the client. Such an attack can result in denying usage of an IRIS service or in supplying false information to end users and many other scenarios.
このセキュリティが不足しているため、攻撃者はクライアントからサーバーに送信され、サーバーからクライアントに送信されるIRIS-LWZメッセージを変更することができます。このような攻撃は、IRISサービスの使用を拒否したり、エンドユーザーや他の多くのシナリオに誤った情報を提供したりする可能性があります。
Because IRIS-LWZ is a UDP-based protocol, it is possible for servers using IRIS-LWZ to be used in a type of distributed denial-of-service attack known as a reflection attack. This type of attack affects other types of UDP-using protocols, such as DNS. Server operators should be prepared to apply the same methods used for mitigating reflection attacks with other protocols, such as DNS, when using IRIS-LWZ. All operators should follow the advice given in BCP 38 [7].
IRIS-LWZはUDPベースのプロトコルであるため、IRIS-LWZを使用するサーバーは、反射攻撃として知られる分散型サービス拒否攻撃で使用される可能性があります。このタイプの攻撃は、DNSなどの他のタイプのUDP使用プロトコルに影響します。サーバーオペレーターは、IRIS-LWZを使用する場合、DNSなどの他のプロトコルとの反射攻撃を緩和するために使用されるのと同じ方法を適用する準備をする必要があります。すべてのオペレーターは、BCP 38 [7]で与えられたアドバイスに従う必要があります。
IRIS-LWZ uses transaction IDs in the payload descriptors to better enable a client to match a response to a request. By randomizing the transaction IDs being used (i.e., not using sequential numbers), attackers flooding the network with a large amount of spoofed packets have a lesser chance of succeeding with the attack. This measure is not guaranteed to thwart any such attack. Client implementers MUST take appropriate measures when ignoring this advice.
IRIS-LWZは、ペイロード記述子のトランザクションIDを使用して、クライアントがリクエストに対する応答をよりよく一致させることができます。使用されているトランザクションIDをランダム化することにより（つまり、シーケンシャル番号を使用しない）、攻撃者はネットワークに大量のスプーフィングされたパケットであふれているため、攻撃で成功する可能性が低くなります。この尺度は、そのような攻撃を阻止することは保証されていません。クライアントの実装者は、このアドバイスを無視するときに適切な対策を講じる必要があります。
[1] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[1] Deutsch、P。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、1996年5月。
[2] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[2] Unicode Consortium、「Unicode Standard、バージョン3」、ISBN 0-201-61633-5、2000、<Unicode Standard、バージョン3>。
[3] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[3] Newton、A。およびM. Sanz、「Iris：The Internet Registry Information Service（IRIS）Core Protocol」、RFC 3981、2005年1月。
[4] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[4] Daigle、L。and A. Newton、「SRV RRSおよびDynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[8] Newton, A., "A Common Schema for Internet Registry Information Service Transfer Protocols", RFC 4991, August 2007.
[8] ニュートン、A。、「インターネットレジストリ情報サービス転送プロトコルの一般的なスキーマ」、RFC 4991、2007年8月。
[9] Newton, A., "XML Pipelining with Chunks for the Internet Registry Information Service", RFC 4992, August 2007.
[9] Newton、A。、「インターネットレジストリ情報サービスのチャンク付きXMLパイプライン」、RFC 4992、2007年8月。
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[10] Kirkpatrick、S.、Stahl、M。、およびM. Recker、「インターネット番号」、RFC 1166、1990年7月。
This section gives examples of IRIS-LWZ exchanges. 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-LWZ交換の例を示します。「c：」で始まる行は、クライアントからサーバーに送信されたデータを示し、「s」で始まる行は、サーバーから送信されたデータをクライアントに示します。「C：」または「S：」に続いて、線にはコメントまたはXMLフラグメントを使用した16進表のオクテット値のいずれかが含まれます。コメントとXMLフラグメントを含むOctet値の両方を含む行はありません。コメントは括弧内に含まれています。
The following example demonstrates an IRIS client requesting a lookup of 'AUP' in the 'local' entity class of a 'dreg1' registry. The client passes a bag (see [3]) with the search request. The server responds with a 'nameNotFound' response and an explanation.
次の例は、「DREG1」レジストリの「ローカル」エンティティクラスの「AUP」の検索を要求するIRISクライアントを示しています。クライアントは、検索リクエストでバッグ（[3]を参照）を渡します。サーバーは、「namenotfound」応答と説明で応答します。
C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9)
C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C: <searchSet>
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: <salt>127.0.0.1:3434</salt>
C: <md5>4LnQ1KdCahzyvwBqJis5rw==</md5>
C: </simpleBag>
C: </bag>
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer></iris:answer>
S: <iris:nameNotFound><iris:explanation language="en-US">
S: The name 'AUP' is not found in 'local'.</iris:explanation>
S: </iris:nameNotFound></iris:resultSet></iris:response>
Example 1
例1
The following example demonstrates an IRIS client requesting domain availability information for 'milo.example.com'. The server responds that the domain is assigned and active.
次の例は、「Milo.example.com」のドメインの可用性情報を要求するIRISクライアントを示しています。サーバーは、ドメインが割り当てられ、アクティブになっていることを応答します。
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x0B 0xE7 (transaction ID=3047)
C: 0x0F 0xA0 (maximum response size=4000)
C: 0x0B (authority length=11)
C: (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
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: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x0B 0xE7 (transaction ID=3047)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer><domain
S: authority="example.com" registryType="dchk1"
S: entityClass="domain-name" entityName="tcs-com-1"
S: temporaryReference="true"
S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
S: milo.example.com</domainName><status><assignedAndActive/>
S: </status></domain></iris:answer>
S: </iris:resultSet></iris:response>
Example 2
例2
The following example demonstrates an IRIS client requesting domain availability information for felix.example.net, hobbes.example.net, and daffy.example.net. The client does not support responses compressed with DEFLATE, and the maximum UDP packet it can safely receive is 498 octets. The server responds with size information indicating that it would take 1211 octets to provide an answer.
次の例は、felix.example.net、hobbes.example.net、およびdaffy.example.netのドメイン可用性情報を要求するIRISクライアントを示しています。クライアントは、デフレートで圧縮された応答をサポートせず、安全に受信できる最大のUDPパケットは498オクテットです。サーバーは、回答を提供するのに1211オクテットが必要であることを示すサイズ情報で応答します。
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x7E 0x8A (transaction ID=32394)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
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 iris1.xsd">
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="felix.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="hobbes.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="daffy.example.net" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si)
S: 0x7E 0x8A (transaction ID=32394)
S: (Size Information XML response)
S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <octets>1211</octets>
S: </responseSize>
Example 3
例3
The following example illustrates an IRIS client requesting the version information from a server, and the server returning the version information.
次の例は、サーバーからバージョン情報をリクエストするIRISクライアントと、バージョン情報を返すサーバーを示しています。
C: (request packet)
C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi)
C: 0x2E 0x9C (transaction ID=11932)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
S: (response packet)
S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi)
S: 0x2E 0x9C (transaction ID=11932)
S: (Version Information XML response)
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.lwz1">
S: <application protocolId="urn:ietf:params:xml:ns:iris1">
S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S: </application>
S: </transferProtocol>
S: </versions>
Example 4
例4
Substantive contributions to this document have been provided by the members of the IETF's CRISP Working Group, especially 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エディター機能の資金は現在、インターネット協会によって提供されています。