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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes a 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.
わかりやすい名前権限ポインタ（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.
IRISこのUDP転送プロトコルの結合は、（圧縮を使用してIRIS軽量用）IRIS-LWZと呼ばれています。そのメッセージ交換パターンは単純で、クライアントは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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
数値を持つオクテットフィールドは、[10] RFC 1166に規則に従って与えられている：全フィールドの左端のビットが最上位ビットです。マルチオクテット量を送信する際に最も重要なオクテットが最初に送信されます。オクテットのフラグを意味するビットが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.
The payload descriptor for request packets varies from 6 to 261
octets in length and has the following format:
+--------+-------------+----------+-----------+-----------+
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
OトランザクションID - トランザクションを識別する16ビット値。この値は、ペイロード応答記述（セクション3.1.2）に返され、との要求を一致させるためにクライアントが使用することができます
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).
反応。クライアントは、連続した値を使用すること（セクション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に設定されているすべてのビットとトランザクションIDを使用する（すなわち、OxFFFFの値）と記述誤りを送らなければなりません（セクション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:
ペイロードヘッダのビットは、ビット0が最上位ビット7は最下位であるRFC 1166 [10]、に従って順序付けられます。 1オクテットのペイロードヘッダの各ビットは、以下の意味を有します。
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.
バージョン番号（「V」フィールド） - - ビット0と1 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の場合、ペイロードはDEFLATE [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が - （「DS」フラグ）サポート収縮 - 1の場合、このパケットの送信者がDEFLATEアルゴリズムを使用して圧縮をサポートします。このビットはリクエスト0である場合、応答のペイロードはDEFLATEで圧縮してはいけません。
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).
ビット6と7 O - これらのビットの値は、ペイロードタイプ（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.
<データモデル> - 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.
「requestSizeOctets」と<tranferProtocol>要素の '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に準拠し、ルート要素として<サイズ>要素を使用しなければなりません。
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に準拠することと、ルート要素として<その他>要素を使用しなければなりません。
The values for the 'type' attribute of <other> are as follows:
次のように<その他>の「タイプ」属性の値は、次のとおりです。
'descriptor-error' - indicates there was an error decoding the descriptor. Servers SHOULD send a descriptor error in the following cases:
「記述子-エラー」 - 記述子をデコードエラーがあったことを示します。サーバーは、次の場合に記述エラーを送信する必要があります。
1. When a request is received with a payload type indicating size information (i.e., the PT field is 'si').
要求が（すなわち、PTフィールドは「SI」）とサイズ情報を示すペイロードタイプで受信される1。
2. When a request is received with a payload type indicating other information (i.e., the PT field is 'oi').
要求が（すなわち、PTフィールドが「OI」である）他の情報を表すペイロードタイプで受信される2。
3. When a request is sent with a transaction ID of 0xFFFF (which is reserved for server use).
要求が（サーバの使用のために予約される）0xFFFFでのトランザクションIDが送信される3。
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.
「ペイロードエラー」 - ペイロードを解釈誤りがあったことを示します。彼らは（すなわち、PTフィールドが「XML」に設定されている）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.
「システムエラー」 - 受信機は、このプロトコルに関連しない条件による要求を処理できないことを示しています。彼らは要求に応答することができるが、処理要求することができないとき、サーバーはシステム・エラーを送るべきです。
'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.
「権威-エラー」 - 対応する要求に指定された意図権限が受信機によって提供されていないことを示しています。彼らは、彼らが仕える以外の機関に向け、要求を受信したときにサーバーが権限エラーを送るべきです。
'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.
「非膨張サポートエラー」 - 受信機はDEFLATE [1]を用いて圧縮されたペイロードをサポートしていないことを示しています。彼らはDEFLATEで圧縮された要求を受信したときにサーバーは、このエラーを送らなければなりませんが、彼らはインフレをサポートしていません。
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]推奨されます。
a. If the path MTU is unknown, the maximum packet size MUST be
1500 octets.
b. If the path MTU is known, the maximum packet size MUST NOT exceed the path MTU and MUST NOT exceed 4000 octets.
B。パスMTUが知られている場合は、最大パケットサイズは、パスMTUを超えてはならないと4000個のオクテットを超えてはなりません。
3. If a request is less than or equal to the maximum packet size, send it uncompressed.
前記要求は、最大パケットサイズ以下である場合、それは圧縮されていない送信します。
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.
前記要求は、圧縮を使用して要求を送信し、より少ない又は最大パケットサイズに等しいサイズに圧縮することができる場合。そうでない場合は、別の転送プロトコルを使用します。別の転送プロトコルが必要とされる場合には、IRIS-XPC [9]推奨されます。
5. If a request yields a size error, send the request with another transfer protocol. IRIS-XPC [9] is RECOMMENDED.
前記要求が寸法誤差を生じた場合、別の転送プロトコルで要求を送信します。 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秒に設定されたタイムアウト値を使用して再送信します。このタイムアウト値は、すべての再送を倍増する必要があり、タイムアウト値が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.
彼らは割り当てるか、この目的のために特別に予約専用のネットワーク帯域幅とリソースを割り当てられている場合を除き、クライアントは、一度に複数の未処理の要求（タイムアウトしていない、すなわち、未回答の要求を）持ってはいけません。
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プロセッサは、[2]エンコードUTF-8およびUTF-16の両方を認識するように義務付けられています。定義されたXMLを使用すると、[8] 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
意図している用法：IRISエンティティはUDP上のXMLを使用して利用できるように識別します
Applications using this scheme: defined in IRIS [3].
この方式を使用したアプリケーション：IRIS [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>
お問い合わせ先：アンドリュー・ニュートン<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].
機能：IRIS [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>
お問い合わせ先：アンドリュー・ニュートン<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>
お問い合わせ先：アンドリュー・ニュートン<andy@hxr.us>
Author/Change controller: the IESG
著者/変更コントローラ：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]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン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規格、バージョン3"、ISBN 0-201-61633-5、2000年、<Unicode標準、バージョン3>。
[3] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[3]ニュートン、A.とM.サンス、 "IRIS：インターネットレジストリ情報サービス（IRIS）コアプロトコル"、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.及びA.ニュートン、2005年1月、RFC 3958 "ドメインベースのアプリケーションサービスロケーションSRV用のRRおよび動的委任ディスカバリサービス（DDDS）の使用"。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]ブラドナーのは、S.は、RFC 2119、BCP 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。
[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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、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]、RFC 4992ニュートン、A.、 "インターネットレジストリ情報サービスのためのチャンクを含むXMLパイプライン"、2007年8月。
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.
[10]カークパトリック、S.、スタール、M.、およびM.レッカー、 "インターネット番号"、RFC 1166、1990年7月。
Appendix A. Examples
付録A.例
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：」をサーバからクライアントに送信されたデータを示します。又は「S」：「C」以下、行はコメントやXMLフラグメントと16進数のいずれか含まオクテット値。何行はコメントとXMLフラグメントの両方のオクテット値が含まれていません。コメントは括弧内に含まれています。
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>
C：（要求パケット）C：0x08に（ヘッダ：V = 0、RR =要求、PD = NO、DS = YES、PT = XML）C：0x03の0xA4の（トランザクションID = 932）C：0x05の0xDA（最大応答サイズ= 1498）C：0x09の（権限長= 9）C：（権限= "ローカルホスト"）C：0x6c 0x6fは0x63の0x61 0x6c 0x68 0x6f 0x73 0x74 C：（IRIS XML要求）C <リクエストのxmlns = "URN：IETF： paramsは：XML：NS：iris1" C：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> C <searchSet> C <バッグ> C <simpleBagのxmlns = "HTTP ：//example.com/ "> C <塩> 127.0.0.1:3434 </塩> C <MD5> 4LnQ1KdCahzyvwBqJis5rw == </ MD5> C </ simpleBag> C </袋> C < lookupEntity C：registryType = "DREG1" C：entityClass = "ローカル" C：エンティティネーム= "AUP" /> C </ searchSet> C </リクエスト>
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>
S：（応答パケット）S：0x20の（ヘッダ：V = 0、RR =応答、PD =なし、DS =なし、PT = XML）S：0x03の0xA4の（トランザクションID = 932）S（IRIS XML応答）S ：<アイリス：レスポンスのxmlns：アイリス= "壷：IETF：のparams：XML：NS：iris1"> S：<アイリス：たresultSet> <アイリス：答え> </アイリス：答え> S：<アイリス：nameNotFound> <アイリス：説明言語= "EN-US"> S：説明> S：</アイリス：nameNotFound> </アイリス：たresultSet> </アイリス：レスポンス名 'AUPは' 'ローカル' </アイリスでは見られません>
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>
C：（要求パケット）C：0x00の（ヘッダ：V = 0、RR =要求、PD = NO、DS =なし、PT = XML）C：0x0Bの0xE7（トランザクションID = 3047）C：0x0Fの0xA0を（最大応答サイズ= 4000）C：0x0Bの（権限長= 11）C：（権限= "example.com"）C：0x65 0x78との0x61 0x6D 0x70 0x6C 0x65 0x23は0x63 0x6F 0x6D C：（IRIS XML要求）C <リクエストの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 = "壷：IETF：のparams：XML：NS：dchk1" C：entityClass = "ドメイン名" C：エンティティネーム=" マイロ。 example.com」/> C：</ searchSet> C：</リクエスト>
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>
S：（応答パケット）S：0x20の（ヘッダ：= 0 V、RR =応答、PD =なし、DS =なし、PT = XML）S：0x0Bの0xE7（トランザクションID = 3047）S：（IRIS XML応答）S ：<アイリス：レスポンスのxmlns：アイリス= "壷：IETF：のparams：XML：NS：iris1"> S：<アイリス：たresultSet> <アイリス：答え> <ドメインS：権限= "example.com" registryType = "dchk1 "S：entityClass =" ドメイン名」エンティティネーム= "TCS-COM-1" S：temporaryReference = "true" をS：のxmlns = "壷：IETF：のparams：XML：NS：dchk1"> <ドメイン名> S：マイロ.example.comと</ドメイン名> <状態> <assignedAndActive /> S：</ステータス> </ドメイン> </アイリス：答え> S：</アイリス：たresultSet> </アイリス：レスポンス>
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.
次の例では、IRISのfelix.example.net、hobbes.example.netのドメイン可用性情報を要求しているクライアント、およびdaffy.example.netを示しています。クライアントはDEFLATEで圧縮された応答をサポートしていない、それが安全に受信できる最大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>
C：（要求パケット）C：0x00の（ヘッダ：V = 0、RR =要求、PD = NO、DS =なし、PT = XML）C：0x7Eを0x8A（トランザクションID = 32394）C：0x01の0xF2（最大応答サイズ= 498）C：0x0Bの（権限長= 11）C：（権限= "example.net"）C：0x65 0x78との0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 C：（IRIS XML要求）C <リクエストの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 =" entityClass = "ドメイン名" C：エンティティネーム= "dchk1" felix.example.net" /> C：</ searchSet> C： <searchSet> C <lookupEntity registryType = "dchk1" entityClass = "ドメイン名" C：エンティティネーム= "hobbes.example.net" /> C </ searchSet> C <searchSet> C <lookupEntity registryType =」 dchk1" entityClass = "ドメイン名" C：エンティティネーム= "daffy.example.net" /> C：</ searchSet> C：</リクエスト>
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>
S：（応答パケット）S：ただし0x22（ヘッダ：V = 0、RR =応答、PD =なし、DS =なし、PT = SI）S：0x7Eを0x8A（トランザクションID = 32394）S：（サイズ情報XML応答） S：<responseSizeのxmlns = "壷：IETF：のparams：XML：NS：アイリス輸送"> S：<オクテット> 1211 </オクテット> 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
C：（要求パケット）C：0x01の（ヘッダ：V = 0、RR =要求、PD = NO、DS =なし、PT = VI）C：0x2E 0x9C（トランザクションID = 11932）C：0x01の0xF2（最大応答サイズ= 498）C：0x0Bの（権限長= 11）C：（権限= "example.net"）C：0x65 0x78との0x61 0x6D 0x70 0x6C 0x65 0x23 0x65 0x74 0x6E
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>
S：（応答パケット）S：0x21で（ヘッダ：V = 0、RR =応答、PD =なし、DS =なし、PT = VI）S：0x2E 0x9C（トランザクションID = 11932）S：（バージョン情報XML応答） S：<バージョンのxmlns = "URN：IETF：paramsは：XML：NS：虹彩輸送"> S <transferProtocol protocolId = "iris.lwz1"> S <アプリケーションprotocolId = "URN：IETF：paramsは：XML：NS ：iris1 "> S <データモデルprotocolId =" URN：IETF：paramsは：XML：NS：dchk1 "/> S <データモデルprotocolId =" URN：IETF：paramsは：XML：NS：DREG1" /> S </アプリケーション> S：</ transferProtocol> S：</バージョン>
Example 4
例4
Appendix B. Contributors
付録B.協力者
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のCRISPワーキンググループのメンバー、特にミレーナCairesとDavid Blackaによって提供されています。
Author's Address
著者のアドレス
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
アンドリュー・L.ニュートンベリサイン社21345 Ridgetopサークルスターリング、VA 20166 USA
Phone: +1 703 948 3382 EMail: andy@hxr.us URI: http://www.verisignlabs.com/
電話：+1 703 948 3382 Eメール：andy@hxr.us URI：http://www.verisignlabs.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。