RFC3983 日本語訳
3983 Using the Internet Registry Information Service (IRIS) over theBlocks Extensible Exchange Protocol (BEEP). A. Newton, M. Sanz. January 2005. (Format: TXT=23466 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Newton
Request for Comments: 3983 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 3983年のベリサインInc.カテゴリ: 標準化過程M.サンスDENIC eG2005年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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).
このドキュメントはインターネットRegistry情報Service(IRIS)に、アプリケーション輸送基板としてBlocks Extensible Exchangeプロトコル(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
1. 序論と動機. . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . 3 3を記録してください。 プロフィール識別. . . . . . . . . . . . . . . . . 3 4を鳴らしてください。 虹彩メッセージパッケージ. . . . . . . . . . . . . . . . . . . . 4 5。 虹彩メッセージパターン. . . . . . . . . . . . . . . . . . . . 4 5.1。 登録に依存するパターン。 . . . . . . . . . . . . . . 4 5.2. デフォルトパターン。 . . . . . . . . . . . . . . . . . . . . 4 6. サーバー証明メソッド. . . . . . . . . . . . . . . . 5 6.1。 登録に依存するメソッド。 . . . . . . . . . . . . . . 5 6.2. 基幹サーバ認証方法。 . . . . . . . . . . 5 7. 定義. . . . . . . . . . . . . . 6 7.1を写像する虹彩輸送。 URI体系. . . . . . . . . . . . . . . . . . . . . . . 6 7.2。 アプリケーション・プロトコルラベル. . . . . . . . . . . . . . . 6 7.3。 許容できる文字コード. . . . . . . . . . . . . . . . 6 7.4。 マッピング. . . . . . . . . . . . . . . . . . . . . . 6 8を鳴らしてください。 登録証明書. . . . . . . . . . . . . . . . . . . . . . . . 6 8.1。 プロフィール登録を鳴らしてください。 . . . . . . . . . . . . . . . 6 8.2. URI体系登録。 . . . . . . . . . . . . . . . . 7
Newton & Sanz Standards Track [Page 1] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[1ページ]。
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
8.3. よく知られるTCPは登録. . . . . . . . . . . . 7 8.4を移植します。 S-NAPTR登録. . . . . . . . . . . . . . . . . . 8 9。 登録定義チェックリスト. . . . . . . . . . . . . . . . 8 10。 国際化問題. . . . . . . . . . . . . 8 11。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 12。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1。 引用規格. . . . . . . . . . . . . . . . . . 10 13.2。 有益な参照. . . . . . . . . . . . . . . . . 11作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 11の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 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の選択は要件をサポートするすべての必要な特徴で既存の、そして、よく理解されているプロトコルを再利用する必要性によって主として動かされます。 これは、サーバとクライアントの両方を組み立てることにおける使用のための豊富なツールキットとデバッグギヤをimplementersに与えて、オペレータが展開の問題の既存の経験を当てはまるのを許容するでしょう。 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の間の混乱につながるかもしれないいかなる他のメソッドと伝統的なWWWアプリケーションも混ぜ合わせて。 また、RFC3205[16]にスペルアウトされたガイドラインを固く守ることを超えて、HTTPの使用はすぐに上告を浸食する他の多くの挑戦を提供します。 例えば、HTTPとのTLS[4]の適切な使用はRFC2817[14]によって定義されますが、通常、RFC2818[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]によって指定されたそれなどのTCPの直接上のIRISの使用は独身のクライアントが質問を処理する際に異なったパラメタで作動する複数のサーバを横断するかもしれない紹介アプリケーションで必要であるクライアント交渉の特性を提供しません。
Newton & Sanz Standards Track [Page 2] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[2ページ]。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[5])で説明されるように本書では解釈されることであるべきです。
3. BEEP Profile Identification
3. ビープ音プロフィール識別
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登録タイプ(URNである)でBEEPプロフィール識別子は、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].
IRISの規則に応じて、簡略化されてください。登録タイプURN MUST、([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プロフィール識別子に関する例です。 マッチへのそれが指定したIRISのバージョンを特定する、「つぼ:iana:params:xml:ナノ秒: 登録があるiris1"がURNをタイプする、「つぼ:iana:params:xml:ナノ秒: dreg1":、」
http://iana.org/beep/iris1/dreg1
http://iana.org/beep/iris1/dreg1
The full ABNF [8] follows, with certain values included from IRIS [6]:
ある値がIRIS[6]から含まれている状態で、完全なABNF[8]は続きます:
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
指定されるとしての虹彩による」 指定されて、」 ユリの輪郭を描いている」 /=" http://iana.org/beep/ "虹彩つぼ登録つぼのabbrev abbrevが//と等しい虹彩つぼのabbrev虹彩登録つぼの「プロフィール=プロフィール-uri」/abbrev=//
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で開けられたどんなチャンネルのすべての広告を出している登録タイプのためにも質問を光栄に思わなければなりません。
Newton & Sanz Standards Track [Page 3] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[3ページ]。
4. IRIS Message Packages
4. 虹彩メッセージパッケージ
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登録のための要求と応答を含んでいて、IRISのためのBEEPプロフィールはXML[1]を伝えます。 [9] RFC3023[11]によると、「アプリケーション/xml」のメディアタイプを使用して、ユニコードとしてこれらの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プロセッサがUTF-8とUTF-16[9]encodingsの両方を認識するのが強いられます。 属性が宣言で「コード化」であることによって、XMLはメカニズムに他の文字符号化を特定して、使用させます。 この属性かバイト・オーダー・マーク(BOM)の欠如はUTF-8コード化のデフォルトを示します。 したがって、互換性理由、およびRFC2277[12]あたりUTF-8の使用はこの輸送マッピングがあるRECOMMENDEDです。 UTF-16はOPTIONALです。 他のencodingsを使用してはいけません。
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応答で参照をつけられる2値画像)でない他のメッセージパッケージを定義するかもしれません。
5. IRIS Message Patterns
5. 虹彩メッセージパターン
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).
それぞれの登録タイプがaによって定義されるので、BEEPプロフィールを切り離してください。([6]) それぞれの登録タイプが異なったメッセージパターンを定義するかもしれないのを確実にしてください。 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.
しかしながら、<lookupEntity>質問がIRISにある状態で、それぞれの登録タイプは、使用のためにデフォルトパターンが(セクション5.2)であるとサポートすることができなければなりません。
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].
クライアントは、有効な虹彩XMLインスタンスを含む「エムエスジー」メッセージを使用することによって、要求を送ります。 "RPY"メッセージが有効な虹彩XMLインスタンスを含んでいて、サーバは反応します。 「間違えてください」というメッセージは送付欠点コードに使用されます。 許容できる欠点コードのリストはBEEP[2]にリストアップされています。
Newton & Sanz Standards Track [Page 4] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[4ページ]。
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メカニズムを使用することによって、サーバへの権威の名前を提示しなければなりません。 例えば、URI「虹彩: dreg1//com/ドメイン/example.com」が決議されているなら、クライアントはBEEPセッション具体化の間、"com"serverName=属性を使用するでしょう。
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]であるに違いない。 この証明書はタイプdNSNameのsubjectDNか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.
1. dNSNameのいずれもsubjectAltNameをタイプします。 2. 唯一それぞれの'dc'コンポーネントが権威名からラベルを表す'dc'コンポーネント(例えば、example.comはdc=例です、dc=com)から成るsubjectDN。 3. 最も左のコンポーネントが権威の名前を含む'cn'コンポーネントであるsubjectDN。 ワイルドカードキャラクタ('*')は名前の最も左のラベルとして'cn'コンポーネントに使用されるかもしれません。
Newton & Sanz Standards Track [Page 5] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[5ページ]。
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. 定義を写像する虹彩輸送
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".
URIは名前を計画します。IRIS MUSTの上でBEEPに特定であるのは、"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のマッピングは本書ではRFC3080[2]に特定です。 このマッピングは指定されるとしてのRFC3081[3]によるTCPを使用しなければなりません。
8. Registrations
8. 登録証明書
8.1. BEEP Profile Registration
8.1. ビープ音プロフィール登録
Profile Identification: http://iana.org/beep/iris1
識別の輪郭を描いてください: http://iana.org/beep/iris1
Messages exchanged during Channel Creation: none
メッセージはChannel Creationの間、交換しました: なし
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によって定義されるIRIS XMLインスタンス[6]
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>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt;、マルコス Sanz <sanz@denic.de 、gt。
Newton & Sanz Standards Track [Page 6] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[6ページ]。
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]
文字符号化問題: 定義されたコネRFC2396として[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]
関連刊行物: ビープ音[2]と虹彩[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt;、マルコス Sanz <sanz@denic.de 、gt。
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.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション3、4、および5では、定義されます。
Functions: defined in IRIS [6]
機能: IRISでは、定義されます。[6]
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: IRIS over BEEP
提案された名前: ビープ音の上の虹彩
Short name: iris.beep
省略名: iris.beep
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt;、マルコス Sanz <sanz@denic.de 、gt。
Newton & Sanz Standards Track [Page 7] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[7ページ]。
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]
関連刊行物: ビープ音[2]と虹彩[6]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz <sanz@denic.de>
問い合わせ先: アンドリュー Newton <andy@hxr.us 、gt;、マルコス Sanz <sanz@denic.de 、gt。
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.
ImplementersはIRIS[6]、BEEP[2]、およびTLS[4]によって与えられたセキュリティ問題を百も承知しているべきです。 TLSの使用によるサーバ証明に関して、セクション6を見てください。
Newton & Sanz Standards Track [Page 8] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[8ページ]。
Clients SHOULD be prepared to use the following BEEP tuning profiles:
クライアントSHOULD、以下の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 暗号化にTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。
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 暗号化とユーザー認証にクライアントサイド証明書があるTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
cipher -- for encryption. See [13].
o 暗号化にTLS_RSA_WITH_AES_128_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。 [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 暗号化とユーザー認証にクライアントサイド証明書があるTLS_RSA_WITH_AES_128_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。 [13]を見てください。
o http://iana.org/beep/TLS using the TLS_RSA_WITH_AES_256_CBC_SHA
cipher -- for encryption. See [13].
o 暗号化にTLS_RSA_WITH_AES_256_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。 [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 暗号化とユーザー認証にクライアントサイド証明書があるTLS_RSA_WITH_AES_256_CBC_SHA暗号を使用する http://iana.org/beep/TLS 。 [13]を見てください。
Anonymous client access SHOULD be considered in one of two methods:
考えられて、2つのメソッドの1つで匿名のクライアントはSHOULDにアクセスします:
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は操作の標準のコースとして紹介メカニズムを含んでいます。 しかしながら、注意は取って、そのユーザー認証メカニズムが信頼されていないサーバへの資格証明書をユーザに手渡さないということであるべきです。 したがって、クライアントSHOULD NOTは http://iana.org/beep/SASL/PLAIN チューニングプロフィールを使用します。 SASL/PLAINによって指定されるように、最初にTCPセッション(例えば、 http://iana.org/beep/TLS チューニングプロフィールなどの)を暗号化しないで、クライアントは http://iana.org/beep/SASL/PLAIN チューニングプロフィールを使用してはいけません。
Newton & Sanz Standards Track [Page 9] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[9ページ]。
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]ワールドワイドウェブコンソーシアム、「拡張マークアップ言語(XML)1インチ、W3C XML1998年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.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[3] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[4] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Newton, A. and M. Sanz, "IRIS: The Internet Registry
Information Service (IRIS) Core Protocol", RFC 3981, January
2005.
[6] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)コアプロトコル」、RFC3981、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[9] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[9] ユニコード共同体、「ユニコード規格、バージョン3インチ、ISBN0-201-61633-5、2000、<、ユニコード規格、バージョン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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[11] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[11] ムラタとM.とローラン、S.通りとD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[12] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[12]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[13]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
Newton & Sanz Standards Track [Page 10] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[10ページ]。
13.2. Informative References
13.2. 有益な参照
[14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[14]Khare、R.、およびS.ローレンス。
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[16] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC
3205, February 2002.
[16] ムーア、K. 「SubstrateとしてのHTTPの使用」のBCP56、RFC3205、2002年2月。
[17] Hollenbeck, S., "EPP TCP Transport", Work in Progress, January
2002.
[17] S.、「EPP TCP輸送」というHollenbeckは進歩、2002年1月に働いています。
[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[18] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[19] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", RFC 3707, February 2004.
[19] ニュートン、A.、「交差している登録インターネットのサービスプロトコル(はっきりする)の要件」、RFC3707、2004年2月。
[20] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[20] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
14. Authors' Addresses
14. 作者のアドレス
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
アンドリューL.ニュートンベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/
以下に電話をしてください。 +1 3382年の703 948メール: anewton@verisignlabs.com; andy@hxr.us ユリ: http://www.verisignlabs.com/
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany
マルコスサンスDENIC eG Wiesenhuettenplatz26D-60329フランクフルトドイツ
EMail: sanz@denic.de URI: http://www.denic.de/
メール: sanz@denic.de ユリ: http://www.denic.de/
Newton & Sanz Standards Track [Page 11] RFC 3983 IRIS-Beep January 2005
ニュートンとサンスStandardsは虹彩ビープ音2005年1月にRFC3983を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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 & Sanz Standards Track [Page 12]
ニュートンとサンス標準化過程[12ページ]
一覧
スポンサーリンク
