RFC4992 日本語訳
4992 XML Pipelining with Chunks for the Internet Registry InformationService. A. Newton. August 2007. (Format: TXT=55848 bytes) (Updates RFC3981) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Newton Request for Comments: 4992 VeriSign, Inc. Updates: 3981 August 2007 Category: Standards Track
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 4992のベリサインInc.アップデート: 3981 2007年8月のカテゴリ: 標準化過程
XML Pipelining with Chunks
for the Internet Registry Information Service
インターネット登録情報サービスのための塊があるXMLパイプライン処理
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining.
このドキュメントはインターネットRegistry情報Service(IRIS)のために簡単なTCP転送プロトコルについて説明します。 パイプライン処理を達成するのに塊を使用することでクライアントとサーバの間にデータを移します。
Newton Standards Track [Page 1] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Terminology ............................................3
3. Request Block (RQB) .............................................4
4. Response Blocks .................................................4
4.1. Response Block (RSB) .......................................5
4.2. Connection Response Block (CRB) ............................5
5. Block Header ....................................................6
6. Chunks ..........................................................7
6.1. No Data Types ..............................................9
6.2. Version Information Types ..................................9
6.3. Size Information Types .....................................9
6.4. Other Information Types ...................................10
6.5. SASL Types ................................................11
6.6. Authentication Success Information Types ..................12
6.7. Authentication Failure Information Types ..................12
6.8. Application Data Types ....................................12
7. Idle Sessions ..................................................13
8. Closing Sessions Due to an Error ...............................13
9. Use over TLS ...................................................13
10. Update to RFC 3981 ............................................13
11. IRIS Transport Mapping Definitions ............................14
11.1. URI Scheme ...............................................14
11.2. Application Protocol Label ...............................14
12. Internationalization Considerations ...........................14
13. IANA Considerations ...........................................14
13.1. XPC URI Scheme Registration ..............................14
13.2. XPCS URI Scheme Registration .............................15
13.3. S-NAPTR XPC Registration .................................15
13.4. S-NAPTR XPCS Registration ................................15
13.5. Well-Known TCP Port Registration for XPC .................16
13.6. Well-Known TCP Port Registration for XPCS ................16
14. Security Considerations .......................................17
14.1. Security Mechanisms ......................................17
14.2. SASL Compliance ..........................................18
15. References ....................................................19
15.1. Normative References .....................................19
15.2. Informative References ...................................19
Appendix A. Examples ..............................................20
Appendix B. Contributors ..........................................28
1. 序論…3 2. 用語を記録してください…3 3. ブロック(RQB)を要求してください…4 4. 応答ブロック…4 4.1. 応答ブロック(RSB)…5 4.2. 接続応答ブロック(CRB)…5 5. ヘッダーを妨げてください…6 6. 塊…7 6.1. データ型がありません…9 6.2. バージョン情報タイプ…9 6.3. サイズ情報タイプ…9 6.4. 他の情報タイプ…10 6.5. SASLはタイプします…11 6.6. 認証成功情報タイプ…12 6.7. 認証失敗情報タイプ…12 6.8. アプリケーションデータ型…12 7. 無駄なセッション…13 8. 閉会式は誤りがそうします。13 9. TLSの上で使用します。13 10. RFC3981に、アップデートします。13 11. 定義を写像する虹彩輸送…14 11.1. URI体系…14 11.2. アプリケーション・プロトコルラベル…14 12. 国際化問題…14 13. IANA問題…14 13.1. XPC URI体系登録…14 13.2. XPCS URI体系登録…15 13.3. S-NAPTR XPC登録…15 13.4. S-NAPTR XPCS登録…15 13.5. よく知られるTCPはXPCのために登録を移植します…16 13.6. よく知られるTCPはXPCSのために登録を移植します…16 14. セキュリティ問題…17 14.1. セキュリティメカニズム…17 14.2. SASLコンプライアンス…18 15. 参照…19 15.1. 標準の参照…19 15.2. 有益な参照…19 付録A.の例…20 付録B.貢献者…28
Newton Standards Track [Page 2] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[2ページ]。
1. Introduction
1. 序論
Using S-NAPTR [5], IRIS has the ability to define the use of multiple application transports (or transfer protocols) for different types of registry services, all at the discretion of the server operator. The TCP transfer protocol defined in this document is completely modular and may be used by any registry types.
IRISには、S-NAPTR[5]を使用して、複数のアプリケーション輸送(プロトコルを移す)の異なったタイプの登録サービスの使用を定義する能力があります、サーバオペレータの裁量で。 本書では定義されたTCP転送プロトコルは、完全にモジュールであり、どんな登録タイプによっても使用されるかもしれません。
This transfer protocol defines simple framing for sending XML in chunks so that XML fragments may be acted upon (or pipelined) before the reception of the entire XML instance. This document calls this XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC.
XML断片が全体のXMLインスタンスのレセプションの前に実行されるかもしれなくて(または、pipelinedしました)、この転送プロトコルは送付XMLのために塊で簡単な縁どりを定義します。 このドキュメントは、IRIS-XPCとして塊があるこのXMLパイプライン処理を(XPC)とIRISとのその使用と呼びます。
XPC is for use with simple request and response interactions between clients and servers. Clients send a series of requests to a server in data blocks. The server will respond to each data block individually with a corresponding data block, but through the same connection. Request and response data blocks are sent using the TCP SEND function and received using the TCP RECEIVE function.
クライアントとサーバの間には、XPCは使用のために簡単な要求と応答相互作用をもってあります。 クライアントは一連の要求をデータ・ブロックのサーバに送ります。 サーバは対応するデータ・ブロックにもかかわらず、同じ接続を通して個別に各データ・ブロックまで反応するでしょう。 TCP RECEIVE機能を使用することで要求と応答データ・ブロックをTCP SEND機能を使用させて、受け取ります。
The lifecycle of an XPC session has the following phases:
XPCセッションのlifecycleには、以下のフェーズがあります:
1. A client establishes a TCP connection with a server.
1. クライアントはサーバとのTCP関係を確立します。
2. The server sends a connection response block (CRB).
2. サーバは接続応答ブロック(CRB)を送ります。
3. The client sends a request block (RQB). In this request, the
client can set a "keep open" flag requesting that the server keep
the XPC session open following the response to this request.
3. クライアントは要求ブロック(RQB)を送ります。 この要求では、この要求への応答に続いて、クライアントは、「開いた状態で、保ってください」という旗が、サーバがXPCセッションを開くように保つよう要求するように設定できます。
4. The server responds with a response block (RSB). In this
response, the server can indicate to the client whether or not
the XPC session will be closed.
4. 応答ブロック(RSB)でサーバは反応します。 この応答では、サーバは、XPCセッションが終えられるかどうかをクライアントに示すことができます。
5. If the XPC session is not to be terminated, then the lifecycle
repeats from step 3.
5. XPCセッションが終えられないことであるなら、lifecycleはステップ3から繰り返されます。
6. The TCP connection is closed.
6. TCP接続は閉じられます。
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 [8].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[8]で説明されるように本書では解釈されることであるべきですか?
Octet fields with numeric values are given according to the conventions in RFC 1166 [12]: the leftmost bit of the whole field is the most significant bit; when a multi-octet quantity is transmitted
RFC1166[12]のコンベンションに応じて、数値がある八重奏野原を与えます: 全体の分野の一番左ビットは最も重要なビットです。 マルチ八重奏量が伝えられるとき
Newton Standards Track [Page 3] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[3ページ]。
the most significant octet is transmitted first. Bits signifying flags in an octet are numbered according to the conventions of RFC 1166 [12]: bit 0 is the most significant bit and bit 7 is the least significant bit. When a diagram describes a group of octets, the order of transmission for the octets starts from the left.
最も重要な八重奏は最初に、伝えられます。 RFC1166[12]のコンベンションによると、八重奏で旗を意味するビットが付番されます: ビット0は最も重要なビットです、そして、ビット7は最下位ビットです。 ダイヤグラムが八重奏のグループについて説明するとき、八重奏のためのトランスミッションの注文は左から始めます。
3. Request Block (RQB)
3. 要求ブロック(RQB)
The format for the request block (RQB) is as follows:
要求ブロック(RQB)で形式は以下の通りです:
+--------+-----------+-----------+-------------+
field | header | authority | authority | chunks 1..n |
| | length | | |
+--------+-----------+-----------+-------------+
octets 1 1 0..255 variable
+--------+-----------+-----------+-------------+ 分野| ヘッダー| 権威| 権威| 塊1。n| | | 長さ| | | +--------+-----------+-----------+-------------+ 八重奏1 1 0。255変数
Request Block
要求ブロック
These fields have the following meanings:
これらの分野には、以下の意味があります:
o header - as described in Section 5.
o ヘッダー--セクション5で説明されるように。
o authority length - the length of the authority field in this
request block.
o 権威の長さ--この要求ブロックの権威分野の長さ。
o authority - a string of octets describing the authority against
which this request is to be executed. See [1] for the definition
and description of an authority. The number of octets in this
string MUST be no more and no less than the number specified by
the authority length.
o 権威--実行されるこの要求がことである権威について説明する一連の八重奏。 権威の定義と記述のための[1]を見てください。 このストリングの八重奏の数は、より多いはずがありません、そして、権威の長さに従って、少なくとも数は指定しました。
o chunks 1..n - the request data broken into chunks (Section 6).
o 塊1。n--塊(セクション6)が細かく分けられた要求データ。
4. Response Blocks
4. 応答ブロック
There are two types of blocks used by a server to respond to a client. The first type is a response block (RSB) defined in Section 4.1. It is used by a server to respond to request blocks (RQBs). The second type is a specialized version of a response block called a connection response block (CRB) defined in Section 4.2. It is sent by a server to a client when a connection is established to initiate protocol negotiation. Conceptually, a CRB is a type of RQB; they share the same format, but a CRB is constrained in conveying only specific information and is only sent at the beginning of the session lifecycle.
サーバによって使用される、クライアントに応じる2つのタイプのブロックがあります。 最初のタイプはセクション4.1で定義された応答ブロック(RSB)です。 それはサーバによって使用されて、ブロック(RQBs)を要求するために応じます。 2番目のタイプはセクション4.2で定義された接続応答ブロック(CRB)と呼ばれる1つの応答ブロックの専門化しているバージョンです。 議定書交渉を開始するために接続を確立するとき、サーバはそれをクライアントに送ります。 概念的に、CRBは一種のRQBです。 彼らが同じ形式を共有しますが、CRBを特殊情報だけを伝える際に抑制して、セッションlifecycleの始めに送るだけです。
Newton Standards Track [Page 4] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[4ページ]。
4.1. Response Block (RSB)
4.1. 応答ブロック(RSB)
The format for the response block (RSB) is as follows:
応答ブロック(RSB)で形式は以下の通りです:
+--------+-------------+
field | header | chunks 1..n |
| | |
+--------+-------------+
octets 1 variable
+--------+-------------+ 分野| ヘッダー| 塊1。n| | | | +--------+-------------+ 八重奏1変数
Response Block
応答ブロック
These fields have the following meanings:
これらの分野には、以下の意味があります:
o header - as described in Section 5.
o ヘッダー--セクション5で説明されるように。
o chunks 1..n - the response data broken into chunks (Section 6).
o 塊1。n--塊(セクション6)が細かく分けられた応答データ。
Servers SHOULD NOT send an RSB to a client until they have received the entire RQB. Servers that do begin sending an RSB before the reception of the entire RQB must consider that clients will not be expected to start processing the RSB until they have fully sent the RQB, and that the RSB may fill the client's TCP buffers.
彼らが全体のRQBを受けるまで、サーバSHOULD NOTはRSBをクライアントに送ります。 全体のRQBのレセプションの前にRSBを送り始めるサーバは、クライアントが、彼らがRQBを完全に送るまでRSBを処理するのを出発しないと予想されて、RSBがクライアントのTCPバッファをいっぱいにするかもしれないと考えなければなりません。
4.2. Connection Response Block (CRB)
4.2. 接続応答ブロック(CRB)
A connection response block (CRB) is a response block sent by a server to a client in response to the client initiating a session. A connection response block has the same format as a response block (RSB) (Section 4.1). The only difference is that it is constrained in one of two ways:
接続応答ブロック(CRB)はセッションを開始するクライアントに対応したサーバによってクライアントに送られた応答ブロックです。 接続応答ブロックには、応答ブロック(RSB)(セクション4.1)と同じ形式があります。 唯一の違いはそれが2つの方法の1つで抑制されるということです:
1. It contains only one chunk (see Section 6) containing version
information (see Section 6.2) and the keep-open (KO) flag in the
block header (see Section 5) has a value of 1 (meaning the
connection is not closing). Servers MUST use this type of CRB to
indicate service availability.
1. それはバージョン情報を含む1つの塊(セクション6を見る)だけを含んでいます、そして、(セクション6.2を見てください)ブロックヘッダー(セクション5を見る)の戸外を保っている(ノックアウト)旗には、1の値があります(接続を意味するのは閉じていません)。 サーバは、サービスの有用性を示すのにCRBのこのタイプを使用しなければなりません。
2. It contains only one chunk (see Section 6) containing a system
error (see 'system-error' under Section 6.4) and the keep-open
(KO) flag in the block header (see Section 5) has a value of 0
(meaning the server will close the connection immediately after
sending the CRB). Servers MUST use this type of CRB when they
can accept connections but cannot process requests.
2. それはシステム・エラーを含む1つの塊(セクション6を見る)だけを含んでいます、そして、(セクション6.4の下で'システム誤り'を見てください)ブロックヘッダー(セクション5を見る)の戸外を保っている(ノックアウト)旗には、0の値があります(サーバを意味すると、CRBを送る直後接続は終えられるでしょう)。 サーバは、接続を受け入れることができるとき、CRBのこのタイプを使用しなければなりませんが、要求を処理できません。
Newton Standards Track [Page 5] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[5ページ]。
5. Block Header
5. ブロックヘッダー
Each data block starts with a one-octet header called the block header. This header has the same format for both request and response data blocks, though some of the bits in the header only have meaning in one type of data block. The bits are ordered according to the convention given in RFC 1166 [12], where bit 0 is the most significant bit and bit 7 is the least significant bit. Each bit in the block header has the following meaning:
各データ・ブロックはブロックヘッダーと呼ばれる1八重奏のヘッダーから始まります。 このヘッダーには、要求と応答データ・ブロックの両方のための同じ形式があります、ヘッダーの数ビットは1つのタイプに関するデータ・ブロックに意味を持っているだけですが。 RFC1166[12]で与えられたコンベンションによると、ビットは配置されます。そこでは、ビット0は最も重要なビットであり、ビット7は最下位ビットです。 ブロックヘッダーの各ビットには、以下の意味があります:
o bits 0 and 1 - version (V field) - If 0 (both bits are zero), the
protocol is the version defined in this document. Otherwise, the
rest of the bits in the header and the block may be interpreted as
another version. If a server receives a request for a version it
does not support, it SHOULD follow the behavior described in
Section 8.
o ビット0と1--バージョン(V分野)--0(両方のビットはゼロである)であるなら、プロトコルは本書では定義されたバージョンです。 さもなければ、ヘッダーとブロックのビットの残りは別のバージョンとして解釈されるかもしれません。 aであるなら、サーバはそれがサポートしないバージョンを求める要求を受け取って、それは振舞いがセクション8で説明したSHOULD尾行です。
o bit 2 - keep open (KO flag) - This flag is used to request that a
connection stay open by a client and to indicate that a connection
will stay open by a server, depending on the type of block. In a
request block (RQB): a value of 1 indicates that a client is
requesting that the server not close the TCP session, and a value
of 0 indicates the client will expect their server to close the
TCP session immediately after sending the corresponding response.
In a response block (RSB) or a connection response block (CRB): a
value of 1 indicates that the server expects the client to keep
the TCP session open for the server to receive another request,
and a value of 0 indicates that the server expects the client to
close the TCP session immediately following this block.
o ビット2--開いた状態で、保ってください(旗をノックアウトしてください)--この旗は接続がクライアントによる開くままであるよう要求して、接続がサーバによる開くままであることを示すのに使用されます、ブロックのタイプに頼っていて。 要求では、(RQB)を妨げてください: 1の値は、クライアントが、サーバがTCPセッションを終えないよう要求しているのを示します、そして、0の値はクライアントが、対応する応答を送る直後それらのサーバがTCPセッションを終えると予想するのを示します。 応答では、(RSB)か接続応答ブロック(CRB)を妨げてください: 1の値は、サーバが、クライアントがサーバが別の要求を受け取るように開くようにTCPセッションを保つと予想するのを示します、そして、0の値はこのブロックに従って、サーバが、クライアントがすぐにTCPセッションを終えると予想するのを示します。
o bits 3, 4, 5, 6, and 7 - reserved - These MUST be 0. If a server
receives a request in which any of these bits is set to 1 and the
server does not understand the purpose for the value, the server
SHOULD follow the behavior described in Section 8.
o ビット3、4、5、6、および7----予約されて、これらは0であるに違いありません。 サーバがこれらのビットのいずれか1に設定される要求を受け取って、サーバが値のために目的を理解していないなら、サーバSHOULDはセクション8で説明された振舞いに続きます。
+---------+-----------+----------+
field | Version | Keep Open | reserved |
| (V) | (KO) | |
+---------+-----------+----------+
bits 0 and 1 2 3 - 7
+---------+-----------+----------+ 分野| バージョン| 開いた状態で、保ってください。| 予約されます。| | (V) | (ノックアウト) | | +---------+-----------+----------+ ビット0と1 2 3--7
Block Header
ブロックヘッダー
Newton Standards Track [Page 6] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[6ページ]。
6. Chunks
6. 塊
Request and response blocks break down the request and response XML data into chunks. Request and response blocks MUST always have a minimum of 1 chunk. Each chunk has a one-octet descriptor. The first bit of the descriptor determines if the chunk is the last chunk in the block.
要求と応答ブロックは要求と応答XMLデータを塊に分解します。 要求と応答ブロックには、最低1つの塊がいつもなければなりません。 各塊には、1八重奏の記述子があります。 記述子の最初のビットは、塊がブロックの最後の塊であるかどうか決定します。
The bits of the chunk descriptor octet are ordered according to the convention given in RFC 1166 [12], where bit 0 is the most significant bit and bit 7 is the least significant bit. The bits of the chunk descriptor octet have the following meaning:
RFC1166[12]で与えられたコンベンションによると、塊記述子八重奏のビットは配置されます。そこでは、ビット0は最も重要なビットであり、ビット7は最下位ビットです。 塊記述子八重奏のビットには、以下の意味があります:
o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk
in the block.
o ビット0--最後の塊(LCは弛む)--1であるなら、この塊はブロックで最後の塊です。
o bit 1 - data complete (DC flag) - If 1, the data in this chunk
represents the end of the data for the chunk type given. If this
bit is never set to 1 in any chunk descriptor for chunks of the
same type in a block, clients and servers MUST NOT assume the data
will continue in another block. If the block transitions from one
type of chunk to another without signaling completion of the data,
clients and servers MUST assume that the remaining data will not
be sent in a remaining chunk.
o ビット1--データは(DC旗)を完成します--1であるなら、この塊におけるデータは与えられている塊タイプのためにデータの終わりを表します。 このビットがブロックの同じタイプの塊のためのどんな塊記述子の1への決してセットでないならも、クライアントとサーバは、データが別のブロックで続くと仮定してはいけません。 ブロックがデータのシグナリング完成なしで1つのタイプの塊から別のものに移行するなら、クライアントとサーバは、残っているデータが残っている塊で送られないと仮定しなければなりません。
o bits 2, 3, and 4 - reserved - These MUST be 0.
o ビット2、3、および4----予約されて、これらは0であるに違いありません。
o bits 5, 6, and 7 - chunk type (CT field) - determines the type of
data carried in the chunk. These are the binary values for the
chunk types:
o ビット5、6、および7(塊タイプ(コネチカット分野))は塊で運ばれたデータのタイプを決定します。 これらは塊タイプにおける2進の値です:
* 000 - no data or 'nd' type (see Section 6.1)
* 000--どんなデータも'nd'もタイプされません。(セクション6.1を見ます)
* 001 - version information or 'vi' type (see Section 6.2)
* 001--バージョン情報か'vi'タイプ(セクション6.2を見ます)
* 010 - size information or 'si' type (see Section 6.3)
* 010--サイズ情報か'si'タイプ(セクション6.3を見ます)
* 011 - other information or 'oi' type (see Section 6.4)
* 011--他の情報か'oi'タイプ(セクション6.4を見ます)
* 100 - SASL (Simple Authentication and Security Layer) data or
'sd' type (see Section 6.5)
* 100--SASL(簡単なAuthenticationとSecurity Layer)データか'sd'がタイプされます。(セクション6.5を見ます)
* 101 - authentication success information or 'as' type (see
Section 6.6)
* 101--認証成功情報か'as'タイプ(セクション6.6を見ます)
* 110 - authentication failure information or 'af' type (see
Section 6.7)
* 110--認証失敗情報か'af'タイプ(セクション6.7を見ます)
Newton Standards Track [Page 7] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[7ページ]。
* 111 - application data or 'ad' type (see Section 6.8)
* 111--アプリケーションデータか'広告'タイプ(セクション6.8を見ます)
+------------+---------------+----------+------------+
field | Last Chunk | Data Complete | reserved | Chunk Type |
| (LC) | (DC) | | (CT) |
+------------+---------------+----------+------------+
bits 0 1 2 - 4 5 - 7
+------------+---------------+----------+------------+ 分野| 最後の塊| データ完全です。| 予約されます。| 塊タイプ| | (LC) | (DC) | | (コネチカット) | +------------+---------------+----------+------------+ ビット0 1 2--4 5--7
Chunk Descriptor
塊記述子
A block MAY have multiple types of chunks, but all chunks of the same type MUST be contiguous in a block and MUST be ordered in the block in the order in which their data is to be interpreted. Contiguous chunks must be ordered by type within a block in the following way:
ブロックには複数のタイプの塊があるかもしれませんが、同じタイプのすべての塊をブロックで隣接でなければならなく、解釈されるそれらのデータがことであるオーダーにおけるブロックで命令しなければなりません。 タイプはブロックの中で以下の方法で隣接の塊を命令しなければなりません:
1. authentication-related chunks - either SASL data chunks (type
100), authentication success information chunks (type 101), or
authentication failure information chunks (type 110), but not
more than one type. During the setup of security mechanisms
using these chunks, clients MUST NOT send subsequent requests
until they have received either an authentication success or
failure chunk.
1. 1つのタイプほどSASLデータ塊(100をタイプする)、認証成功情報塊(101をタイプする)か認証失敗情報塊(110をタイプする)のどちらかの、そして、しかし、多くでない認証関連の塊。 これらの塊を使用するセキュリティー対策の機構の間、彼らが認証成功か失敗塊のどちらかを受けるまで、クライアントはその後の要求を送ってはいけません。
2. data chunks - either no data chunks (type 000) or application
data chunks (type 111), but not both.
2.、データ塊--データ塊がない(000をタイプする)両方ではなく、アプリケーションデータ塊(111をタイプする)のどちらか。
3. information chunks - either version information (type 001) or
other information (type 011), but not both.
3.、情報塊--バージョン情報(001をタイプする)か両方ではなく、情報(011をタイプする)のどちらか他の。
A block MUST have at least one type of the above chunks.
ブロックには、上の塊の少なくとも1つのタイプがなければなりません。
The format for a chunk is as follows:
塊のための形式は以下の通りです:
+-----------+------------+--------+
field | chunk | chunk data | chunk |
| descriptor| length | data |
+-----------+------------+--------+
octets 1 2 variable
+-----------+------------+--------+ 分野| 塊| 塊データ| 塊| | 記述子| 長さ| データ| +-----------+------------+--------+ 八重奏1 2変数
chunk
塊
These fields have the following meanings:
これらの分野には、以下の意味があります:
o chunk descriptor - as described above. o chunk data length - the length of the data of the chunk. o chunk data - the data of the chunk.
o 塊記述子--、説明された上o塊データの長さ--塊に関するデータの長さ、o塊データ--塊に関するデータ。
Newton Standards Track [Page 8] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[8ページ]。
6.1. No Data Types
6.1. データ型がありません。
Servers and clients MUST ignore data in chunk types labeled no data. There is no requirement for these types of chunks to be zero length. A client MAY send "no data" to a server, and the server MUST respond with either a chunk of the same type or other information (Section 6.4).
サーバとクライアントはデータがないことのレッテルを貼られた塊タイプによるデータを無視しなければなりません。 これらのタイプの塊がゼロ・レングスであるという要件が全くありません。 クライアントは「データがありません」をサーバに送るかもしれません、そして、サーバは同じタイプの塊か情報(セクション6.4)のどちらかで他の反応しなければなりません。
6.2. Version Information Types
6.2. バージョン情報タイプ
Chunks of this type contain XML conformant to the schema specified in [9] and MUST have the <versions> element as the root element.
このタイプの塊は、[9]で指定された図式にXML conformantを含んでいて、根の要素として<バージョン>要素を持たなければなりません。
In the context of IRIS-XPC, the protocol identifiers for these elements are as follows:
IRIS-XPCの文脈では、これらの要素のためのプロトコル識別子は以下の通りです:
o <transferProtocol> - the value "iris.xpc1" to indicate the
protocol specified in this document.
o <transferProtocol>--、「プロトコルが本書では指定したのを示すiris.xpc1"」を評価してください。
o <application> - the XML namespace identifier for IRIS [1].
o <アプリケーション>--IRIS[1]のためのXML名前空間識別子。
o <dataModel> - the XML namespace identifier for IRIS registries.
o <dataModel>--IRIS登録のためのXML名前空間識別子。
In the context of IRIS-XPC, the authentication mechanism identifiers are the SASL mechanism names found in the IANA SASL mechanism registry defined by RFC 4422 [10].
IRIS-XPCの文脈では、認証機構識別子はRFC4422[10]によって定義されたIANA SASLメカニズム登録で見つけられたSASLメカニズム名です。
This document defines no extension identifiers.
このドキュメントは拡大識別子を全く定義しません。
Clients MAY send a block with this type of chunk to a server. These chunks SHOULD be zero length, and servers MUST ignore any data in them. When a server receives a chunk of this type, it MUST respond with a chunk of this type. This interchange allows a client to query the version information of a server.
クライアントはゼロが長さであったならサーバこれらへのこのタイプの塊があるブロックで塊SHOULDを送るかもしれません、そして、サーバはそれらのどんなデータも無視しなければなりません。 サーバがこのタイプの塊を受けるとき、それはこのタイプの塊で応じなければなりません。 この置き換えで、クライアントはサーバのバージョン情報について質問できます。
The octet sizes for the 'requestSizeOctets' and 'responseSizeOctets' attributes of the <tranferProtocol> element are defined in Section 6.3.
<tranferProtocol>要素の'requestSizeOctets'と'responseSizeOctets'属性のための八重奏サイズはセクション6.3で定義されます。
6.3. Size Information Types
6.3. サイズ情報タイプ
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <size> element as the root element.
このタイプの塊は、RFC4991[9]で指定された図式にXML conformantを含んでいて、根の要素として<サイズ>要素を持たなければなりません。
Octet counts provided by this information are defined as the sum of the count of all chunk data of a particular chunk type. For instance, if an XML instance is broken up into chunks of 20, 30, and 40 octets, the octet count would be 90 (20 + 30 + 40).
この情報によって提供された八重奏カウントは特定の塊タイプに関するすべての塊データのカウントの合計と定義されます。 例えば、XMLインスタンスが20、30の塊、および40の八重奏に終えられるなら、八重奏カウントは90(20+30+40)でしょう。
Newton Standards Track [Page 9] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[9ページ]。
Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received.
クライアントはこのタイプの塊を送ってはいけません、そして、このタイプの塊が受け取られているならセクション8の手順を用いて、サーバはセッションの下側に閉じるかもしれません。
6.4. Other Information Types
6.4. 他の情報タイプ
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <other> element as the root element.
このタイプの塊は、RFC4991[9]で指定された図式にXML conformantを含んでいて、根の要素として他の>要素の<を持たなければなりません。
The values for the 'type' attribute of <other> are as follows:
<他の>の'タイプ'属性のための値は以下の通りです:
'block-error' - indicates there was an error decoding a block.
Servers SHOULD send a block error in the following cases:
'ブロック誤り'--ブロックを解読する誤りがあったのを示します。 サーバSHOULDは以下の場合におけるブロック誤りを送ります:
1. When a request block is received containing a chunk of this
type.
1. 要求ブロックがこの塊を含むのにおいて受信されているときには、タイプしてください。
2. When a request block is received containing authentication
success (see Section 6.6) or authentication failure (see
Section 6.7) information.
2. 要求ブロックが認証成功(セクション6.6を見る)か認証失敗(セクション6.7を見る)情報を含むのにおいて受信されているとき。
3. When a request block is received containing size information
(see Section 6.3).
3. 要求ブロックがサイズ情報を含むのにおいて受信されているとき(セクション6.3を見てください)。
4. When reserved bits in the request block are 1.
4. 予約されると、要求ブロックのビットは1です。
5. When a block has not been received in its entirety and the TCP
session has been idle for a specific period of time (i.e., a
data block has been received but no terminating chunk for the
data block has been received). Two minutes is RECOMMENDED for
this timeout value. Note, there is a difference between an
idle condition due to the incomplete reception of a data block
and an idle condition between request/response transactions
associated with keeping the session open. For the latter, see
Section 7.
5. ブロックが全体として受け取られていなくて、TCPセッションが特定の期間の間無駄であるときに(すなわち、データ・ブロックを受け取りましたが、データ・ブロックで終わり塊は全く受け取っていません)。 2分はこのタイムアウト値のためのRECOMMENDEDです。 注意、セッションを開くように保つと関連している要求/応答トランザクションの間には、1データ・ブロックの不完全なレセプションによる活動していない状態と活動していない状態の間には、違いがあります。 後者に関しては、セクション7を見てください。
'data-error' - indicates there was an error parsing data in chunks
containing application or SASL data (e.g., XML is not valid in
application data).
'データ誤り'--アプリケーションかSASLデータを含む塊にはデータを分析する誤りがあったのを(例えば、XMLはアプリケーションデータで有効ではありません)示します。
'system-error' - indicates that the receiver cannot process the
request due to a condition not related to this protocol. Servers
SHOULD send a system-error when they are capable of responding to
requests but not capable of processing requests.
'システム誤り'--受信機がこのプロトコルに関連しない状態による要求を処理できないのを示します。 サーバSHOULDはそれらが要求に応じることができますが、処理要求ができないときのシステム誤りを送ります。
Newton Standards Track [Page 10] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[10ページ]。
'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が権威誤りを送るのを示します。
'idle-timeout' - indicates that an XPC session has been idle for
too long. Usage of this value is defined in Section 7. Note,
there is a difference between an idle condition due to the
incomplete reception of a data block and an idle condition between
request/response transactions associated with keeping the session
open. For the former, see 'block-error' above.
'アイドルタイムアウト'--XPCセッションがあまりに長い間無駄であることを示します。 この価値の用法はセクション7で定義されます。 注意、セッションを開くように保つと関連している要求/応答トランザクションの間には、1データ・ブロックの不完全なレセプションによる活動していない状態と活動していない状態の間には、違いがあります。 前者に関しては、'ブロック誤り'が上であることを見てください。
Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received.
クライアントはこのタイプの塊を送ってはいけません、そして、このタイプの塊が受け取られているならセクション8の手順を用いて、サーバはセッションの下側に閉じるかもしれません。
6.5. SASL Types
6.5. SASLはタイプします。
The SASL chunk type allows clients and servers to exchange SASL data.
SASL塊タイプはクライアントとサーバにSASLデータを交換させます。
The format for the data of this type of chunk is as follows:
このタイプの塊に関するデータのための形式は以下の通りです:
+-----------+-----------+-----------+-----------+
field | mechanism | mechanism | mechanism | mechanism |
| name | name | data | data |
| length | | length | |
+-----------+-----------+-----------+-----------+
octets 1 variable 2 variable
+-----------+-----------+-----------+-----------+ 分野| メカニズム| メカニズム| メカニズム| メカニズム| | 名前| 名前| データ| データ| | 長さ| | 長さ| | +-----------+-----------+-----------+-----------+ 八重奏1の可変2変数
SASL Authentication
SASL認証
These fields have the following meaning:
これらの分野には、以下の意味があります:
o mechanism name length - the length of the SASL mechanism name.
o メカニズム名前の長さ--SASLメカニズム名の長さ。
o mechanism name - the name of the SASL mechanism as registered in
the IANA SASL mechanism registry defined by [10].
o メカニズム名--[10]によって定義されたIANA SASLメカニズム登録の登録されるとしてのSASLメカニズムの名前。
o mechanism data length - the length of the SASL data.
o メカニズムデータの長さ--SASLデータの長さ。
o mechanism data - the data used for SASL.
o メカニズムデータ--SASLに使用されるデータ。
These fields MUST NOT span multiple chunks. Therefore, it should be noted that SASL data length exceeding the length of the chunk minus the length of SASL profile name minus one is an error.
これらの分野は複数の塊にかかってはいけません。 したがって、SASLプロフィール名の長さを引いて1を引いて塊の長さを超えているSASLデータの長さが誤りであることに注意されるべきです。
Newton Standards Track [Page 11] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[11ページ]。
Depending on the nature of the SASL mechanism being used, SASL data is sent from clients to servers and from servers to clients and may require multiple request/response transactions to complete. However, once a SASL exchange is complete and a server can determine authentication status, the server MUST send either authentication success information (see Section 6.6) or authentication failure information (see Section 6.7).
中古のSASLデータであることが、クライアントからサーバまでサーバからクライアントに送られて、複数の要求/応答トランザクションが完成するのを必要とするかもしれないSASLメカニズムの本質によります。 しかしながら、いったんSASL交換が完全であり、サーバが認証状態を決定できると、サーバは認証成功情報(セクション6.6を見る)か認証失敗情報のどちらかを送らなければなりません(セクション6.7を見てください)。
When used as an initial challenge response for SASL mechanisms that support such a feature, the mechanism data length may be set to a decimal value of 65,535 to indicate an absent initial response. A value of 0 indicates an empty initial response.
そのような特徴をサポートするSASLメカニズムに初期のチャレンジレスポンスとして使用されると、6万5535のデシマル値にメカニズムデータの長さが欠けている初期の応答を示すように設定されるかもしれません。 0の値は空の初期の応答を示します。
6.6. Authentication Success Information Types
6.6. 認証成功情報タイプ
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <authenticationSuccess> element as the root element.
このタイプの塊は、RFC4991[9]で指定された図式にXML conformantを含んでいて、根の要素として<authenticationSuccess>要素を持たなければなりません。
This type of chunk is only sent from a server to a client. If a client sends it to a server, this will result in a block error (see 'block-error' in Section 6.4). The usage of this chunk type is defined in Section 6.5. A server MAY close down a session due to reception of this type of chunk using the procedure in Section 8.
このタイプの塊をサーバからクライアントに送るだけです。 クライアントがそれをサーバに送ると、これはブロック誤りをもたらすでしょう(セクション6.4で'ブロック誤り'を見てください)。 この塊タイプの使用法はセクション6.5で定義されます。 セクション8の手順を用いて、サーバはこのタイプの塊のレセプションによるセッションの下側に閉じるかもしれません。
SASL mechanisms may use the <data> child element to pass back arbitrary binary data as base 64 binary. The absence of this element indicates the absence of such data, where as the presence of the element with no content indicates an empty data set.
SASLメカニズムは、ベース64バイナリーとして任意のバイナリ・データを戻すのに<データ>子供要素を使用するかもしれません。 この要素の欠如はそのようなデータ(内容のない要素の存在が空のデータセットを示すようなどこ)の欠如を示すか。
6.7. Authentication Failure Information Types
6.7. 認証失敗情報タイプ
Chunks of this type contain XML conformant to the schema specified in RFC 4991 [9] and MUST have the <authenticationFailure> element as the root element.
このタイプの塊は、RFC4991[9]で指定された図式にXML conformantを含んでいて、根の要素として<authenticationFailure>要素を持たなければなりません。
This type of chunk is only sent from a server to a client. If a client sends it to a server, this will result in a block error (see 'block-error' in Section 6.4). The usage of this chunk type is defined in Section 6.5. A server MAY close down a session due to reception of this type of chunk using the procedure in Section 8.
このタイプの塊をサーバからクライアントに送るだけです。 クライアントがそれをサーバに送ると、これはブロック誤りをもたらすでしょう(セクション6.4で'ブロック誤り'を見てください)。 この塊タイプの使用法はセクション6.5で定義されます。 セクション8の手順を用いて、サーバはこのタイプの塊のレセプションによるセッションの下側に閉じるかもしれません。
6.8. Application Data Types
6.8. アプリケーションデータ型
These chunks contain application data. For IRIS, these are IRIS [1] XML instances.
これらの塊はアプリケーションデータを含んでいます。 IRISに関しては、これらはIRIS[1]XMLインスタンスです。
Newton Standards Track [Page 12] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[12ページ]。
7. Idle Sessions
7. 無駄なセッション
If a server needs to close a connection due to it being idle, it SHOULD do the following:
サーバが、それによる接続を終える必要があるなら、存在は怠けて、それはSHOULDです。以下をしてください:
1. Send an unsolicited response block containing an idle timeout
error (see 'idle-timeout' in Section 6.4) with the keep-open (KO)
flag in the block header (Section 5) set to a value of 0.
1. (セクション5)が0の値に設定するブロックヘッダーに戸外を保っている(ノックアウト)旗でアイドルタイムアウト誤りを含む(セクション6.4で'アイドルタイムアウト'を見ます)求められていない応答ブロックを送ってください。
2. Close the TCP connection.
2. TCP接続を終えてください。
8. Closing Sessions Due to an Error
8. 誤りによる閉会式
If a server is to close a session due to an error, it SHOULD do the following:
サーバはaであるなら誤りのため閉会することであり、それはSHOULDです。以下をしてください:
1. Send a response block containing either a block-error or data-
error (see Section 6.4) or version information (see Section 6.2)
with the keep-open (KO) flag in the block header (Section 5) set
to a value of 0.
1. (セクション5)が0の値に設定するブロックヘッダーで戸外を保っている(ノックアウト)旗でブロック誤りかデータ誤り(セクション6.4を見る)かバージョン情報(セクション6.2を見る)のどちらかを含む応答ブロックを送ってください。
2. Close the TCP connection.
2. TCP接続を終えてください。
9. Use over TLS
9. TLSの上の使用
XPC may be tunneled over TLS [4] by establishing a TLS session immediately after a TCP session is opened and before any blocks are sent. This type of session is known as XPCS.
TCPセッションが開かれる直後どんなブロックも送る前にTLSセッションを確立することによって、XPCはTLS[4]の上でトンネルを堀られるかもしれません。 このタイプのセッションはXPCSとして知られています。
When using TLS, a convention must be established to allow a client to authenticate the validity of a server. XPCS uses the same convention as described by IRIS-BEEP [2].
TLSを使用するとき、クライアントがサーバの正当性を認証するのを許容するためにコンベンションを設立しなければなりません。XPCSはIRIS-BEEP[2]による説明されるのと同じコンベンションを使用します。
TLS enables authentication and confidentiality.
TLSは認証と秘密性を可能にします。
Implementers should note that while XPC and XPCS have separate URI scheme names and S-NAPTR application protocol labels, both are identified with the same <transferProtocol> value in version information chunks (see Section 6.2).
Implementersは、XPCとXPCSには別々のURI体系名とS-NAPTRアプリケーション・プロトコルラベルがある間両方がバージョン情報塊における同じ<transferProtocol>価値と同一視されていることに注意するはずです(セクション6.2を見てください)。
10. Update to RFC 3981
10. RFC3981へのアップデート
Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is the default transport for IRIS. This document revises RFC 3981 and specifies IRIS-XPC as the default transport for IRIS. The TCP well- known port registration is specified in Section 13.5.
RFC3981[1](IRIS-CORE)のセクション6.2は、IRIS-BEEP[2]がIRISのためのデフォルト輸送であると述べます。 このドキュメントは、IRISのためのデフォルト輸送としてRFC3981を改訂して、IRIS-XPCを指定します。 知られているTCP井戸ポート登録はセクション13.5で指定されます。
Newton Standards Track [Page 13] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[13ページ]。
11. IRIS Transport Mapping Definitions
11. 定義を写像する虹彩輸送
This section lists the definitions required by IRIS [1] for transport mappings.
このセクションは輸送マッピングのためにIRIS[1]によって必要とされた定義を記載します。
11.1. URI Scheme
11.1. URI体系
See Section 13.1 and Section 13.2.
セクション13.1とセクション13.2を見てください。
11.2. Application Protocol Label
11.2. アプリケーション・プロトコルラベル
See Section 13.3 and Section 13.4.
セクション13.3とセクション13.4を見てください。
12. Internationalization Considerations
12. 国際化問題
XML processors are obliged to recognize both UTF-8 and UTF-16 [3] encodings. Use of the XML defined by [9] MUST NOT use any other character encodings other than UTF-8 or UTF-16.
XMLプロセッサがUTF-8とUTF-16[3]encodingsの両方を認識するのが強いられます。 [9]によって定義されたXMLの使用はUTF-8かUTF-16以外のいかなる他の文字符号化も使用してはいけません。
13. IANA Considerations
13. IANA問題
13.1. XPC URI Scheme Registration
13.1. XPC URI体系登録
URL scheme name: iris.xpc
URL体系名: iris.xpc
Status: permanent
状態: 永久的
URL scheme syntax: defined in [1].
URL体系構文: [1]では、定義されます。
Character encoding considerations: as defined in RFC 3986 [6].
文字符号化問題: RFC3986[6]で定義されるように。
Intended usage: identifies IRIS XML using chunks over TCP
意図している用法: TCPの上で塊を使用することでIRIS XMLを特定します。
Applications using this scheme: defined in IRIS [1].
これを使用するアプリケーションが計画されます: IRIS[1]では、定義されます。
Interoperability considerations: n/a
相互運用性問題: なし
Security Considerations: defined in Section 14.
セキュリティ問題: セクション14では、定義されます。
Relevant Publications: IRIS [1].
関連刊行物: 虹彩[1]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
Newton Standards Track [Page 14] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[14ページ]。
13.2. XPCS URI Scheme Registration
13.2. XPCS URI体系登録
URL scheme name: iris.xpcs
URL体系名: iris.xpcs
Status: permanent
状態: 永久的
URL scheme syntax: defined in [1].
URL体系構文: [1]では、定義されます。
Character encoding considerations: as defined in RFC 3986 [6].
文字符号化問題: RFC3986[6]で定義されるように。
Intended usage: identifies IRIS XML using chunks over TLS
意図している用法: TLSの上で塊を使用することでIRIS XMLを特定します。
Applications using this scheme: defined in IRIS [1].
これを使用するアプリケーションが計画されます: IRIS[1]では、定義されます。
Interoperability considerations: n/a
相互運用性問題: なし
Security Considerations: defined in Section 14.
セキュリティ問題: セクション14では、定義されます。
Relevant Publications: IRIS [1].
関連刊行物: 虹彩[1]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
13.3. S-NAPTR XPC Registration
13.3. S-NAPTR XPC登録
Application Protocol Label (see [5]): iris.xpc
アプリケーションはラベルについて議定書の中で述べます。([5])を見てください: iris.xpc
Intended usage: identifies an IRIS server using XPC
意図している用法: XPCを使用することでIRISサーバを特定します。
Interoperability considerations: n/a
相互運用性問題: なし
Security Considerations: defined in Section 14.
セキュリティ問題: セクション14では、定義されます。
Relevant Publications: IRIS [1].
関連刊行物: 虹彩[1]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
13.4. S-NAPTR XPCS Registration
13.4. S-NAPTR XPCS登録
Application Protocol Label (see [5]): iris.xpcs
アプリケーションはラベルについて議定書の中で述べます。([5])を見てください: iris.xpcs
Intended usage: identifies an IRIS server using secure XPCS
意図している用法: 安全なXPCSを使用することでIRISサーバを特定します。
Interoperability considerations: n/a
相互運用性問題: なし
Newton Standards Track [Page 15] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[15ページ]。
Security Considerations: defined in Section 14.
セキュリティ問題: セクション14では、定義されます。
Relevant Publications: IRIS [1].
関連刊行物: 虹彩[1]。
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
13.5. Well-Known TCP Port Registration for XPC
13.5. よく知られるTCPはXPCのために登録を移植します。
Protocol Number: TCP
数について議定書の中で述べてください: TCP
TCP Port Number: 713
TCPは数を移植します: 713
Message Formats, Types, Opcodes, and Sequences: defined in Section 4.2, Section 3, and Section 4.1.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション4.2、セクション3、およびセクション4.1では、定義されます。
Functions: defined in IRIS [1].
機能: IRIS[1]では、定義されます。
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: IRIS over XPC
提案された名前: XPCの上の虹彩
Short name: iris.xpc
省略名: iris.xpc
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
13.6. Well-Known TCP Port Registration for XPCS
13.6. よく知られるTCPはXPCSのために登録を移植します。
Protocol Number: TCP
数について議定書の中で述べてください: TCP
TCP Port Number: 714
TCPは数を移植します: 714
Message Formats, Types, Opcodes, and Sequences: defined in Sections 9, 4.2, 3, and 4.1.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション9、4.2、3、および4.1では、定義されます。
Functions: defined in IRIS [1].
機能: IRIS[1]では、定義されます。
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: IRIS over XPCS
提案された名前: XPCSの上の虹彩
Short name: iris.xpcs
省略名: iris.xpcs
Contact Information: Andrew Newton <andy@hxr.us>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt。
Newton Standards Track [Page 16] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[16ページ]。
14. Security Considerations
14. セキュリティ問題
Implementers should be fully aware of the security considerations given by IRIS [1] and TLS [4]. With respect to server authentication with the use of TLS, see Section 6 of IRIS-BEEP [2].
ImplementersはIRIS[1]とTLS[4]によって与えられたセキュリティ問題を百も承知しているべきです。 TLSの使用によるサーバ証明に関して、IRIS-BEEP[2]のセクション6を見てください。
14.1. Security Mechanisms
14.1. セキュリティー対策
Clients SHOULD be prepared to use the following security mechanisms in the following manner:
クライアントSHOULD、以下の方法で以下のセキュリティー対策を使用するように用意してください:
o SASL/DIGEST-MD5 - for user authentication without the need of
session encryption.
o SASL/DIGEST-MD5--セッション暗号化の必要性のないユーザー認証のために。
o SASL/OTP - for user authentication without the need of session
encryption.
o SASL/OTP--セッション暗号化の必要性のないユーザー認証のために。
o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for
encryption.
o 暗号化にTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用するTLS。
o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-
side certificates - for encryption and user authentication.
o クライアントとのTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用するTLSが暗号化とユーザー認証のための証明書に面があります。
o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for
encryption. See [7].
o 暗号化にTLS_RSA_WITH_AES_128_CBC_SHA暗号を使用するTLS。 [7]を見てください。
o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side
certificates - for encryption and user authentication. See [7].
o 暗号化とユーザー認証にクライアントサイド証明書があるTLS_RSA_WITH_AES_128_CBC_SHA暗号を使用するTLS。 [7]を見てください。
o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for
encryption. See [7].
o 暗号化にTLS_RSA_WITH_AES_256_CBC_SHA暗号を使用するTLS。 [7]を見てください。
o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side
certificates - for encryption and user authentication. See [7].
o 暗号化とユーザー認証にクライアントサイド証明書があるTLS_RSA_WITH_AES_256_CBC_SHA暗号を使用するTLS。 [7]を見てください。
Anonymous client access SHOULD be considered in one of two
methods:
考えられて、2つのメソッドの1つで匿名のクライアントはSHOULDにアクセスします:
1. When no authentication has been used.
1. 認証が全く使用されていないとき。
2. Using the SASL anonymous profile: SASL/ANONYMOUS
2. SASLの匿名のプロフィールを使用します: SASL/匿名です。
As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN mechanism without first encrypting the TCP session (e.g., such as with TLS). Clients MUST implement SASL/PLAIN and TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher.
SASL/PLAINによって指定されるように、最初にTCPセッション(例えば、TLSなどの)を暗号化しないで、クライアントはSASL/PLAINメカニズムを使用してはいけません。 TLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して、クライアントはSASL/PLAINとTLSを実装しなければなりません。
Newton Standards Track [Page 17] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[17ページ]。
14.2. SASL Compliance
14.2. SASLコンプライアンス
The following list details the compliance of IRIS-XPC for use with SASL, as specified by RFC 4422 [10], Section 4.
RFC4422[10]、セクション4によって指定されるように以下のリストはSASLとの使用のためにIRIS-XPCのコンプライアンスを詳しく述べます。
1. The SASL service name to be used by IRIS-XPC is "iris-xpc".
1. IRIS-XPCによって使用されるべきSASLサービス名は「虹彩-xpc」です。
2. Section 6.2 describes the negotiation facility used to determine
the available security mechanisms. This facility may be used
both before the initiation of SASL exchanges and after the
installation of security mechanisms.
2. セクション6.2は利用可能なセキュリティー対策を決定するのに使用される交渉施設について説明します。この施設はSASL交換の開始の前とセキュリティー対策のインストールの後に使用されるかもしれません。
3.
3.
a) Section 6.5 describes the mechanism to initiate
authentication exchanges.
a) セクション6.5は、認証交換を起こすためにメカニズムについて説明します。
b) Section 6.5 describes the mechanism to transfer server
challenges and client responses.
b) セクション6.5は、サーバ挑戦とクライアント応答を移すためにメカニズムについて説明します。
c) Section 6.6 and Section 6.7 describe the mechanisms to
indicate the outcome of an authentication exchange. Section
6.6 describes how additional data may be carried with this
message.
c) セクション6.6とセクション6.7は、認証交換の結果を示すためにメカニズムについて説明します。 セクション6.6は追加データがこのメッセージでどう運ばれるかもしれないかを説明します。
4. Non-empty authorization identity strings used within IRIS-XPC
MUST be normalized according to RFC 4013 [11]. The semantics of
the non-empty authorization identity strings is server dependent,
and clients MUST use the values for these strings as given by
configuration or the user.
4. 非空の承認アイデンティティストリングは中でIRIS-XPC MUSTを使用しました。RFC4013[11]に従って、正常にされてください。 非空の承認アイデンティティストリングの意味論はサーバに依存しています、そして、構成かユーザによって与えられているようにクライアントはこれらのストリングに値を使用しなければなりません。
5. Clients or servers wishing to abort an ongoing authentication
exchange MUST close the connection.
5. クライアントか進行中の認証交換を中止したがっているサーバが接続を終えなければなりません。
6. After new security layers are negotiated, they take effect on the
first octet following the authentication success (as) (Section
6.6) chunk sent by the server and on the first octet sent after
receipt of the authentication success (as) chunk sent by the
client.
6. 新しいセキュリティ層が交渉された後に、サーバとクライアントによって送られた認証成功(as)塊の領収書の後に送られた最初の八重奏の上に送られた認証成功(as)(セクション6.6)塊に続いて、それらは最初の八重奏のときに効きます。
7. IRIS-XPC can be used with both TLS and SASL. When used in
combination, TLS MUST always be applied before any SASL
mechanism.
7. TLSとSASLの両方と共にIRIS-XPCを使用できます。 いつが中でいつも組み合わせ、TLS MUSTを使用したか。どんなSASLメカニズムの前でも適用されます。
8. IRIS-XPC does not support multiple SASL authentications.
However, if TLS is being used in combination with SASL, TLS
authentication MUST occur before any SASL authentication.
8. IRIS-XPCは複数のSASL認証をサポートしません。 しかしながら、TLSがSASLと組み合わせて使用されているなら、TLS認証はどんなSASL認証の前にも起こらなければなりません。
Newton Standards Track [Page 18] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[18ページ]。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[1] Newton, A. and M. Sanz, "IRIS: The Internet Registry
Information Service (IRIS) Core Protocol", RFC 3981, January
2005.
[1] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)コアプロトコル」、RFC3981、2005年1月。
[2] Newton, A. and M. Sanz, "Using the Internet Registry
Information Service over the Blocks Extensible Exchange
Protocol", RFC 3983, January 2005.
[2] ニュートン、A.、およびM.サンス、「インターネット登録情報を使用して、広げることができる交換プロトコルをブロックの上修理してください」、RFC3983、2005年1月。
[3] The Unicode Consortium, "The Unicode Standard, Version 3",
ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[3] ユニコード共同体、「ユニコード規格、バージョン3インチ、ISBN0-201-61633-5、2000、<、ユニコード規格、バージョン3>、」
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[4] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[5] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[5] Daigle、L.、およびA.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな委譲発見は(DDDS)を修理します」、RFC3958、2005年1月。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[7]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[9] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", RFC 4991, August 2007.
[9] ニュートン、A.、「インターネット登録情報サービス転送プロトコルのための一般的な図式」、RFC4991、2007年8月。
[10] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[10] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。
[11] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and
Passwords", RFC 4013, February 2005.
[11]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
15.2. Informative References
15.2. 有益な参照
[12] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990.
[12] カークパトリックとS.とスタール、M.とM.Recker、「インターネット番号」、RFC1166、1990年7月。
Newton Standards Track [Page 19] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[19ページ]。
Appendix A. Examples
付録A.の例
This section gives examples of IRIS-XPC sessions. Lines beginning with "C:" denote data sent by the client to the server, and lines beginning with "S:" denote data sent by the server to the client. Following the "C:" or "S:", the line contains either octet values in hexadecimal notation with comments or XML fragments. No line contains both octet values with comments and XML fragments. Comments are contained within parentheses.
このセクションはIRIS-XPCセッションに関する例を出します。 始めを裏打ちする、「C:」 クライアントによってサーバ、および系列始めに送られたデータを指示する、「S:」 サーバによってクライアントに送られたデータを指示してください。 次の「C:」 または、「S:」、系列はコメントがある16進法における八重奏値かXML断片のどちらかを含んでいます。 どんな系列もコメントがある八重奏値とXML断片の両方を含んでいません。 コメントは括弧の中に保管されています。
It should also be noted that flag values of "yes" and "no" reflect binary values 1 and 0.
また、「はい」と「いいえ」の旗の値が2進の値1と0を反映することに注意されるべきです。
The following example demonstrates an IRIS client issuing two requests in one XPC session. In the first request, the client is requesting status information for "example.com". This request and its response are transferred with one chunk. In the second request, the client is requesting status information for "milo.example.com", "felix.example.com", and "hobbes.example.com". This request and its response are transferred with three chunks.
以下の例は1つのXPCセッションにおける2つの要求を出すIRISクライアントのデモをします。 最初の要求では、クライアントは"example.com"のための状態情報を要求しています。 1つの塊でこの要求とその応答を移します。 2番目の要求では、クライアントは"milo.example.com"、"felix.example.com"、および"hobbes.example.com"のための状態情報を要求しています。 3つの塊でこの要求とその応答を移します。
S: (connection response block) S: 0x20 (block header: V=0,KO=yes) S: (chunk 1) S: 0xC1 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBF (chunk length=447) S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <transferProtocol protocolId="iris.xpc1" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions>
S: (接続応答ブロック) S: 0×20(ブロックヘッダー: V=0、ノックアウト=はい)S: (塊1) S: 0xC1(LCははいと等しく、DCははいと等しく、コネチカットはviと等しい)S: 0×01 0xBF(塊の長さ=447)S: (バージョン情報) S: <?xmlバージョン= 「1インチ?」>S: <バージョンxmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送、「>S:」 <transferProtocol protocolIdが等しい、「iris.xpc1"S:」 authenticationIdsが等しい、「単に外部、「>S:」 <アプリケーションprotocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"S:、」 extensionIdsが等しい、「 http://example.com/SIMPLEBAG 、「>S:」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"/>S:、」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dreg1"/>S:、」 </アプリケーション>S: </transferProtocol>S: </バージョン>。
C: (request block) C: 0x20 (block header: V=0,KO=yes) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0xC7 (LC=yes,DC=yes,CT=ad) C: 0x01 0x53 (chunk length=339) C: (IRIS XML request)
C: (要求ブロック) C: 0×20(ブロックヘッダー: V=0、ノックアウト=はい)C: 0x0B(権威の長さ=11)C: (権威="example.com") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23、0×63 0x6F 0x6D C: (塊1) C: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)C: 0×01 0×53(塊の長さ=339)C: (IRIS XML要求)
Newton Standards Track [Page 20] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[20ページ]。
C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="example.com" /> C: </searchSet> C: </request>
C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: iris1 iris.xsd」>Cと等しいです: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"example.com"/>Cと等しいです: </searchSet>C: </要求>。
S: (response block) S: 0x20 (block header: V=0,KO=yes) S: (chunk 1) S: 0xC7 (LC=yes,DC=yes,CT=ad) S: 0x01 0xE0 (chunk length=480) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response>
S: (応答ブロック) S: 0×20(ブロックヘッダー: V=0、ノックアウト=はい)S: (塊1) S: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)S: 0×01 0xE0(塊の長さ=480)S: (IRIS XML応答) S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: </虹彩: 応答>。
C: (request block) C: 0x00 (block header: V=0,KO=no) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0x07 (LC=no,DC=no,CT=ad) C: 0x01 0x4E (chunk length=339) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name"
C: (要求ブロック) C: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)C: 0x0B(権威の長さ=11)C: (権威="example.com") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23、0×63 0x6F 0x6D C: (塊1) C: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)C: 0×01 0x4E(塊の長さ=339)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は「ドメイン名」と等しいです。
Newton Standards Track [Page 21] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[21ページ]。
C: entityName="milo.example.com" /> C: </searchSet> C: (chunk 2) C: 0x07 (LC=no,DC=no,CT=ad) C: 0x00 0xA9 (chunk length=169) C: (IRIS XML request) C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="felix.example.com" /> C: </searchSet> C: (chunk 3) C: 0xC7 (LC=yes,DC=yes,CT=ad) C: 0x00 0xB5 (chunk length=181) C: (IRIS XML request) C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="hobbes.example.com" /> C: </searchSet> C:</request>
C: entityNameは"milo.example.com"/>Cと等しいです: </searchSet>C: (塊2) C: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)C: 0×00 0xA9(塊の長さ=169)C: (IRIS XML要求) C: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"felix.example.com"/>Cと等しいです: </searchSet>C: (塊3) C: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)C: 0×00 0xB5(塊の長さ=181)C: (IRIS XML要求) C: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"hobbes.example.com"/>Cと等しいです: </searchSet>C: </要求>。
S: (response block) S: 0x00 (block header: V=0,KO=no) S: (chunk 1) S: 0x07 (LC=no,DC=no,CT=ad) S: 0x01 0xDA (chunk length=474) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="milo.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>milo.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 2) S: 0x07 (LC=no,DC=no,CT=ad) S: 0x01 0xA2 (chunk length=418) S: (IRIS XML response)
S: (応答ブロック) S: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)S: (塊1) S: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)S: 0×01 0xDA(塊の長さ=474)S: (IRIS XML応答) S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「milo.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>milo.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: (塊2) S: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)S: 0×01 0xA2(塊の長さ=418)S: (IRIS XML応答)
Newton Standards Track [Page 22] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[22ページ]。
S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="felix.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>felix.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 3) S: 0xC7 (LC=yes,DC=yes,CT=ad) S: 0x01 0xB5 (chunk length=437) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" S: entityName="hobbes.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>hobbes.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response>
S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「felix.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>felix.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: (塊3) S: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)S: 0×01 0xB5(塊の長さ=437)S: (IRIS XML応答) S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassは「ドメイン名」Sと等しいです: entityNameが等しい、「hobbes.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>hobbes.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: </虹彩: 応答>。
Example 1
例1
In the following example, an IRIS client requests domain status information for "milo.example.com", "felix.example.com", and "hobbes.example.com" in one request. The request is sent with one chunk; however, the answer is returned in three chunks.
以下の例では、IRISクライアントは1つの要求で"milo.example.com"、"felix.example.com"、および"hobbes.example.com"のためのドメイン状態情報を要求します。 1つの塊と共に要求を送ります。 しかしながら、3つの塊で答えを返します。
S: (connection response block) S: 0x20 (block header: V=0,KO=yes) S: (chunk 1) S: 0xC1 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBF (chunk length=447) S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: (接続応答ブロック) S: 0×20(ブロックヘッダー: V=0、ノックアウト=はい)S: (塊1) S: 0xC1(LCははいと等しく、DCははいと等しく、コネチカットはviと等しい)S: 0×01 0xBF(塊の長さ=447)S: (バージョン情報) S: <?xmlバージョン= 「1インチ?」>S: <バージョンxmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送">"
Newton Standards Track [Page 23] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[23ページ]。
S: <transferProtocol protocolId="iris.xpc1" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions>
S: <transferProtocol protocolIdが等しい、「iris.xpc1"S:」 authenticationIdsが等しい、「単に外部、「>S:」 <アプリケーションprotocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"S:、」 extensionIdsが等しい、「 http://example.com/SIMPLEBAG 、「>S:」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"/>S:、」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dreg1"/>S:、」 </アプリケーション>S: </transferProtocol>S: </バージョン>。
C: (request block) C: 0x00 (block header: V=0,KO=no) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0xC7 (LC=yes,DC=yes,CT=ad) C: 0x02 0xAB (chunk length=683) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="milo.example.com" /> C: </searchSet> C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="felix.example.com" /> C: </searchSet> C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="hobbes.example.com" /> C: </searchSet> C: </request>
C: (要求ブロック) C: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)C: 0x0B(権威の長さ=11)C: (権威="example.com") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23、0×63 0x6F 0x6D C: (塊1) C: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)C: 0×02 0xAB(塊の長さ=683)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: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"felix.example.com"/>Cと等しいです: </searchSet>C: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"hobbes.example.com"/>Cと等しいです: </searchSet>C: </要求>。
S: (response block) S: 0x00 (block header: V=0,KO=no) S: (chunk 1) S: 0x07 (LC=no,DC=no,CT=ad) S: 0x01 0xDA (chunk length=474) S: (IRIS XML response)
S: (応答ブロック) S: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)S: (塊1) S: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)S: 0×01 0xDA(塊の長さ=474)S: (IRIS XML応答)
Newton Standards Track [Page 24] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[24ページ]。
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="milo.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>milo.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 2) S: 0x07 (LC=no,DC=no,CT=ad) S: 0x01 0xA2 (chunk length=418) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="felix.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>felix.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: (chunk 3) S: 0xC7 (LC=yes,DC=yes,CT=ad) S: 0x01 0xB5 (chunk length=437) S: (IRIS XML response) S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" S: entityName="hobbes.example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>hobbes.example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer>
S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「milo.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>milo.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: (塊2) S: 0×07(LCはいいえと等しく、DCはいいえと等しく、コネチカットは広告と等しい)S: 0×01 0xA2(塊の長さ=418)S: (IRIS XML応答) S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「felix.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>felix.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: (塊3) S: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)S: 0×01 0xB5(塊の長さ=437)S: (IRIS XML応答) S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassは「ドメイン名」Sと等しいです: entityNameが等しい、「hobbes.example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>hobbes.example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: 答え>。
Newton Standards Track [Page 25] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[25ページ]。
S: </iris:resultSet> S: </iris:response>
S: </虹彩: resultSet>S: </虹彩: 応答>。
Example 2
例2
In the following example, an IRIS client sends a request containing SASL/PLAIN authentication data and a domain status check for "example.com". The server responds with authentication success information and the domain status of "example.com". Note that the client requests that the connection stay open for further requests, but the server does not honor this request.
以下の例では、IRISクライアントは"example.com"のためにSASL/PLAIN認証データを含む要求とドメイン状態チェックを送ります。 サーバは"example.com"の認証成功情報とドメイン状態で反応します。 接続が滞在しているというクライアント要求がさらなる要求のために開きますが、サーバがこの要求を光栄に思わないことに注意してください。
S: (connection response block) S: 0x20 (block header: V=0,KO=yes) S: (chunk 1) S: 0xC1 (LC=yes,DC=yes,CT=vi) S: 0x01 0xBF (chunk length=447) S: (Version Information) S: <?xml version="1.0"?> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <transferProtocol protocolId="iris.xpc1" S: authenticationIds="PLAIN EXTERNAL"> S: <application protocolId="urn:ietf:params:xml:ns:iris1" S: extensionIds="http://example.com/SIMPLEBAG"> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: </application> S: </transferProtocol> S: </versions>
S: (接続応答ブロック) S: 0×20(ブロックヘッダー: V=0、ノックアウト=はい)S: (塊1) S: 0xC1(LCははいと等しく、DCははいと等しく、コネチカットはviと等しい)S: 0×01 0xBF(塊の長さ=447)S: (バージョン情報) S: <?xmlバージョン= 「1インチ?」>S: <バージョンxmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送、「>S:」 <transferProtocol protocolIdが等しい、「iris.xpc1"S:」 authenticationIdsが等しい、「単に外部、「>S:」 <アプリケーションprotocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"S:、」 extensionIdsが等しい、「 http://example.com/SIMPLEBAG 、「>S:」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"/>S:、」 <dataModel protocolIdが等しい、「つぼ:ietf:params: xml:ナノ秒:dreg1"/>S:、」 </アプリケーション>S: </transferProtocol>S: </バージョン>。
C: (request block) C: 0x00 (block header: V=0,KO=no) C: 0x0B (authority length=11) C: (authority="example.com") C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D C: (chunk 1) C: 0x44 (LC=no,DC=yes,CT=sd) C: 0x00 0x11 (chunk length=11) C: (SASL data) C: 0x05 (mechanism length=5) C: (mechanism name="PLAIN") C: 0x50 0x4C 0x41 0x49 0x43 C: 0x00 0x0A (sasl PLAIN data length=10) C: (sasl PLAIN data: authcid="bob") C: (sasl PLAIN data: authzid=NULL) C: (sasl PLAIN data: password="kEw1") C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 C: (chunk 2)
C: (要求ブロック) C: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)C: 0x0B(権威の長さ=11)C: (権威="example.com") C: 0×65 0×78 0×61 0x6D0x70 0x6C0x65 0×23、0×63 0x6F 0x6D C: (塊1) C: 0×44(LCはいいえと等しく、DCははいと等しく、コネチカットはsdと等しい)C: 0×00 0×11(塊の長さ=11)C: (SASLデータ) C: 0×05(メカニズムの長さ=5)C: (メカニズム名前=「平野」) C: 0×50 0x4C、0×41 0×49 0×43C: 0×00 0x0A(sasl PLAINデータの長さ=10)C: (sasl PLAINデータ: authcid=「ボブ」) C: (sasl PLAINデータ: authzid=NULL) C: (sasl PLAINデータ: パスワード=、「kEw1")」 C: 0×62 0x6F0x62 0×20 0×00 0×20 0x6B0x45 0×77、0×31C: (塊2)
Newton Standards Track [Page 26] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[26ページ]。
C: 0xC7 (LC=yes,DC=yes,CT=ad) C: 0x01 0x53 (chunk length=339) C: (IRIS XML request) C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" > C: <searchSet> C: <lookupEntity C: registryType="urn:ietf:params:xml:ns:dchk1" C: entityClass="domain-name" C: entityName="example.com" /> C: </searchSet> C: </request>
C: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)C: 0×01 0×53(塊の長さ=339)C: (IRIS XML要求) C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: iris1 iris.xsd」>Cと等しいです: <searchSet>C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1"C:、」 entityClassは「ドメイン名」Cと等しいです: entityNameは"example.com"/>Cと等しいです: </searchSet>C: </要求>。
S: (response block) S: 0x00 (block header: V=0,KO=no) S: (chunk 1) S: 0x45 (LC=no,DC=yes,CT=as) S: 0x00 0xD0 (chunk length=208) S: (authentication success response) S: <?xml version="1.0"?> S: <authenticationSuccess S: xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <description language="en"> S: user 'bob' authenticates via password S: </description> S: </authenticationSuccess> S: (chunk 2) S: 0xC7 (LC=yes,DC=yes,CT=ad) S: 0x01 0xE0 (chunk length=480) S: (IRIS XML response) S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:resultSet> S: <iris:answer> S: <domain authority="example.com" registryType="dchk1" S: entityClass="domain-name" entityName="example.com-1" S: temporaryReference="true" S: xmlns="urn:ietf:params:xml:ns:dchk1"> S: <domainName>example.com</domainName> S: <status> S: <assignedAndActive/> S: </status> S: </domain> S: </iris:answer> S: </iris:resultSet> S: </iris:response>
S: (応答ブロック) S: 0×00(ブロックヘッダー: V=0、ノックアウト=いいえ)S: (塊1) S: 0×45(いいえ、DCがはいct=と等しいLC=)S: 0×00 0xD0(塊の長さ=208)S: (認証成功応答) S: <?xmlバージョン= 「1インチ?」>S: <authenticationSuccess S: xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 虹彩輸送、「>S:」 <記述言語が等しい、「アン、「>S:」 ユーザ'ボブ'はパスワードSで以下を認証します。 </記述>S: </authenticationSuccess>S: (塊2) S: 0xC7(LCははいと等しく、DCははいと等しく、コネチカットは広告と等しい)S: 0×01 0xE0(塊の長さ=480)S: (IRIS XML応答) S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1">S:、」 <虹彩: resultSet>S: <虹彩: >Sに答えてください: "example.com"<ドメイン権威=registryTypeが等しい、「dchk1" S:」 entityClassが「ドメイン名」entityName=と等しい、「example.com-1インチS:」 temporaryReferenceは「本当」のSと等しいです: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:dchk1">S:、」 <ドメイン名>example.com</ドメイン名>S: <状態>S: <assignedAndActive/>S: </状態>S: </ドメイン>S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: </虹彩: 応答>。
Example 3
例3
Newton Standards Track [Page 27] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[27ページ]。
Appendix B. Contributors
付録B.貢献者
Substantive contributions to this document have been provided by the members of the IETF's CRISP Working Group, especially Robert Martin- Legene, Milena Caires, and David Blacka.
このドキュメントへの実質的な貢献はIETFのCRISP作業部会、ロバート・マーチン特にレジェーヌ、ミレナ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 28] RFC 4992 IRIS XML Pipelining with Chunks August 2007
ニュートンStandardsは2007年8月に塊でRFC4992虹彩XMLパイプライン処理を追跡します[28ページ]。
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 29]
ニュートン標準化過程[29ページ]
一覧
スポンサーリンク
