RFC 3983 - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3983
タイトル : RFC 3983 - Blocks Extensible Exchange Protocol (BEEP) を介した Internet Registry Information Service (IRIS) の使用
翻訳編集 : 自動生成

[要約] RFC 3983は、IRISをBEEP上で使用するためのガイドラインです。目的は、インターネットレジストリ情報サービス（IRIS）の効果的な利用と、BEEPプロトコルを介した通信のセキュリティと信頼性の向上です。

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)

Blocks Extensible Exchange Protocol (BEEP) を介した Internet Registry Information Service (IRIS) の使用

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) を参照してください。このメモの配布は無制限です。

著作権表示

著作権 (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) のアプリケーショントランスポート基盤として Blocks Extensible Exchange Protocol (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

1. Introduction and Motivations

1. 紹介と動機

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 と従来の World Wide Web アプリケーションの間の混乱を引き起こす可能性のあるその他の方法の使用を意図したものではありません。RFC 3205 [16] に明記されているガイドラインを遵守するだけでなく、HTTP の使用には、その魅力を急速に損なう他の多くの課題もあります。たとえば、HTTP での TLS [4] の適切な使用は RFC 2817 [14] で定義されていますが、RFC 2818 [18] で説明されている一般的な使用は、通常、ほとんどの実装における唯一の方法です。

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 [17] で指定されているような IRIS を 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 BCP 14, RFC 2119 [5].

この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [5] に記載されているように解釈されます。

3. BEEP Profile Identification

3. BEEP プロファイルの識別

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 プロファイル識別子は、IRIS スキーマ URN、スラッシュ、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 の規則に従って短縮されなければなりません (MUST)。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 は、IRIS の規則に従って省略しなければなりません ([6] を参照)。これは、レジストリタイプ 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 プロファイル識別子の例です。これは、レジストリタイプ URN が「urn:iana:params:xml:ns:dreg1」である「urn:iana:params:xml:ns:iris1」で指定されたバージョンと一致する IRIS のバージョンを識別します。

http://iana.org/beep/iris1/dreg1

The full ABNF [8] follows, with certain values included from IRIS [6]:

完全な ABNF [8] は次のとおりです。IRIS [6] からの特定の値も含まれています。

      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

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 の「profile」要素で使用されます。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 で開かれたチャネル上のすべてのアドバタイズされたレジストリタイプのクエリを受け入れなければなりません (MUST)。

4. IRIS Message Packages

4. IRIS メッセージパッケージ

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 プロファイルは、IRIS レジストリへのリクエストとレスポンスを含む XML [1] を送信します。これらの XML インスタンスは、RFC 3023 [11] に従って、メディアタイプ「application/xml」を使用して Unicode [9] としてエンコードされなければなりません (MUST)。

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 プロセッサは、UTF-8 と UTF-16 [9] エンコーディングの両方を認識する必要があります。XML では、宣言内の「encoding」属性によって他の文字エンコーディングを識別して使用するメカニズムが可能になります。この属性またはバイトオーダーマーク (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 応答によって参照されるバイナリイメージなど) を定義してもよい(MAY)。

5. IRIS Message Patterns

5. IRIS メッセージパターン

5.1. Registry Dependent Patterns

5.1. レジストリに依存するパターン

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).

各レジストリタイプは個別の BEEP プロファイル ([6] を参照) によって定義されるため、各レジストリタイプは異なるメッセージパターンを定義してもよい(MAY)。これらのパターンは 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) をサポートできなければなりません (MUST)。

5.2. Default Pattern

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 プロファイルには、1 対 1 の要求/応答メッセージパターンのみがあります。この交換には 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] に記載されています。

6. Server Authentication Methods

6. サーバーの認証方法

6.1. Registry Dependent Methods

6.1. レジストリに依存するメソッド

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 の権限コンポーネントに依存するため、各レジストリタイプでサーバー認証方法を定義する必要があります (SHOULD)。

If a registry type does not explicitly define a server authentication method, the basic server authentication method (Section 6.2) is used.

レジストリタイプでサーバー認証方法が明示的に定義されていない場合は、基本サーバー認証方法 (セクション 6.2) が使用されます。

6.2. Basic Server Authentication Method

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 メカニズムを使用してサーバーに権限の名前を提示しなければなりません (MUST)。たとえば、URI "iris:dreg1//com/domain/example.com" が解決される場合、クライアントは BEEP セッションのインスタンス化中に serverName="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.

2. TLS ネゴシエーション中に、サーバーは、serverName で指定された機関の証明書をクライアントに提示します。この証明書は X.509 証明書 [10] でなければなりません。この証明書には、subjectDN または dNSName タイプの subjectAltName 拡張子のいずれかに認証局が含まれていなければなりません (MUST)。

3. The certificate MUST be cryptographically verified according to the procedures of TLS.

3. 証明書は、TLS の手順に従って暗号的に検証されなければなりません (MUST)。

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.

1. subjectAltName 内のいずれかの dNSName タイプ。2. subjectDN は「dc」コンポーネントのみで構成され、各「dc」コンポーネントは機関名からのラベルを表します (例: example.com は dc=example, dc=com)。3. 左端のコンポーネントが機関の名前を含む「cn」コンポーネントである subjectDN。ワイルドカード文字 ('*') は、'cn' コンポーネント内の名前の左端のラベルとして使用できます (MAY)。

If the subject of the certificate does not match any of these name components, then the certificate is invalid for representing the authority.

証明書の件名がこれらの名前コンポーネントのいずれにも一致しない場合、証明書は機関を表すものとしては無効です。

7. IRIS Transport Mapping Definitions

7. IRIS トランスポートマッピングの定義

This section lists the definitions required by IRIS [6] for transport mappings.

このセクションでは、IRIS [6] でトランスポートマッピングに必要な定義をリストします。

7.1. URI Scheme

7.1. URIスキーム

The URI scheme name specific to BEEP over IRIS MUST be "iris.beep".

BEEP over IRIS に固有の URI スキーム名は「iris.beep」でなければなりません。

7.2. Application Protocol Label

7.2. アプリケーションプロトコルラベル

The application protocol label MUST be "iris.beep".

アプリケーションプロトコルラベルは「iris.beep」でなければなりません。

7.3. Allowable Character Sets

7.3. 使用できる文字セット

See Sections 4 and 10.

セクション 4 と 10 を参照してください。

7.4. BEEP Mapping

7.4. ビープ音のマッピング

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 [3] で指定されている TCP を使用しなければなりません (MUST)。

8. Registrations

8. 登録

8.1. BEEP Profile Registration

8.1. BEEPプロファイルの登録

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 [6] で定義されている IRIS XML インスタンス

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>

8.2. URI Scheme Registration

8.2. URIスキームの登録

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

相互運用性に関する考慮事項: なし

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>

Author/Change controller: the IESG

作成者/変更管理者: IESG

8.3. Well-Known TCP Port Registration

8.3. 既知の TCP ポートの登録

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

提案された名前: IRIS over BEEP

Short name: iris.beep

ショートネーム: iris.beep

   Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
   <sanz@denic.de>

8.4. S-NAPTR Registration

8.4. S-NAPTR登録

Application Protocol Label: iris.beep

アプリケーションプロトコルラベル: iris.beep

Intended usage: identifies an IRIS server using BEEP

使用目的: BEEP を使用して IRIS サーバーを識別します。

Interoperability considerations: 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>

Author/Change controller: the IESG

作成者/変更管理者: IESG

9. Registry Definition Checklist

9. レジストリ定義チェックリスト

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 サーバー認証方式 -- TLS によるサーバー認証に使用する方式の定義、セクション 6.2 の基本サーバー認証方式を使用する宣言、またはサーバー認証をまったく使用しない宣言。

10. Internationalization Considerations

10. 国際化に関する考慮事項

See Section 4.

セクション 4 を参照してください。

11. IANA Considerations

11. IANAの考慮事項

Registrations with the IANA are described in Section 8.

IANA への登録についてはセクション 8 で説明します。

12. Security Considerations

12. セキュリティに関する考慮事項

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.

実装者は、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:

匿名クライアントアクセスは、次の 2 つの方法のいずれかで考慮される必要があります。

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 調整プロファイルを使用すべきではありません (SHOULD NOT)。SASL/PLAIN で指定されているように、クライアントは最初に TCP セッションを暗号化せずに http://iana.org/beep/SASL/PLAIN チューニングプロファイルを使用してはなりません (例: http://iana.org/beep/TLS など)。チューニングプロファイル）。

13. References

13. 参考文献

13.1. Normative References

13.1. 引用文献

[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] World Wide Web Consortium、「Extensible Markup Language (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] Rose, M.、「The Blocks Extensible Exchange Protocol Core」、RFC 3080、2001 年 3 月。

[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.

[3] Rose, M.、「BEEP コアを TCP にマッピング」、RFC 3081、2001 年 3 月。

[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

[4] Dierks, T. および C. Allen、「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] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。

[6] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.

[6] Newton, A. および M. Sanz、「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] Berners-Lee, T.、Fielding, R.、および L. Masinter、「Uniform Resource Identifiers (URI): Generic Syntax」、RFC 2396、1998 年 8 月。

[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[8] Crocker, 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 コンソーシアム、「The Unicode Standard, Version 3」、ISBN 0-201-61633-5、2000、<The Unicode Standard, Version 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.、Polk, W.、Ford, W.、および D. Solo、「インターネット X.509 公開キー基盤証明書および証明書失効リスト (CRL) プロファイル」、RFC 3280、2002 年 4 月。

[11] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[11] Murata, M.、Laurent, S. St.、および D. Kohn、「XML Media Types」、RFC 3023、2001 年 1 月。

[12] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[12] Alvestorm, 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.

[13] Cown, P.、「トランスポート層セキュリティ (TLS) のための高度暗号化標準 (AES) 暗号スイート」、RFC 3268、2002 年 6 月。

13.2. Informative References

13.2. 参考引用

[14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.

[14] Khare, R. および S. Lawrence、「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] Fielding, R.、Gettys, J.、Mogul, J.、Frystyk, H.、Masinter, L.、Leach, P.、および T. Berners-Lee、「ハイパーテキスト転送プロトコル -- 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] Moore, K.、「基板としての HTTP の使用について」、BCP 56、RFC 3205、2002 年 2 月。

[17] Hollenbeck, S., "EPP TCP Transport", Work in Progress, January 2002.

[17] Hollenbeck, S.、「EPP TCP Transport」、進行中の作業、2002 年 1 月。

[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[18] Rescorla, E.、「HTTP Over TLS」、RFC 2818、2000 年 5 月。

[19] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004.

[19] Newton, A.、「クロスレジストリインターネットサービスプロトコル (CRISP) 要件」、RFC 3707、2004 年 2 月。

[20] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[20] Mealing, M.、「IETF XML Registry」、BCP 81、RFC 3688、2004 年 1 月。

14. Authors' Addresses

14. 著者の住所

Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA

   Phone: +1 703 948 3382
   EMail: anewton@verisignlabs.com; andy@hxr.us
   URI:   http://www.verisignlabs.com/

Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany

Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 フランクフルトドイツ

   EMail: sanz@denic.de
   URI:   http://www.denic.de/

Full Copyright Statement

完全な著作権に関する声明

著作権 (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.

この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネットエンジニアリングタスクフォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。

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.

IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC エディター機能の資金は現在、インターネット協会によって提供されています。

RFC 3983 - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) 日本語訳

1. Introduction and Motivations

1. 紹介と動機

2. Document Terminology

2. 文書用語

3. BEEP Profile Identification

3. BEEP プロファイルの識別

4. IRIS Message Packages

4. IRIS メッセージ パッケージ

5. IRIS Message Patterns

5. IRIS メッセージ パターン

5.1. Registry Dependent Patterns

5.1. レジストリに依存するパターン

5.2. Default Pattern

5.2. デフォルトパターン

6. Server Authentication Methods

6. サーバーの認証方法

6.1. Registry Dependent Methods

6.1. レジストリに依存するメソッド

6.2. Basic Server Authentication Method

6.2. 基本サーバー認証方式

7. IRIS Transport Mapping Definitions

7. IRIS トランスポート マッピングの定義

7.1. URI Scheme

7.1. URIスキーム

7.2. Application Protocol Label

7.2. アプリケーションプロトコルラベル

7.3. Allowable Character Sets

7.3. 使用できる文字セット

7.4. BEEP Mapping

7.4. ビープ音のマッピング

8. Registrations

8. 登録

8.1. BEEP Profile Registration

8.1. BEEPプロファイルの登録

8.2. URI Scheme Registration

8.2. URIスキームの登録

8.3. Well-Known TCP Port Registration

8.3. 既知の TCP ポートの登録

8.4. S-NAPTR Registration

8.4. S-NAPTR登録

9. Registry Definition Checklist

9. レジストリ定義チェックリスト

10. Internationalization Considerations

10. 国際化に関する考慮事項

11. IANA Considerations

11. IANAの考慮事項

12. Security Considerations

12. セキュリティに関する考慮事項

13. References

13. 参考文献

13.1. Normative References

13.1. 引用文献

13.2. Informative References

13.2. 参考引用

14. Authors' Addresses

14. 著者の住所

4. IRIS メッセージパッケージ

5. IRIS メッセージパターン

7. IRIS トランスポートマッピングの定義