Network Working Group A. Newton
Request for Comments: 3983 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
Using the Internet Registry Information Service (IRIS) over
the Blocks Extensible Exchange Protocol (BEEP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS).
この文書は、インターネットレジストリ情報サービス（IRIS）のためのアプリケーション輸送基質としてブロック拡張可能交換プロトコル（BEEP）を使用する方法を指定します。
Table of Contents
目次
1. Introduction and Motivations . . . . . . . . . . . . . . . . . 2
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. BEEP Profile Identification . . . . . . . . . . . . . . . . . 3
4. IRIS Message Packages . . . . . . . . . . . . . . . . . . . . 4
5. IRIS Message Patterns . . . . . . . . . . . . . . . . . . . . 4
5.1. Registry Dependent Patterns. . . . . . . . . . . . . . . 4
5.2. Default Pattern. . . . . . . . . . . . . . . . . . . . . 4
6. Server Authentication Methods . . . . . . . . . . . . . . . . 5
6.1. Registry Dependent Methods. . . . . . . . . . . . . . . 5
6.2. Basic Server Authentication Method. . . . . . . . . . . 5
7. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 6
7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Application Protocol Label . . . . . . . . . . . . . . . 6
7.3. Allowable Character Sets . . . . . . . . . . . . . . . . 6
7.4. BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . 6
8. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. BEEP Profile Registration. . . . . . . . . . . . . . . . 6
8.2. URI Scheme Registration. . . . . . . . . . . . . . . . . 7
8.3. Well-Known TCP Port Registration . . . . . . . . . . . . 7
8.4. S-NAPTR Registration . . . . . . . . . . . . . . . . . . 8
9. Registry Definition Checklist . . . . . . . . . . . . . . . . 8
10. Internationalization Considerations . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
The proposal in this document describes the IRIS [6] application transport binding that uses BEEP [2]. Requirements for IRIS and the specification in this document are outlined in CRISP [19].
この文書で提案されたがBEEP [2]を使用して結合IRIS [6]アプリケーションの輸送を記述する。 IRISとこの文書の仕様の要件は、CRISP [19]に概説されています。
The choice of BEEP as the transport substrate is primarily driven by the need to reuse an existing, well-understood protocol with all the necessary features to support the requirements. This would give implementers a wealth of toolkits and debugging gear for use in constructing both servers and clients and allow operators to apply existing experience in issues of deployment. The construction of a simple application transport for the specific purpose of IRIS would yield a similar standard, though likely smaller and less complete, after taking into consideration matters such as framing and authentication.
搬送基板としてBEEPの選択は、主な要件をサポートするために必要なすべての機能を、既存の、十分に理解プロトコルを再利用する必要性によって駆動されます。これは、サーバーとクライアントの両方を構築するには実装にツールキットおよび使用のためのデバッグギアの富を与え、事業者が展開の問題で既存の経験を適用することができるようになります。おそらく小さいとあまり完全なもののIRISの特定の目的のために簡単なアプリケーションの輸送での建設は、このようなフレーミングや認証などの考慮事項を考慮に入れた後、同様の標準をもたらすであろう。
Precedents for using other transport mechanisms in layered applications do not seem to fit with the design goals of IRIS. HTTP [15] offers many features employed for use by similar applications. However, IRIS is not intended to be put to uses such as bypassing firewalls, commingling URI schemes, or any other methods that might lead to confusion between IRIS and traditional World Wide Web applications. Beyond adhering to the guidelines spelled out in RFC 3205 [16], the use of HTTP also offers many other challenges that quickly erode its appeal. For example, the appropriate use of TLS [4] with HTTP is defined by RFC 2817 [14], but the common use, as described in RFC 2818 [18], is usually the only method in most implementations.
階層化アプリケーション内の他のトランスポートメカニズムを使用するための判例は、IRISの設計目標に適合していないようです。 HTTP [15]同様のアプリケーションで使用するために使用される多くの機能を提供しています。しかし、IRISは、そのようなURIスキーム、またはIRISと伝統的なワールド・ワイド・ウェブ・アプリケーションとの間の混乱を招く可能性のある他の方法を混ぜ合わ、ファイアウォールをバイパスとしての用途に置くことを意図するものではありません。 [16] RFC 3205で綴らガイドラインに付着した以外にも、HTTPの使用はまた、すぐにその魅力を侵食し、他の多くの課題を提供しています。 RFC 2818に記載されているように、例えば、HTTPとTLSの適切な使用[4] [18]、RFC 2817 [14]によって定義されるが、一般的に使用され、通常、ほとんどの実装では唯一の方法です。
Finally, the use of IRIS directly over TCP, such as that specified by EPP-TCP [17], does not offer the client negotiation characteristics needed by a referral application in which a single client, in processing a query, may traverse multiple servers operating with different parameters.
最後に、このようEPP-TCPで指定されたものとして直接TCP上のIRISの使用、[17]は、単一のクライアントは、クエリを処理するには、動作する複数のサーバを通過する可能性のある紹介のアプリケーションが必要とするクライアント折衝特性を提供していません。異なるパラメータを持ちます。
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 BCP 14, RFC 2119 [5].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[5]。
The BEEP profile identifier for IRIS is a URI composed of the IRIS schema URN, followed by a slash, followed by an IRIS registry type (which is a URN).
IRISのためのBEEPプロファイル識別子（URN）でIRISレジストリタイプに続くスラッシュ続いIRISスキーマURN、からなるURIです。
In this profile identifier, the IRIS schema MUST be abbreviated according to the rules of IRIS. This is possible because the IRIS schema URN is compliant with XML_URN [20].
このプロファイル識別子は、IRISスキーマは、IRISの規則に従って略記しなければなりません。 IRISスキーマのURNがXML_URN [20]に準拠しているので、これは可能です。
The registry type URN MUST be abbreviated according to the rules of IRIS (see [6]). This is possible because the registry type URN is compliant with XML_URN [20].
レジストリタイプURNは（[6]参照）IRISの規則に従って略記しなければなりません。レジストリ型URNがXML_URN [20]に準拠しているので、これは可能です。
The following is an example of an IRIS profile identifier for BEEP. It identifies the version of IRIS to match that specified by "urn:iana:params:xml:ns:iris1" with a registry type URN of "urn:iana:params:xml:ns:dreg1":
以下は、BEEP用IRISプロファイル識別子の例です。 "：IANA：のparams：XML：NS：DREG1壷" のレジストリ型URNとそれは "：IANA：のparams：XML：：NS iris1 URN" で指定されたものと一致するIRISのバージョンを識別します。
http://iana.org/beep/iris1/dreg1
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／いりｓ１／ｄれｇ１
The full ABNF [8] follows, with certain values included from IRIS [6]:
完全ABNF [8] [6] IRISから含まれる特定の値と、次の
profile = profile-uri "/" iris-urn-abbrev "/" registry-urn-abbrev profile-uri = "http://iana.org/beep/" iris-urn-abbrev = // as specified by IRIS registry-urn-abbrev = // as specified by IRIS
プロファイル=プロファイル-URI "/" アイリス - URN-略語 "/" レジストリ-URN-略語プロファイル-URI = "http://iana.org/beep/" アイリス - URN-略称= // IRISレジストリで指定されています-urn-略称= // IRISによって指定されました
This URI is used in the "profile" element in BEEP during channel creation. According to the rules of BEEP, multiple "profile" elements may be offered, thus allowing negotiation of the version of IRIS to be used for every registry type being served.
このURIは、チャネルの作成中にBEEPの「プロファイル」の要素で使用されています。 BEEPの規則によると、複数の「プロファイル」の要素は、このようにIRISのバージョンの交渉が提供されているすべてのレジストリのタイプのために使用することができるように、提供されることがあります。
Once this profile is accepted and the channel is created, the channel is considered ready to exchange IRIS messages. A server MUST honor queries for all advertised registry types on any channel opened with an IRIS profile URI.
このプロファイルが受け入れられ、チャネルが作成されると、チャネルは、IRISのメッセージを交換する準備が考えられています。サーバーは、IRISプロファイルURIで開かれた任意のチャネル上のすべての広告を出して、レジストリの種類のクエリを尊重しなければなりません。
The BEEP profile for IRIS transmits XML [1] containing the requests and responses for IRIS registries. These XML instances MUST be encoded as Unicode [9] using the media-type of "application/xml" according to RFC 3023 [11].
IRISのためのBEEPプロフィールは、[1] IRISレジストリのための要求および応答を含むXMLを送信します。これらのXMLインスタンスは、Unicodeとしてエンコードされなければならない[9] [11] RFC 3023によれば、「アプリケーション/ XML」のメディア・タイプを使用。
XML processors are obliged to recognize both UTF-8 and UTF-16 [9] encodings. XML allows mechanisms to identify and use other character encodings by means of the "encoding" attribute in the declaration. Absence of this attribute or a byte order mark (BOM) indicates a default of UTF-8 encoding. Thus, for compatibility reasons, and per RFC 2277 [12], use of UTF-8 is RECOMMENDED with this transport mapping. UTF-16 is OPTIONAL. Other encodings MUST NOT be used.
XMLプロセッサは、[9]エンコードUTF-8およびUTF-16の両方を認識するように義務付けられています。 XMLは、メカニズムは宣言の中で、「エンコーディング」属性によって他の文字エンコーディングを特定して使用することができます。この属性またはバイトオーダーマーク（BOM）の不在は、UTF-8エンコーディングのデフォルト値を示します。したがって、互換性の理由のために、およびRFC 2277あたり[12]、UTF-8の使用は、このトランスポートマッピングで推奨されています。 UTF-16はオプションです。他のエンコーディングを使用してはいけません。
A registry type MAY define other message packages that are not IRIS XML instances (e.g., binary images referenced by an IRIS response).
レジストリタイプはIRISのXMLインスタンス（例えば、バイナリ画像はIRIS応答によって参照）ではない他のメッセージ・パッケージを定義することができます。
Because each registry type is defined by a separate BEEP profile (see [6]), each registry type MAY define a different message pattern. These patterns MUST be within the allowable scope of BEEP [2]. If a registry type does not explicitly define a message pattern, the default pattern is used (see Section 5.2).
各レジストリタイプが（[6]参照）別BEEPプロファイルで定義されているので、各レジストリタイプが異なるメッセージパターンを定義することができます。これらのパターンは、BEEP [2]の許容範囲内でなければなりません。レジストリのタイプを明示的にメッセージパターンを定義していない場合は、デフォルトのパターンは、（5.2節を参照）が使用されています。
However, each registry type MUST be capable of supporting the default pattern (Section 5.2) for use with the <lookupEntity> query in IRIS.
しかし、各レジストリタイプはIRISで<lookupEntity>クエリで使用するためのデフォルトのパターン（セクション5.2）をサポートできなければなりません。
The default BEEP profile for IRIS only has a one-to-one request/ response message pattern. This exchange involves sending an IRIS XML instance, which results in a response of an IRIS XML instance.
IRISのデフォルトBEEPプロファイルは、一対一の要求/応答メッセージパターンを有します。この交換は、IRIS XMLインスタンスの応答をもたらすIRIS XMLインスタンスを送信することを含みます。
The client sends the request by using an "MSG" message containing a valid IRIS XML instance. The server responds with an "RPY" message containing a valid IRIS XML instance. The "ERR" message is used for sending fault codes. The list of allowable fault codes is listed in BEEP [2].
クライアントは有効なIRIS XMLインスタンスを含む「MSG」メッセージを使用して要求を送信します。サーバーは、有効なIRIS XMLインスタンスを含む「RPY」メッセージで応答します。 「ERR」メッセージは、故障コードを送信するために使用されます。許容故障コードのリストは、BEEPにリストされている[2]。
When the TLS [4] tuning profile in BEEP is used, it is possible to verify the authenticity of the server. However, a convention is needed to conduct this authentication. This convention dictates the name of the authority a client uses to ask for authentication credentials so that the server knows which set of credentials to pass back. Because this is dependent on the authority component of the URI, each registry type SHOULD define a server authentication method.
BEEPでTLS [4]チューニングプロファイルが使用される場合、サーバの正当性を検証することができます。しかし、条約は、この認証を行うために必要とされています。この規則は、クライアントは、サーバーがバックパスする資格情報のセットを知っているように、認証資格情報を求めるために使用する権限の名前が決まります。これはURIの権限コンポーネントに依存しているため、各レジストリタイプは、サーバーの認証方法を定義する必要があります。
If a registry type does not explicitly define a server authentication method, the basic server authentication method (Section 6.2) is used.
レジストリのタイプを明示的にサーバーの認証方法を定義していない場合は、基本的なサーバーの認証方法（6.2節）が使用されています。
The basic server authentication method is as follows:
次のように基本的なサーバーの認証方法は次のとおりです。
1. When connecting to a server, the client MUST present the name of the authority to the server by using the BEEP [2] serverName mechanism. For instance, if the URI "iris:dreg1//com/domain/ example.com" is being resolved, the client would use the serverName="com" attribute during the BEEP session instantiation.
1.サーバーに接続している、クライアントはBEEP [2] serverNameの機構を使用してサーバーへの権限の名前を提示しなければなりません。 URI「アイリス：DREG1 // COM /ドメイン/ example.com」場合たとえば、解決され、クライアントはBEEPセッションのインスタンス化時にサーバ名=「COM」属性を使用します。
2. During TLS negotiation, the server presents to the client a certificate for the authority given in serverName. This certificate MUST be an X.509 certificate [10]. This certificate MUST contain the authority in either the subjectDN or the subjectAltName extension of type dNSName.
TLSネゴシエーション中2、サーバーはクライアントにserverNameの中で与えられた権限の証明書を提示します。この証明書はX.509証明書[10]でなければなりません。この証明書はのsubjectDNまたはタイプのdNSNameのsubjectAltName拡張のいずれかで権限を含まなければなりません。
3. The certificate MUST be cryptographically verified according to the procedures of TLS.
3.証明書は、暗号TLSの手順に従って検証されなければなりません。
4. The client then checks the subject of the certificate for a case insensitive match in the following order:
4.次に、クライアントは、次の順序で大文字と小文字を区別しない一致する証明書のサブジェクトをチェック：
1. Any of the dNSName types in the subjectAltName.
2. The subjectDN consisting solely of 'dc' components, in which
each 'dc' component represents a label from the authority
name (e.g., example.com is dc=example, dc=com).
3. A subjectDN in which the left-most component is a 'cn'
component containing the name of the authority. A wildcard
character ('*') MAY be used as the left-most label of the
name in the 'cn' component.
If the subject of the certificate does not match any of these name components, then the certificate is invalid for representing the authority.
証明書のサブジェクトは、これらの名前のコンポーネントのいずれかと一致しない場合、証明書は権威を表すため無効です。
This section lists the definitions required by IRIS [6] for transport mappings.
このセクションでは、トランスポート・マッピングのためにIRIS [6]で必要な定義を示しています。
The URI scheme name specific to BEEP over IRIS MUST be "iris.beep".
IRISを超えるビープ音が鳴り、特定のURIスキーム名が「iris.beep」でなければなりません。
The application protocol label MUST be "iris.beep".
アプリケーションプロトコルラベルは「iris.beep」でなければなりません。
See Sections 4 and 10.
セクション4および10を参照してください。
The mapping of IRIS in this document is specific to RFC 3080 [2]. This mapping MUST use TCP as specified by RFC 3081 [3].
この文書に記載されているIRISのマッピングは、RFC 3080に特異的である[2]。 RFC 3081で指定されたように、このマッピングは、TCPを使用しなければならない[3]。
Profile Identification: http://iana.org/beep/iris1
プロフィール同定：http://iana.org/beep/iris1
Messages exchanged during Channel Creation: none
メッセージはチャンネルの作成中に交換：なし
Messages starting one-to-one exchanges: IRIS XML instance
メッセージは、1対1の交換を開始：IRIS XMLインスタンス
Messages in positive replies: IRIS XML instance
正の返信のメッセージ：IRIS XMLインスタンス
Messages in negative replies: none
負の返信のメッセージ：なし
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: IRIS XML instances as defined by IRIS [6]
メッセージ構文：IRISのXMLインスタンス[6] IRISによって定義されます
Message Semantics: request/response exchanges as defined by IRIS [6]
メッセージの意味：要求/応答交換IRISによって定義された[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
お問い合わせ先：アンドリュー・ニュートン<andy@hxr.us>とマルコス・サンス<sanz@denic.de>
URL scheme name: iris.beep
URLスキーム名：iris.beep
URL scheme syntax: defined in Section 7.1 and [6]
URLスキームの構文：セクション7.1で定義されており、[6]
Character encoding considerations: as defined in RFC 2396 [7]
文字エンコーディングの考慮事項：RFC 2396で定義されている[7]。
Intended usage: identifies an IRIS entity made available using the BEEP profile for IRIS
意図した使用方法は：IRISのためのBEEPプロファイルを使用して利用可能となるIRISエンティティを識別する
Applications using this scheme: defined in IRIS [6]
この方式を使用したアプリケーション：IRISで定義されている[6]
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: defined in Section 12.
セキュリティの考慮：第12節で定義されています。
Relevant Publications: BEEP [2] and IRIS [6]
関連資料：BEEP [2]、IRIS [6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
お問い合わせ先：アンドリュー・ニュートン<andy@hxr.us>とマルコス・サンス<sanz@denic.de>
Author/Change controller: the IESG
著者/変更コントローラ：IESG
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: defined in Sections 3, 4, and 5.
メッセージフォーマット、タイプ、オペコード、および配列：セクション3、4、及び5で定義されました。
Functions: defined in IRIS [6]
機能：IRISで定義されている[6]
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: IRIS over BEEP
提案名：BEEP以上IRIS
Short name: iris.beep
短い名前：iris.beep
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
お問い合わせ先：アンドリュー・ニュートン<andy@hxr.us>とマルコス・サンス<sanz@denic.de>
Application Protocol Label: iris.beep
アプリケーションプロトコルラベル：iris.beep
Intended usage: identifies an IRIS server using BEEP
使用目的：BEEPを使ってIRISサーバーを識別
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: defined in Section 12
セキュリティの考慮：第12節で定義されています
Relevant Publications: BEEP [2] and IRIS [6]
関連資料：BEEP [2]、IRIS [6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
お問い合わせ先：アンドリュー・ニュートン<andy@hxr.us>とマルコス・サンス<sanz@denic.de>
Author/Change controller: the IESG
著者/変更コントローラ：IESG
Specifications of registry types MUST include the following explicit definitions:
レジストリタイプの仕様は以下の明示的な定義を含める必要があります。
o message pattern -- a definition of the message pattern for use with BEEP, or a declaration to use the default message pattern in Section 5.2.
Oメッセージパターン - BEEPと共に使用するためのメッセージ・パターンの定義、またはセクション5.2のデフォルトのメッセージパターンを使用する宣言。
o server authentication method -- a definition of the method to use for server authentication with TLS, a declaration to use the basic server authentication method in Section 6.2, or a declaration to use no server authentication at all.
Oサーバーの認証方法 - 方法の定義はまったくサーバ認証を使用しないために、6.2節、または宣言で基本的なサーバーの認証方法を使用するには、TLSをサーバー認証のための宣言を使用します。
See Section 4.
第4節を参照してください。
Registrations with the IANA are described in Section 8.
IANAでの登録は、セクション8に記載されています。
Implementers should be fully aware of the security considerations given by IRIS [6], BEEP [2], and TLS [4]. With respect to server authentication with the use of TLS, see Section 6.
ImplementersはIRISによって与えられたセキュリティ問題の完全に認識しておく必要があり[6]、BEEP [2]、およびTLS [4]。 TLSを使用したサーバー認証に関しては、第6章を参照してください。
Clients SHOULD be prepared to use the following BEEP tuning profiles:
クライアントは、次のBEEPチューニングプロファイルを使用するために準備する必要があります。
o http://iana.org/beep/SASL/DIGEST-MD5 -- for user authentication without the need of session encryption.
O http://iana.org/beep/SASL/DIGEST-MD5 - セッションの暗号化を必要とせずにユーザ認証のため。
o http://iana.org/beep/SASL/OTP -- for user authentication without the need of session encryption.
O http://iana.org/beep/SASL/OTP - セッションの暗号化を必要とせずにユーザ認証のため。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher -- for encryption.
O http://iana.org/beep/TLS TLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して - 暗号化のために。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates -- for encryption and user authentication.
O http://iana.org/beep/TLSクライアント側の証明書を使用してTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して - 暗号化とユーザー認証のために。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher -- for encryption. See [13].
O http://iana.org/beep/TLS TLS_RSA_WITH_AES_128_CBC_SHA暗号を使用して - 暗号化のために。 [13]を参照してください。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates -- for encryption and user authentication. See [13].
O http://iana.org/beep/TLSクライアント側の証明書を使用してTLS_RSA_WITH_AES_128_CBC_SHA暗号を使用して - 暗号化とユーザー認証のために。 [13]を参照してください。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher -- for encryption. See [13].
O http://iana.org/beep/TLS TLS_RSA_WITH_AES_256_CBC_SHA暗号を使用して - 暗号化のために。 [13]を参照してください。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates -- for encryption and user authentication. See [13].
O http://iana.org/beep/TLSクライアント側の証明書を使用してTLS_RSA_WITH_AES_256_CBC_SHA暗号を使用して - 暗号化とユーザー認証のために。 [13]を参照してください。
Anonymous client access SHOULD be considered in one of two methods:
匿名クライアントのアクセスは、二つの方法のいずれかで考慮されるべきです：
1. When no authentication tuning profile has been used. 2. Using the SASL anonymous profile: http://iana.org/beep/SASL/ANONYMOUS
認証なしのチューニングプロファイルが使用されていない1。 2. SASL匿名のプロファイルを使用する：http://iana.org/beep/SASL/ANONYMOUS
IRIS contains a referral mechanism as a standard course of operation. However, care should be taken that user authentication mechanisms do not hand user credentials to untrusted servers. Therefore, clients SHOULD NOT use the http://iana.org/beep/SASL/PLAIN tuning profile. As specified by SASL/PLAIN, clients MUST NOT use the http://iana.org/beep/SASL/PLAIN tuning profile without first encrypting the TCP session (e.g. such as with the http://iana.org/beep/TLS tuning profile).
IRISは操作の標準コースとして紹介メカニズムが含まれています。しかし、ケアは、ユーザ認証メカニズムは、信頼されていないサーバにない手のユーザーの資格情報を行うように注意しなければなりません。そのため、クライアントはhttp://iana.org/beep/SASL/PLAINチューニングプロファイルを使用しないでください。 SASL / PLAINで規定されているように、クライアントは、このようなhttp://iana.org/beep/TLSと同様に例えば（最初のTCPセッションを暗号化せずにhttp://iana.org/beep/SASL/PLAINチューニングプロファイルを使用してはなりませんチューニングプロファイル）。
[1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[1]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（XML）1.0"、W3C XML、1998年2月、<http://www.w3.org/TR/1998/REC-xml-19980210>。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[3]ローズ、M.、RFC 3081、 "TCP上にBEEPコアのマッピング" を、2001年3月。
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[4]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[6]ニュートン、A.とM.サンス、 "IRIS：インターネットレジストリ情報サービス（IRIS）コアプロトコル"、RFC 3981、2005年1月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[9] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[9]ユニコードコンソーシアム、 "Unicode規格、バージョン3"、ISBN 0-201-61633-5、2000年、<Unicode標準、バージョン3>。
[10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[10] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[11] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[11]村田、M.、ローラン、S.セント、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[12] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[12] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
、RFC 3268、2002年6月[13]のchown、P.、 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせ"。
[14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[14] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[15]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[16] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[16]ムーア、K.、BCP 56、RFC 3205、2002年2月 "基板としてHTTPを使用することに"。
[17] Hollenbeck, S., "EPP TCP Transport", Work in Progress, January 2002.
[17]ホレンベック、S.、 "EPP TCP交通"、進歩、2002年1月の作業。
[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[18]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[19] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004.
[19]ニュートン、A.、 "クロスレジストリのインターネットサービスプロトコル（CRISP）の要件"、RFC 3707、2004年2月。
[20] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[20] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
アンドリュー・L.ニュートンベリサイン社21345 Ridgetopサークルスターリング、VA 20166 USA
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/
電話：+1 703 948 3382 Eメール：anewton@verisignlabs.com。 andy@hxr.us URI：http://www.verisignlabs.com/
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany
マルコスサンスDENIC Wiesenhuettenplatz 26 D-60329フランクフルトドイツ
EMail: sanz@denic.de URI: http://www.denic.de/
電子メール：sanz@denic.de URI：http://www.denic.de/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。