RFC4993 日本語訳
4993 A Lightweight UDP Transfer Protocol for the Internet RegistryInformation Service. A. Newton. August 2007. (Format: TXT=34383 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Newton Request for Comments: 4993 VeriSign, Inc. Category: Standards Track August 2007
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 4993年のベリサインInc.カテゴリ: 標準化過程2007年8月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはインターネットRegistry情報Service(IRIS)のために軽量のUDP転送プロトコルについて説明します。 この転送プロトコルは、あらゆる要求と応答に単一のパケットを使用して、パケットのコンテンツの上で任意に圧縮を使います。
Newton Standards Track [Page 1] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[1ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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
1. 序論…3 2. 用語を記録してください…3 3. パケット形式…4 3.1. 有効搭載量記述子…4 3.1.1. 有効搭載量要求記述子…4 3.1.2. 有効搭載量応答記述子…5 3.1.3. 有効搭載量ヘッダー…6 3.1.4. 有効搭載量タイプ…6 3.1.5. バージョン情報…7 3.1.6. サイズ情報…8 3.1.7. 他の情報…8 4. 相互作用…9 5. 国際化問題…10 6. 定義を写像する虹彩輸送…10 6.1. URI体系…10 6.2. アプリケーション・プロトコルラベル…10 7. IANA問題…10 7.1. 登録証明書…10 7.1.1. URI体系登録…10 7.1.2. よく知られるUDPは登録を移植します…11 7.1.3. S-NAPTR登録…11 8. セキュリティ問題…12 9. 参照…13 9.1. 標準の参照…13 9.2. 有益な参照…13 付録A.の例…14 付録B.貢献者…18
Newton Standards Track [Page 2] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[2ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
1. Introduction
1. 序論
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.
IRISには、Straightforward Name Authority Pointers(S-NAPTR)[4]を使用して、複数のアプリケーション輸送の使用を定義するか、または異なったタイプの登録サービスのためにプロトコルを移す能力があります、サーバオペレータの裁量で。 本書では定義された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-LWZ(Compressionを使用している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つの部品、2進のペイロード記述子、および要求/応答トランザクションペイロードで構成されます。 要求/応答トランザクションペイロードは、DEFLATE[1]アルゴリズムを使用することで圧縮されるかもしれません。
2. Document Terminology
2. ドキュメント用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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.
RFC1166[10]のコンベンションに応じて、数値がある八重奏野原を与えます: 全体の分野の一番左ビットは最も重要なビットです。 マルチ八重奏量が伝えられるとき、最も重要な八重奏は最初に、伝えられます。 RFC1166[10]のコンベンションによると、八重奏で旗を意味するビットが付番されます: ビット0は最も重要なビットです、そして、ビット7は最下位ビットです。 ダイヤグラムが八重奏のグループについて説明するとき、八重奏のためのトランスミッションの注文は左から始めます。
Newton Standards Track [Page 3] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[3ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
3. Packet Format
3. パケット・フォーマット
The packet format for IRIS-LWZ is as follows:
IRIS-LWZのためのパケット・フォーマットは以下の通りです:
+------------+---------+
field | payload | payload |
| descriptor | |
+------------+---------+
octets 3 or 6..261* 0..n
+------------+---------+ 分野| ペイロード| ペイロード| | 記述子| | +------------+---------+ 八重奏3か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
虹彩-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の八重奏より大きいパケットを送ってはいけません。
3.1. Payload Descriptor
3.1. 有効搭載量記述子
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つがあります。 しかしながら、各形式はセクション3.1.3で説明された一般的な1八重奏のペイロードヘッダーを共有します。
3.1.1. Payload Request Descriptor
3.1.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
+--------+-------------+----------+-----------+-----------+ 分野| ヘッダー| トランザクション| 最大| 権威| 権威| | | ID| 応答| 長さ| | | | | 長さ| | | +--------+-------------+----------+-----------+-----------+ 八重奏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)で返して、要求に合っているクライアントは使用できます。
Newton Standards Track [Page 4] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[4ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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).
応答。 クライアントSHOULD NOTは連続した値を使用します(セクション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]を見てください。 このストリングの八重奏の数は、より多いはずがありません、そして、権威の長さに従って、少なくとも数は指定しました。
3.1.2. Payload Response Descriptor
3.1.2. 有効搭載量応答記述子
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
+--------+-------------+ 分野| ヘッダー| トランザクション| | | ID| +--------+-------------+ 八重奏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であるに違いありません。
Newton Standards Track [Page 5] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[5ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
3.1.3. Payload Header
3.1.3. 有効搭載量ヘッダー
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:
RFC1166[10]によると、ペイロードヘッダーのビットは配置されます。そこでは、ビット7は最も重要ではありません中でビット0がものである最も重要である。 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.
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であるなら、ペイロードは、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).
o ビット6と7--これらのビットの価値はペイロードタイプ(セクション3.1.4)('太平洋標準時'分野)を示します。
3.1.4. Payload Types
3.1.4. 有効搭載量タイプ
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'タイプ)。 ペイロードは、ベースのXMLが要求するIRISか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)であることを示します。
Newton Standards Track [Page 6] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[6ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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)であることを示します。
3.1.5. Version Information
3.1.5. バージョン情報
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へのconformantであり、根の要素として<バージョン>要素を使用しなければなりません。
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[3]のためのXML名前空間識別子。
<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:
サーバSHOULDは以下のケースの中のバージョン情報を送ります:
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のためにバージョン交渉について説明することを意図するだけです。
Newton Standards Track [Page 7] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[7ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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のための八重奏サイズ。
3.1.6. Size Information
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へのconformantであり、根の要素として<サイズ>要素を使用しなければなりません。
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ペイロード長)の全長と定義されます。
3.1.7. Other Information
3.1.7. 他の情報
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へのconformantであり、根の要素として他の>要素の<を使用しなければなりません。
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:
'記述子誤り'--記述子を解読する誤りがあったのを示します。 サーバSHOULDは以下の場合における記述子誤りを送ります:
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.
'システム誤り'--受信機がこのプロトコルに関連しない状態による要求を処理できないのを示します。 サーバSHOULDはそれらが要求に応じることができますが、処理要求ができないときのシステム誤りを送ります。
Newton Standards Track [Page 8] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[8ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
'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.
対応する要求で指定された意図している権威は受信機によって役立たれていません。'権威誤り'--彼らがそれら以外の権威に向けられて、役立つという要求を受け取るとき、サーバSHOULDが権威誤りを送るのを示します。
'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と共に圧縮された要求を受け取るとき、サーバはこの誤りを送らなければなりませんが、それらはインフレーションをサポートしません。
4. Interactions
4. 相互作用
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]、そして/または、Blocks Extensible Exchangeプロトコル(BEEP))の使用を必要としないかもしれません。 以下の戦略SHOULD、使用されてください:
1. If a request requires authentication, confidentiality, or other
security, use another transfer protocol. IRIS-XPC [9] is
RECOMMENDED.
1. 要求が認証、秘密性、または他のセキュリティを必要とするなら、別の転送プロトコルを使用してください。 IRIS-XPC[9]はRECOMMENDEDです。
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。 経路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。 経路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]はRECOMMENDEDです。
5. If a request yields a size error, send the request with another
transfer protocol. IRIS-XPC [9] is RECOMMENDED.
5. 要求がサイズ誤りをもたらすなら、別の転送プロトコルによる要求を送ってください。 IRIS-XPC[9]はRECOMMENDEDです。
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.
答えがないと考えられた要求の「再-トランスミッション」に関しては、初めはタイムアウト値を使用するSHOULDが再送するクライアントは1秒までセットしました。 あらゆる「再-トランスミッション」のために倍にされて、このタイムアウトはSHOULDを評価します。クライアントSHOULD NOTは達した状態でどんな要求もタイムアウト値がいったんそうすると60秒再送します。
Newton Standards Track [Page 9] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[9ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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はそれが同様に使用されるように使用されるべきRECOMMENDEDか、より効率的であり、より大きい応答サイズを提供して、より良いセキュリティを許容するでしょう。
5. Internationalization Considerations
5. 国際化問題
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]encodingsの両方を認識するのが強いられます。 [8]によって定義されたXMLの使用はUTF-8かUTF-16以外のいかなる他の文字符号化も使用してはいけません。
6. IRIS Transport Mapping Definitions
6. 定義を写像する虹彩輸送
This section lists the definitions required by IRIS [3] for transport mappings.
このセクションは輸送マッピングのためにIRIS[3]によって必要とされた定義を記載します。
6.1. URI Scheme
6.1. URI体系
See Section 7.1.1.
セクション7.1.1を見てください。
6.2. Application Protocol Label
6.2. アプリケーション・プロトコルラベル
See Section 7.1.3.
セクション7.1.3を見てください。
7. IANA Considerations
7. IANA問題
7.1. Registrations
7.1. 登録証明書
7.1.1. URI Scheme Registration
7.1.1. URI体系登録
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].
文字符号化問題: RFC3986[5]で定義されるように。
Newton Standards Track [Page 10] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[10ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
Intended usage: identifies an IRIS entity made available using XML over UDP
意図している用法: UDPの上でXMLを使用することで利用可能にされたIRIS実体を特定します。
Applications using this scheme: defined in IRIS [3].
これを使用するアプリケーションが計画されます: IRIS[3]では、定義されます。
Interoperability considerations: n/a
相互運用性問題: なし
Security Considerations: defined in Section 8.
セキュリティ問題: セクション8では、定義されます。
Relevant Publications: IRIS [3].
関連刊行物: 虹彩[3]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
7.1.2. Well-known UDP Port Registration
7.1.2. よく知られるUDPポート登録
Protocol Number: UDP
数について議定書の中で述べてください: UDP
UDP Port Number: 715
UDPは数を移植します: 715
Message Formats, Types, Opcodes, and Sequences: defined in Sections 3 and 3.1.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション3と3.1では、定義されます。
Functions: defined in IRIS [3].
機能: IRIS[3]では、定義されます。
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: IRIS-LWZ
提案された名前: 虹彩-LWZ
Short name: iris.lwz
省略名: iris.lwz
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
7.1.3. S-NAPTR Registration
7.1.3. S-NAPTR登録
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
相互運用性問題: なし
Security Considerations: defined in Section 8.
セキュリティ問題: セクション8では、定義されます。
Relevant Publications: IRIS [3].
関連刊行物: 虹彩[3]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Newton Standards Track [Page 11] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[11ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
8. Security Considerations
8. セキュリティ問題
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転送プロトコルを使用しなければなりません、IRIS-XPC[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などのように。 すべてのオペレータがBCP38[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をランダマイズすることによって、多量の偽造しているパケットでネットワークをあふれさせる攻撃者が攻撃で成功するというより少ない機会を持っています。 この測定は、どんなそのような攻撃も阻むために保証されません。 このアドバイスを無視するとき、クライアントimplementersは適宜の処置を取らなければなりません。
Newton Standards Track [Page 12] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[12ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[1] ドイツ語、P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[2] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[2] ユニコード共同体、「ユニコード規格、バージョン3インチ、ISBN0-201-61633-5、2000、<、ユニコード規格、バージョン3>、」
[3] Newton, A. and M. Sanz, "IRIS: The Internet Registry
Information Service (IRIS) Core Protocol", RFC 3981, January
2005.
[3] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)コアプロトコル」、RFC3981、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.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな委譲発見は(DDDS)を修理します」、RFC3958、2005年1月。
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、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] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[8] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", RFC 4991, August 2007.
[8] ニュートン、A.、「インターネット登録情報サービス転送プロトコルのための一般的な図式」、RFC4991、2007年8月。
[9] Newton, A., "XML Pipelining with Chunks for the Internet
Registry Information Service", RFC 4992, August 2007.
[9] ニュートン、A.、「インターネット登録情報サービスのための塊があるXMLパイプライン処理」、RFC4992、2007年8月。
9.2. Informative References
9.2. 有益な参照
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990.
[10] カークパトリックとS.とスタール、M.とM.Recker、「インターネット番号」、RFC1166、1990年7月。
Newton Standards Track [Page 13] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[13ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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:」 サーバによってクライアントに送られたデータを指示してください。 次の「C:」 または、「S:」、線はコメントがある16進法における八重奏値かXML断片のどちらかを含んでいます。 どんな線もコメントがある八重奏値とXML断片の両方を含んでいません。 コメントは括弧の中に保管されています。
Newton Standards Track [Page 14] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[14ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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: 0×08(ヘッダー: V=0、RR=要求(PD=ノー、太平洋標準時のDS=はい)はxmlと等しい)C: 0×03 0xA4(取引ID=932)C: 0×05 0xDA(最大の応答サイズ=1498)C: 0×09(権威の長さ=9)C: (権威="localhost") C: 0x6c 0x6f0×63 0×61 0x6c0×68 0x6f0x73 0×74C: (IRIS XML要求) C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒: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<md5>4LnQ1KdCahzyvwBqJis5rw=>C: </simpleBag>C: </バッグ>C: <lookupEntity C: registryTypeが等しい、「dreg1"C:」 entityClassは「地方」のCと等しいです: entityNameは"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: 0×20(ヘッダー: V=0、RR=応答(PD=ノー、太平洋標準時のDS=ノー)はxmlと等しい)S: 0×03 0xA4(取引ID=932)S: (IRIS XML応答) S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet><虹彩: 答え></虹彩: >Sに答えてください: <虹彩: nameNotFound><虹彩: 説明言語が等しい、「アン米国、「>S:」 存在という名前'AUP'は'地方'で. </虹彩: 説明>Sを見つけませんでした: </虹彩: nameNotFound></虹彩: resultSet></虹彩: 応答>。
Example 1
例1
Newton Standards Track [Page 15] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[15ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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: 0×00(ヘッダー: V=0、RR=要求(PD=ノー、太平洋標準時のDS=ノー)はxmlと等しい)C: 0x0B 0xE7(取引ID=3047)C: 0x0F 0xA0(最大の応答サイズ=4000)C: 0x0B(権威の長さ=11)C: (権威="example.com") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23、0×63 0x6F 0x6D C: (IRIS XML要求) C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: iris1 iris.xsd」>Cと等しいです: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"milo.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: 0×20(ヘッダー: V=0、RR=応答(PD=ノー、太平洋標準時のDS=ノー)はxmlと等しい)S: 0x0B 0xE7(取引ID=3047)S: (IRIS XML応答) S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet><虹彩: ><ドメインSに答えてください: "example.com"権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「tcs-com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"><ドメイン名>S:、」 milo.example.com</ドメイン名><状態><assignedAndActive/>S: </状態></ドメイン></虹彩: >Sに答えてください: </虹彩: resultSet></虹彩: 応答>。
Example 2
例2
Newton Standards Track [Page 16] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[16ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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クライアントのデモをします。 クライアントは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: 0×00(ヘッダー: V=0、RR=要求(PD=ノー、太平洋標準時のDS=ノー)はxmlと等しい)C: 0x7E 0x8A(取引ID=32394)C: 0×01 0xF2(最大の応答サイズ=498)C: 0x0B(権威の長さ=11)C: (権威="example.net") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23 0x6E0x65 0×74C: (IRIS XML要求) C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: iris1 iris1.xsd、「>C:」 <searchSet>C: 「<lookupEntity registryType=「dchk1" entityClass=」ドメイン名」C: entityNameは"felix.example.net"/>Cと等しいです: </searchSet>C: <searchSet>C: 「<lookupEntity registryType=「dchk1" entityClass=」ドメイン名」C: entityNameは"hobbes.example.net"/>Cと等しいです: </searchSet>C: <searchSet>C: 「<lookupEntity registryType=「dchk1" entityClass=」ドメイン名」C: entityNameは"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: 0×22(ヘッダー: V=0、RR=応答(PD=ノー、太平洋標準時のDS=ノー)はsiと等しい)S: 0x7E 0x8A(取引ID=32394)S: (サイズ情報XML応答) S: <responseSize xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送、「>S:」 <八重奏>1211</八重奏>S: </は>をresponseSizeします。
Example 3
例3
Newton Standards Track [Page 17] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[17ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
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: 0×01(ヘッダー: V=0、RR=要求(PD=ノー、太平洋標準時のDS=ノー)はviと等しい)C: 0x2E 0x9C(取引ID=11932)C: 0×01 0xF2(最大の応答サイズ=498)C: 0x0B(権威の長さ=11)C: (権威="example.net") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23 0x6E0x65 0×74
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: 0×21(ヘッダー: V=0、RR=応答(PD=ノー、太平洋標準時のDS=ノー)はviと等しい)S: 0x2E 0x9C(取引ID=11932)S: (バージョン情報XML応答) S: <バージョンxmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送、「>S:」 <transferProtocol protocolIdが等しい、「iris.lwz1">S:」 <アプリケーションprotocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"/>S:、」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒: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、およびデヴィッドBlackaのメンバーによって提供されました。
Author's Address
作者のアドレス
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
アンドリューL.ニュートンベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国
Phone: +1 703 948 3382 EMail: andy@hxr.us URI: http://www.verisignlabs.com/
以下に電話をしてください。 +1 3382年の703 948メール: andy@hxr.us ユリ: http://www.verisignlabs.com/
Newton Standards Track [Page 18] RFC 4993 Lightweight UDP Transfer Protocol for IRIS August 2007
ニュートン標準化過程[18ページ]のRFC4993ライト級UDPは虹彩2007年8月にプロトコルを移します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Newton Standards Track [Page 19]
ニュートン標準化過程[19ページ]
一覧
スポンサーリンク
