Network Working Group L. Daigle
Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Domain-Based Application Service Location Using SRV RRs and the
Dynamic Delegation Discovery Service (DDDS)
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 memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
このメモは、硬質ドメインの命名規則（いわゆる名ハック）に依存することなく、サービスの場所を可能にするアプリケーション・サービス・ネーミングのための一般的なメカニズムを定義します。提案は、サーバーとポートをターゲットに動的ドメイン名、アプリケーション・サービス名、およびアプリケーションプロトコルをマッピングするためのダイナミックな委譲発見システム（DDDS）アプリケーションを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application to map domain name, application service name, and application protocol dynamically to target server and port.
このメモは、硬質ドメインの命名規則（いわゆる名ハック）に依存することなく、サービスの場所を可能にするアプリケーション・サービス・ネーミングのための一般的なメカニズムを定義します。サーバおよびポートを標的とするように動的にドメイン名、アプリケーション・サービス名、およびアプリケーションプロトコルをマッピングするためのアプリケーション - （[4]を参照DDDS）提案は、ダイナミックな委譲発見システムが定義します。
As discussed in section 5, existing approaches to using DNS records for dynamically determining the current host for a given application service are limited in terms of the use cases supported. To address some of the limitations, this document defines a DDDS Application to map service+protocol+domain to specific server addresses by using both NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as a more general version of the use of SRV and/or a very restricted application of the use of NAPTR resource records.
セクション5で説明したように、動的に与えられたアプリケーションサービスの現在のホストを決定するためのDNSレコードを使用する既存のアプローチは、サポートされているユースケースの点で制限されています。制限のいくつかに対処するため、この文書はDDDSアプリケーションがNAPTR [5]とSRV（[3]）DNSリソースレコードの両方を使用して、特定のサーバアドレスへのサービス+プロトコル+ドメインをマッピングするために定義します。これは、SRVおよび/またはNAPTRリソースレコードを使用するのが非常に制限されたアプリケーションを使用するのがより一般的なバージョンとみなすことができます。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
The precise details of the specification of this DDDS application are given in Section 6. This section defines the usage of the DDDS application.
このDDDSアプリケーションの仕様の正確な詳細は、このセクションでは、DDDSのアプリケーションの使用状況を定義するセクション6に記載されています。
"Application service" is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag. For example, retrieving mail is a type of application service that can be implemented by different application-layer protocols (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered for it. (Note that this has not been done, and there are no plans to do so at the time of this writing.)
「アプリケーションサービス」は、それを提供するために使用されるプロトコルに依存しないアプリケーションのいくつかのタイプ、の総称です。各アプリケーションサービスは、IANA登録タグに関連付けられます。たとえば、メールを取得すると、異なるアプリケーション層プロトコル（例えば、POP3、IMAP4）によって実現することができるアプリケーションサービスの種類です。こうした「RetMail」などのタグは、それを登録することができます。 （これが行われていないことに注意してください、この記事の執筆時点ではそうする予定はありません。）
An "application protocol" is used to implement the application service. These are also associated with IANA-registered tags. Using the mail example above, "POP3" and "IMAP4" could be registered as application protocol tags. If multiple transports are available for the application, separate tags should be defined for each transport.
「アプリケーションプロトコル」は、アプリケーションサービスを実装するために使用されます。これらは、IANA登録タグと関連しています。上記メールの例を使用して、「POP3」と「IMAP4は」アプリケーションプロトコルタグとして登録することができます。複数のトランスポートは、アプリケーションのために利用可能である場合、別個のタグは、各トランスポートのために定義されるべきです。
The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "RetMail:POP3" would be sufficient for a client to identify a server with which it can communicate.
それが通信可能なサーバを識別するためのクライアントのために十分であろう。その意図は、アプリケーションサービスとプロトコルタグの組み合わせが知られているペア（例えば、「POP3はRetMail」を見つけること十分に特異的であるべきであるということです。
Some protocols support multiple application services. For example, LDAP is an application protocol and can be found supporting various services (e.g., "whitepages", "directory enabled networking".
一部のプロトコルでは、複数のアプリケーションサービスをサポートしています。たとえば、LDAPは、アプリケーションプロトコルであり、様々なサービス（例えば、「ホワイトページ」をサポートし、「ディレクトリ対応ネットワーキング」見つけることができます。
As defined in section 6, NAPTR records are used to store application service+protocol information for a given domain. Following the DDDS standard, these records are looked up, and the rewrite rules (contained in the NAPTR records) are used to determine the successive DNS lookups until a desirable target is found.
セクション6で定義されているように、NAPTRレコードは、所与のドメインのアプリケーションサービス+プロトコル情報を格納するために使用されます。 DDDS標準以下、これらのレコードが検索され、そして（NAPTRレコードに含まれる）書き換え規則は、所望のターゲットが見つかるまで連続するDNSルックアップを決定するために使用されます。
For the rest of this section, refer to the set of NAPTR resource records for example.com, shown in the figure below, where "WP" is the imagined application service tag for "white pages" and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
このセクションの残りの部分については、「WP」は「ホワイトページ」と「EM」の想像アプリケーションサービスタグは、アプリケーション・サービス・タグであり、下図に示すexample.comのNAPTRリソースレコードのセット、を参照してください。想像「拡張メッセージング」アプリケーションサービスのため。
example.com. ;; order pref flags IN NAPTR 100 10 "" "WP:whois++" ( ; service "" ; regexp bunyip.example. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "" "EM:protA" ( ; service "" ; regexp someisp.example. ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement )
example.com。 ;; NAPTR 100 10 "" "WP：WHOIS ++" で県フラグを注文（; ";正規表現bunyip.example;置換NAPTR 100 20にサービス"） "秒" "WP：LDAP"（;サービス "";正規表現_ldap._tcp .myldap.example.com; NAPTR 200 10 "" "EM：PROTA" IN置換）; "NAPTR 200 30 IN置換）;正規表現someisp.example。 "" "EM：protB" サービス"（。サービス「」;正規表現myprotB.example.com;交換用）
A client retrieves all the NAPTR records associated with the target domain name (example.com, above). These are to be sorted in terms of increasing ORDER and increasing PREF within each ORDER.
クライアントは、ターゲット・ドメイン名（example.com、上記）に関連するすべてのNAPTRレコードを取得します。これらは、ORDERを増やし、各ORDER内PREFを上げるという点でソートされることになります。
Starting with the first sorted NAPTR record, the client examines the SERVICE field to find a match. In the case of the S-NAPTR DDDS application, this means a SERVICE field that includes the tags for the desired application service and a supported application protocol.
最初のソートされたNAPTRレコードから始めて、クライアントが一致するものを見つけるために、SERVICEフィールドを調べます。 S-NAPTR DDDSのアプリケーションの場合、これは、所望のアプリケーションサービスとサポートされるアプリケーションプロトコルのタグを含むサービスフィールドを意味します。
If more than one NAPTR record matches, they are processed in increasing sort order.
複数のNAPTRレコードが一致した場合、彼らはソート昇順に処理されます。
A NAPTR record with an empty FLAG field is "non-terminal" -- that is, more NAPTR RR lookups are to be performed. Thus, to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is used as the target of the next DNS lookup -- for NAPTR RRs.
空のフラグフィールドを持つNAPTRレコードは、「非末端」である - つまり、より多くのNAPTR RRルックアップが実行されます。 NAPTRのRRのために - したがって、S-NAPTRにおける空フラグフィールドとNAPTRレコードを処理するために、予備フィールドは、次のDNSルックアップの対象として使用されます。
In S-NAPTR, the only terminal flags are "S" and "A". These are called "terminal" NAPTR lookups because they denote the end of the DDDS/NAPTR processing rules. In the case of an "S" flag, the REPLACEMENT field is used as the target of a DNS query for SRV RRs, and normal SRV processing is applied. In the case of an "A" flag, an address record is sought for the REPLACEMENT field target (and the default protocol port is assumed).
S-NAPTRにおいて、端末のみフラグは「S」と「A」です。彼らはDDDS / NAPTR処理ルールの終わりを示すため、これらは、「ターミナル」NAPTRルックアップと呼ばれています。 「S」フラグの場合には、置換フィールドは、SRV資源レコードのDNSクエリの対象として使用され、通常のSRV処理が適用されます。 「A」フラグの場合には、アドレスレコードは、置換フィールドの目標のために求められている（そして、デフォルトのプロトコルポートが仮定されます）。
As shown in the example set above, it is possible to have multiple possible targets for a single application service+protocol pair. These are to be pursued in order until a server is successfully contacted or all possible matching NAPTR records have been successively pursued through terminal lookup and server contact. That is, a client must backtrack and attempt other resolution paths in the case of failure.
上記の例に示すように、単一のアプリケーション・サービス+プロトコルのペアのための複数の可能なターゲットを有することが可能です。これらは、サーバーが正常に接触されるか、すべての可能なマッチングのNAPTRレコードが連続して、端末のルックアップとサーバの接触によって追求されてきたまで順番に追求すべきです。つまり、クライアントはバックトラックや障害が発生した場合に、他の解像度パスを試みなければなりません。
"Failure" is declared, and backtracking must be used, when
「失敗は」と、宣言され、バックトラックを使用する必要があります
o the designated remote server (host and port) fails to provide appropriate security credentials for the *originating* domain;
O指定されたリモートサーバー（ホストおよびポート）*元の*ドメインのための適切なセキュリティ資格情報を提供するために失敗しました。
o connection to the designated remote server otherwise fails -- the specifics terms of which are defined when an application protocol is registered; or
指定されたリモートサーバーへO接続は、そうでなければ失敗 - アプリケーションプロトコルが登録されている場合の用語が定義されている内容を、または
o the S-NAPTR-designated DNS lookup fails to yield expected results -- e.g., no A RR for an "A" target, no SRV record for an "S" target, or no NAPTR record with appropriate application service and protocol for a NAPTR lookup. Except in the case of the very first NAPTR lookup, this last is a configuration error: the fact that example.com has a NAPTR record pointing to "bunyip.example" for the "WP:Whois++" service and protocol means the administrator of example.com believes that service exists. If bunyip.example has no "WP:Whois++" NAPTR record, the application client MUST backtrack and try the next available "WP:Whois++" option from example.com. As there is none, the whole resolution fails.
S-NAPTR指定DNSルックアップが期待される結果を得るために失敗したO - 例えば、「A」の目標のためノーRR、「S」の目標、またはのための適切なアプリケーションサービスとプロトコルで無NAPTRレコードの無SRVレコードNAPTR検索。非常に最初のNAPTR検索の場合を除いて、この最後は、構成エラーがある：example.com「はWP：Whoisの++」の「bunyip.example」に向いてNAPTRレコード持っているという事実のサービスとプロトコルは例の管理者を意味し、 .COMは、サービスが存在することを考えています。 bunyip.exampleはない「WP：Whoisの++」がない場合：example.comからオプションNAPTRレコードを、アプリケーション・クライアントは、次の利用可能な「Whoisの++ WP」をバックトラックとしようとする必要があります。何も存在しないため、全体の解像度が失敗します。
An application client first queries for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
名前のアプリケーション・サービスのドメインのためのNAPTR RRのためのアプリケーションクライアント最初のクエリ。最初のDNSクエリは、元のターゲット・ドメイン（example.com、上記）にNAPTRのRRのためのものです。
In the case of an application client that supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol.
アプリケーションが正常に接続またはがあるまで、与えられたアプリケーションサービスのために複数のプロトコルをサポートするアプリケーションクライアントの場合、それは、すべての潜在的なPREF内の端末の検索とORDERランキングを模索し、完全に1つのプロトコル用のS-NAPTR解像度を追求しなければなりませんそのプロトコルのためにこれ以上の可能性。
That is, the client MUST NOT start looking for one protocol, observe that a successive NAPTR RR set supports another of its preferred protocols, and continue the S-NAPTR resolution based on that protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there is no reason to believe that it does so on behalf of example.com (as there is no such pointer in example.com's NAPTR RR set).
つまり、クライアントは、1つのプロトコルを探し始める連続のNAPTR RRセットはその好ましいプロトコルの別をサポートしていることを観察し、そのプロトコルに基づいたS-NAPTRの解像度を継続してはなりません。例えば、someisp.exampleはプロトコル「ProtB」と「EM」のサービスを提供しています場合でも、example.comのNAPTRのRRセットには、このようなポインタがないので、それは（example.comに代わってそうすると信じる理由はありません）。
It MAY choose which protocol to try first based on its own preference, or on the PREF ranking in the first set of NAPTR records (i.e., those for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
これは、最初に自身の好みに基づいて試してみたプロトコルを選択、またはMAY PREFがNAPTRレコードの最初のセットでランキングに（すなわち、ターゲットという名前のドメイン用のもの）。しかし、選択されたプロトコルは、最初のNAPTR RRセットにリストされなければなりません。
It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid-resolution.
これは、上記の要件は、それぞれ独立して、プロトコルに適用される場合には、複数のプロトコルのための同時DDDSの決議を実行することもできます。つまり、プロトコル半ば解像度を切り替えないでください。
The purpose of S-NAPTR is to provide application standards developers with a more powerful framework (than SRV RRs alone) for naming service targets, without requiring each application protocol (or service) standard to define a separate DDDS application.
S-NAPTRの目的は、別個のDDDSアプリケーションを定義するために、各アプリケーションプロトコル（またはサービス）標準を必要とすることなく、サービス・ターゲットの命名（単独で、SRV RRを超える）より強力なフレームワークとアプリケーション標準の開発を提供することです。
Note that this approach is intended specifically for use when it makes sense to associate services with particular domain names (e.g., e-mail addresses, SIP addresses, etc). A non-goal is having all manner of label mapped into domain names in order to use this.
それは、特定のドメイン名（例えば、電子メールアドレス、SIPアドレスなど）を備えたサービスを関連付けることは理にかなっていたときに、このアプローチを使用するために意図されていることに注意してください。非目標は、これを使用するためには、ドメイン名にマッピングされたラベルのすべての方法を持っています。
This document does not address how to select the domain for which the service+protocol is being sought. Other conventions will have to define how this might be used (e.g., new messaging standards can define what domain to use from their URIs or how to step down from foobar.example.com to example.com, if applicable).
この文書では、サービス+プロトコルが求められているドメインを選択する方法を扱っていません。その他の規則は（例えば、新しいメッセージング標準は、どのようなドメイン自分のURIから使用するか、どのように該当する場合、example.comにfoobar.example.comからステップダウンするを定義することができます）、これは使用されるかもしれない方法を定義する必要があります。
Although this document proposes a DDDS application that does not use all the features of NAPTR resource records, it is not intended to imply that DNS resolvers should fail to implement all aspects of the NAPTR RR standard. A DDDS application is a client use convention.
このドキュメントはNAPTRリソースレコードのすべての機能を使用しないDDDSアプリケーションを提案しているが、DNSリゾルバがNAPTR RRの標準のすべての側面を実装するために失敗することを意味するものではありません。 DDDSアプリケーションは、クライアントの利用規約です。
The rest of this section outlines the specific elements that protocol developers must determine and document to make use of S-NAPTR.
この節の残りの部分ではS-NAPTRを利用するために、特定のプロトコルの開発者が決定しなければならないことを要素と文書の概要を説明します。
Application protocol developers who wish to make use of S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
第7章で説明したようにS-NAPTRの使用をしたいアプリケーションプロトコルの開発者は、関連するすべてのアプリケーションサービスとアプリケーションプロトコルタグを登録するための規定を作る必要があります。
One other important aspect that must be defined is the expected behaviour for interacting with the servers that are reached via S-NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? What should it consider a failure that causes it to return to the S-NAPTR process to determine the next serviceable target, which by definition will have a lower preference ranking.
定義されなければならないもう1つの重要な側面は、S-NAPTRを介して到達しているサーバーとやり取りするための正常な動作です。具体的には、どのような状況の下で、クライアントは、S-NAPTR経て発見されたターゲットを再試行する必要がありますか？何それは定義によって低い優先順位を持つことになり、次が修理対象を決定するためにS-NAPTRプロセスに戻るには、原因となる故障を考慮すべきです。
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it try the next-preferred target in the S-NAPTR chain of resolution? Should it only try the next-preferred target if it receives a protocol-specific permanent error message?
クライアントがサーバからのメッセージを「接続が拒否した」取得する場合たとえば、それは時間の一部（プロトコル依存）時間にリトライする必要がありますか？それとも、解像度のS-NAPTRチェーン内の次の優先対象を試してみてください？それは、プロトコル固有の永続的なエラーメッセージを受信した場合にのみ、次の優先対象を試してみてください？
The most important thing is to select one expected behaviour and document it as part of the use of S-NAPTR.
最も重要なことは、1つの期待される動作を選択し、S-NAPTRの使用の一環として、それを文書化することです。
As noted earlier, failure to provide appropriate credentials to identify the server as being authoritative for the original target domain is always considered a failure condition.
先に述べたように、元のターゲットドメインの権威あるものとしてサーバーを識別するために、適切な資格情報を提供するために、失敗は、常に障害状態と考えられています。
As noted in section 8, use of the DNS for server location increases the importance of using protocol-specific handshakes to determine and confirm the identity of the server that is eventually reached.
セクション8で述べたように、サーバーの場所のためのDNSを使用するかを決定し、最終的に到達しているサーバーの身元を確認するために、プロトコル固有のハンドシェイクを使用することの重要性を増大させます。
Therefore, application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR.
クライアントは、S-NAPTRにより求めサーバーに接続したときしたがって、S-NAPTRを使用してアプリケーションプロトコルの開発者は、予想される識別ハンドシェイクのメカニズムを識別すべきです。
Although S-NAPTR aims to provide a "straightforward" application of DDDS and use of NAPTR records, it is still possible to create very complex chains and dependencies with the NAPTR and SRV records.
S-NAPTRはDDDSとNAPTRレコードの使用の「直接的な」アプリケーションを提供することを目的としますが、NAPTRとSRVレコードを持つ非常に複雑なチェーンとの依存関係を作成することは可能です。
Therefore, domain administrators are called upon to use S-NAPTR with as much restraint as possible while still achieving their service design goals.
そのため、ドメイン管理者は、まだ彼らのサービスの設計目標を達成しながら、可能な限り抑制してS-NAPTRを使用することを求めています。
The complete set of NAPTR, SRV, and A RRs "reachable" through the S-NAPTR process for a particular application service can be thought of as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or SRV records; each SRV record points to several A record lookups. Even though a particular client can "prune" the tree to use only those records referring to application protocols supported by the client, the tree could be quite deep, and retracing the tree to retry other targets can become expensive if the tree has many branches.
特定のアプリケーション・サービスのためのNAPTR、SRV、およびS-NAPTRプロセスを通じてのRR「到達可能」の完全なセットは、「ツリー」と考えることができます。よりNAPTRまたはSRVレコードに取り出されポイント各NAPTRのRR。いくつかのレコード検索に各SRVレコードがポイント。特定のクライアントがクライアントによってサポートされるアプリケーションプロトコルを参照するレコードのみを使用するツリーを「プルーン」ことができるにもかかわらず、ツリーがかなり深くすることができ、木は多くの枝を持っている場合は他のターゲットを再試行してツリーを辿りことは高価になることができます。
Therefore,
そのため、
o fewer branches is better: For both NAPTR and SRV records, provide different targets with varying preferences where appropriate (e.g., to provide backup services) but don't look for reasons to provide more; and
O少ない枝は良いです：両方NAPTRとSRVレコードの場合、様々な好みで異なるターゲットを提供し、適切な場合（例えば、バックアップサービスを提供するために）が、理由が多くを提供するために見ていません。そして
o shallower is better: Avoid using NAPTR records to "rename" services within a zone. Use NAPTR records to identify services hosted elsewhere (i.e., where you cannot reasonably provide the SRV records in your own zone).
O浅いが良いです：ゾーン内のサービスの「名前の変更」するNAPTRレコードを使用しないでください。他の場所でホストされたサービスを識別するためにNAPTRレコードを使用します（つまり、どこが合理的に自分自身のゾーンにSRVレコードを提供することはできません）。
To understand DDDS/NAPTR properly, an implementor must read [4]. However, the most important aspect to keep in mind is that if the application cannot successfully connect to one target, the application will be expected to continue through the S-NAPTR tree to try the (less preferred) alternatives.
適切DDDS / NAPTRを理解するために、実装者は読まなければならない[4]。しかし、心に留めておくべき最も重要な側面は、アプリケーションが正常に一つのターゲットに接続できない場合、アプリケーションは（あまり好ましくない）代替案を試してS-NAPTRツリーを継続することが予想されるということです。
The basic intended use cases for which S-NAPTR has been developed are as follows
次のようにS-NAPTRが開発された基本的な使用用途例があります
o Service discovery within a domain. For example, this can be used to find the "authoritative" server for some type of service within a domain (see the specific example in section 4.2).
ドメイン内のOサービスの発見。例えば、これは、ドメイン内のサービスのいくつかのタイプの「権威」のサーバを（セクション4.2で具体的な例を参照）を見つけるために使用することができます。
o Multiple protocols. This is already common today as new application services are defined, and is increasingly a problem. It includes the case of extensible messaging (a hypothetical service), which can be offered with multiple protocols (see section 4.3).
O複数のプロトコル。これは、新しいアプリケーションサービスが定義されているとして、すでに今日一般的であり、ますます問題となっています。これは、複数のプロトコル（セクション4.3を参照）で提供することができる拡張可能なメッセージング（仮想サービス）の場合を含みます。
o Remote hosting. Each of the above use cases applies within the administration of a single domain. However, one domain operator may elect to engage another organization to provide an application service. See section 4.4 for an example that cannot be served by SRV records alone.
Oリモートホスティング。上記の使用例それぞれが単一のドメインの管理の中に適用されます。しかし、1つのドメインオペレータは、アプリケーションサービスを提供するために、別の組織に係合するように選ぶことができます。単独のSRVレコードによって提供することができません例えばセクション4.4を参照してください。
There are occasions when it is useful to be able to determine the "authoritative" server for a given application service within a domain. This is "discovery", as there is no a priori knowledge as to whether or where the service is offered; it is therefore important to determine the location and characteristics of the offered service.
ドメイン内の任意のアプリケーション・サービスのための「権威」のサーバを決定することができると便利であるとき機会があります。サービスが提供されているかどうかどこになど何の事前知識がないので、これは、「発見」です。場所や提供するサービスの特性を決定することが重要です。
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.
例えば、特定のアプリケーション（サーバ）に関連付けられたキーまたは証明書を見つけるための一般的な機構を有する成長議論で動作（または場合）特定のドメインが存在します。以下は、特定のドメインのためのアプリケーションキーまたは証明書データを格納するための仮想的なケースである：前提クレデンシャルレジストリ（CredReg）サービスは、/によって運営サーバーの本命（又はためのキーを保持するリーフノードサービスとして定義されていることです）ドメイン。複数のプロトコルは、特定のドメインにサービスを提供するために利用可能であることが想定されます。このDDDSベースのアプローチは、情報を保持しているCredRegサーバを見つけるために使用されます。
Thus, the set of NAPTR records for thinkingcat.example might look like this:
したがって、thinkingcat.exampleのためのNAPTRレコードのセットは次のようになります。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service "" ; regexp theserver.thinkingcat.example. ; replacement
thinkingcat.example。 ;; NAPTR 100 10 "" "LDAP：CREDREG iris.beep" に県旗を注文。;サービス "";正規表現theserver.thinkingcat.example;（交換
Note that the application service might be offered in another domain using a different set of application protocols:
アプリケーションサービスは、アプリケーションプロトコルの異なるセットを使用して、別のドメインで提供されるかもしれないことに注意してください。
anotherdomain.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service "" ; regexp foo.anotherdomain.example. ; replacement )
anotherdomain.example。 ;; NAPTR 100 10 "" に県旗を注文する "CREDREG：iris.lwz：iris.beep"（;サービス "";正規表現foo.anotherdomain.example;交換。）
Extensible messaging, a hypothetical application service, will be used for illustrative purposes. (For an example of a real application service with multiple protocols, see [9] and [10]). Assuming that "EM" was registered as an application service, this DDDS application could be used to determine the available services for delivery to a target.
拡張可能なメッセージング、仮想的なアプリケーションサービスは、例示的な目的のために使用されます。 （複数のプロトコルと実際のアプリケーションサービスの例については、[9]及び[10]参照）。 「EM」はアプリケーションサービスとして登録されたと仮定すると、このDDDSアプリケーションがターゲットへの配信のために利用可能なサービスを決定するために使用することができます。
Two particular features of this hypothetical extensible messaging should be noted:
この仮想的な拡張可能なメッセージングの2つの特定の機能には注意する必要があります。
2. Extensible messaging servers are likely to be operated out of a different domain than that of the extensible messaging address, and servers of different protocols may be offered by independent organizations.
2.拡張メッセージングサーバーは、拡張可能なメッセージングアドレスとは異なるドメインの外に操作される可能性があり、かつ異なるプロトコルのサーバは、独立した組織によって提供されることがあります。
For example, "thinkingcat.example" may support its own servers for the "ProtA" extensible messaging protocol but rely on outsourcing from "example.com" for "ProtC" and "ProtB" servers.
「ProtC」と「ProtB」サーバー用たとえば、「thinkingcat.example」「PROTA」拡張可能なメッセージングプロトコルのために、独自のサーバをサポートするかもしれませんが、「example.com」からアウトソーシングに頼っています。
Using this DDDS-based approach, thinkingcat.example can indicate a preference ranking for the different types of servers for the extensible messaging service, yet the out-sourcer can independently rank the preference and ordering of servers. This independence is not achievable through the use of SRV records alone.
このDDDSベースのアプローチを使用して、thinkingcat.exampleは、拡張可能なメッセージングサービスのためのサーバの異なる種類のランキング好みを示すことができ、まだアウトsourcerは、独立して、サーバの好みや順序をランク付けすることができます。この独立性だけではSRVレコードを使用して達成可能ではありません。
Thus, to find the EM services for thinkingcat.example, the NAPTR records for thinkingcat.example are retrieved:
したがって、thinkingcat.exampleのためのEMサービスを見つけるために、thinkingcat.exampleのためのNAPTRレコードが取得されています。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement ) IN NAPTR 100 30 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement )
thinkingcat.example。 ;; "; ProtB "サービス（" 20 "秒"" EM NAPTR 100において "（置換;サービス "";正規表現_ProtA._tcp.thinkingcat.example。）PROTA：NAPTR 100 IN県フラグ10 "秒"" EMを注文ProtC "（;サービス "";正規表現_ProtC._tcp.example.com;置換）; EM" NAPTR 100 30 "秒" IN置換）;正規表現_ProtB._tcp.example.com。
Then the administrators at example.com can manage the preference rankings of the servers they use to support the ProtB service:
そして、example.comの管理者は、彼らがProtBサービスをサポートするために使用するサーバの優先順位を管理することができます。
_ProtB._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtB._tcp.example.com。 ;;県重ポートターゲット内のSRV 10 0 10001 bigiron.example.com。 SRV、IN 20 0 10001 backup.em.example.com。 SRV、IN 30 0 10001 nuclearfallout.australia-isp.example。
In the Instant Message hosting example in Section 4.3, the service owner (thinkingcat.example) had to host pointers to the hosting service's SRV records in the thinkingcat.example domain.
4.3節でインスタントメッセージのホスティングの例では、サービスの所有者（thinkingcat.example）はthinkingcat.exampleドメインのホスティングサービスのSRVレコードへのポインタをホストする必要がありました。
A better approach is to have one NAPTR RR in the thinkingcat.example domain point to all the hosted services. The hosting domain has NAPTR records for each service to map them to whatever local hosts it chooses (this may change from time to time).
より良いアプローチは、すべてのホスティングサービスにthinkingcat.exampleドメイン・ポイント内の1つのNAPTR RRを持つことです。ホスティングドメインは、それが選択した地域のどんなホストにマッピングするために、各サービスのためのNAPTRレコードを持っている（これは随時変更される可能性があり）。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service "" ; regexp thinkingcat.example.com. ; replacement )
thinkingcat.example。 ;; NAPTR 100 20 "" "：ProtB：EM ProtC" における "（置換;サービス "";正規表現_ProtA._tcp.thinkingcat.example。）PROTA：NAPTR 100 IN県フラグ10 "秒"" EMを注文（;サービス " ";正規表現thinkingcat.example.com;交換）
Then the administrators at example.com can break out the individual application protocols and manage the preference rankings of the servers they use to support the ProtB service (as before):
そして、example.comの管理者は、個々のアプリケーション・プロトコルを破ると、彼らは（以前のように）ProtBサービスをサポートするために使用するサーバの優先順位を管理することができます。
thinkingcat.example.com. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement )
thinkingcat.example.com。 ;; "; ProtB "サービス（" 20 "秒"" EM NAPTR 100において "（置換; ";正規表現_ProtC._tcp.example.com。ProtCサービス"）：NAPTR 100 IN県フラグ10 "秒"" EMを注文;正規表現_ProtB._tcp.example.com;交換）
_ProtC._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtC._tcp.example.com。 ;;県重ポートターゲット内のSRV 10 0 10001 bigiron.example.com。 SRV、IN 20 0 10001 backup.em.example.com。 SRV、IN 30 0 10001 nuclearfallout.australia-isp.example。
Note that the above sections assume that there was one service available (via S-NAPTR) per domain. Often, this will not be the case. Assuming that thinkingcat.example had the CredReg service set up as described in Section 4.2 and had the extensible messaging service set up as described in Section 4.4, then a client querying for the NAPTR RR set from thinkingcat.com would get the following answer:
上記のセクションでは、ドメインごと（S-NAPTRを介して）利用可能な一つのサービスがあったと仮定することに注意してください。多くの場合、これはそうではありません。その後、thinkingcat.comからNAPTR RRセットを照会するクライアントは、次のような答えになるだろう、4.2節で説明し、4.4節で説明したように拡張可能なメッセージングサービスを設定していたとしてthinkingcat.exampleがCredRegサービスを設定していたと仮定すると：
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service "" ; regexp thinkingcat.example.com. ; replacement ) IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service "" ; regexp bouncer.thinkingcat.example. ; replacement )
thinkingcat.example。 ;; NAPTR 100 20 "" "：ProtB：EM ProtC" における "（置換;サービス "";正規表現_ProtA._tcp.thinkingcat.example。）PROTA：NAPTR 100 IN県フラグ10 "秒"" EMを注文（;サービス " ";正規表現thinkingcat.example.com; NAPTR 200における置換）10。 "" "CREDREG：LDAP：虹彩ビープ"（;サービス "";正規表現bouncer.thinkingcat.example;置換）。
Sorting them by increasing "ORDER", the client would look through the SERVICE strings to determine whether there was a NAPTR RR that matched the application service it was looking for, with an application protocol it could use. The client would use the first (lowest PREF) record that matched to continue.
「ORDER」を増やすことで、それらを並べ替え、クライアントはそれを使用することができますアプリケーションプロトコルで、それが探していたアプリケーションサービスをマッチしたNAPTR RRがあったかどうかを判断するために、サービスの列に目を通すだろう。クライアントは、継続して一致した最初の（最低PREF）レコードを使用します。
Consider the example in section 4.3. Visually, the sequence of steps required for the client to reach the final server for a "ProtB" service for EM for the thinkingcat.example domain is as follows:
セクション4.3の例を考えてみましょう。次のように視覚、thinkingcat.exampleドメインのためにEMのための「ProtB」サービスのための最終的なサーバに到達するために、クライアントのために必要な一連の手順は以下のとおりです。
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
1. The name server (NS) for thinkingcat.example is reached with a request for all NAPTR records.
1. thinkingcat.exampleのネームサーバー（NS）は、すべてのNAPTRレコードの要求に達しています。
3. The second NAPTR record matches the desired criteria; it has an "s" flag and a replacement fields of "_ProtB._tcp.example.com". So the client looks up SRV records for that target, ultimately making the request of the NS for example.com.
前記第2のNAPTRレコードは、所望の基準に一致します。それは「S」フラグと「_ProtB._tcp.example.com」の交換用のフィールドがあります。だから、クライアントは最終的にexample.comのNSの要求を行うと、その目標のためにSRVレコードを検索します。
5. The client attempts to reach the server with the lowest PREF in the SRV list -- looking up the A record for the SRV record's target (bigiron.example.com).
SRVレコードのターゲット（bigiron.example.com）のAレコードを検索 - 5.クライアントは、SRVリストの最下位PREFとサーバーに到達しようとします。
6. The example.com NS responds with an error message -- no such machine!
6. example.com NSはエラーメッセージで応答しない - そのような機械を！
7. The client attempts to reach the second server in the SRV list and looks up the A record for backup.em.example.com.
7.クライアントは、SRVのリストの2番目のサーバーに到達しようとするとbackup.em.example.comのAレコードを検索します。
8. The client gets the A record with the IP address for backup.em.example.com from example.com's NS.
8.クライアントがexample.comのNSからbackup.em.example.comのIPアドレスを持つレコードを取得します。
9. The client connects to that IP address, on port 10001 (from the SRV record), by using ProtB over tcp.
9.クライアントは、TCP上のProtBを使用することにより、（SRVレコードから）ポート10001上で、そのIPアドレスに接続します。
11. The client uses ProtB to challenge that this server has credentials to operate the service for the original domain (thinkingcat.example)
11.クライアントは、このサーバーは、元のドメインのサービス（thinkingcat.example）を動作させるための資格情報を持つことに挑戦するProtBを使用しています
Increasingly, application protocol standards use domain names to identify server targets and stipulate that clients should look up SRV resource records to determine the host and port providing the server. This enables a distinction between naming an application service target and actually hosting the server. It also increases flexibility in hosting the target service, as follows:
ますます、アプリケーションプロトコルの標準規格は、サーバーの標的を同定し、クライアントがサーバを提供するホストとポートを決定するためにSRVリソースレコードをルックアップする必要があることを規定するためにドメイン名を使用します。これは、アプリケーションサービスの対象を命名し、実際にサーバをホスティングしているの区別を可能にします。次のようにそれはまた、対象サービスをホストする際の柔軟性を向上させます：
o The server may be operated by a completely different organization without having to list the details of that organization's DNS setup (SRVs).
Oサーバーは、その組織のDNS設定（のSRV）の詳細を一覧表示することなく、完全に異なる組織によって操作されてもよいです。
o Multiple instances can be set up (e.g., for load balancing or secondaries).
O複数のインスタンスは、（ロードバランシングまたはセカンダリのために、例えば）を設定することができます。
o It can be moved from time to time without disrupting clients' access, etc.
Oそれはなど、クライアントのアクセスを中断することなく随時移動することができます
This approach is quite useful, but section 5.1 outlines some of its inherent limitations.
このアプローチは非常に便利ですが、5.1節には固有の限界のいくつかを概説します。
That is, although SRV records can be used to map from a specific service name and protocol for a specific domain to a specific server, SRV records are limited to one layer of indirection and are focused on server administration rather than on application naming. Furthermore, although the DDDS specification and use of NAPTR allows multiple levels of redirection before the target server machine with an SRV record is located, this proposal requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR. These restrictions make the client's resolution process much more predictable and efficient than it would be with some potential uses of NAPTR records. This is dubbed "S-NAPTR" -- a "S"traightforward use of NAPTR records.
SRVレコードは、SRVレコードが間接の一つの層に限定されている、特定のサーバーに特定のドメインのための特定のサービス名とプロトコルからマップするために使用することができ、サーバ管理ではなく、アプリケーションの命名に焦点を当てているが、それは、あります。 SRVレコードとターゲット・サーバー・マシンが設置される前に、NAPTRのDDDS仕様と使用はリダイレクトの複数のレベルを可能にするが、さらに、この提案は、NAPTRのREGEXPフィールドを使用せずに、ドメイン名に厳密にバインドされたNAPTRのサブセットのみを必要とします。これらの制限は、それがNAPTRレコードのいくつかの潜在的な用途となるであろうよりも、クライアントの解決プロセスは、はるかに予測可能かつ効率的にします。 NAPTRレコードの "S" traightforwardの使用 - これは、 "S-NAPTR" と呼ばれています。
An expected question at this point is: this is so similar in structure to SRV records, why are we doing this with DDDS/NAPTR?
この時点で予想される質問です：これはSRVレコードと構造が非常に似ている、なぜ我々はDDDS / NAPTRでこれをやっていますか？
Limitations of SRV include the following:
SRVの制限事項は次のとおりです。
o SRV provides a single layer of indirection; the outcome of an SRV lookup is a new domain name for which the A RR is to be found.
O SRVは、間接の単一層を提供します。 SRVルックアップの結果は、A RRが発見されるべき新しいドメイン名です。
o the purpose of SRV is to address individual server administration issues, not to provide application naming: As stated in [3], "The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups".
O SRVの目的は、アプリケーションの命名を提供するのではなく、個々のサーバー管理の問題に対処することです。で述べたように、[3]、「SRV RRは管理者が少しでホストするためにホストからのサービスを移動するために、単一のドメインに対して複数のサーバーを使用することができますバックアップなどのサービスと他人のためにプライマリサーバ」として、いくつかのホストを指定する大騒ぎと。
o Target servers by "service" (e.g., "ldap") and "protocol" (e.g., "tcp") in a given domain. The definition of these terms implies specific things (e.g., that protocol should be one of UDP or TCP) without being precise. Restriction to UDP and TCP is insufficient for the uses described here.
「サービス」（例えば、「LDAP」）によってOターゲットサーバおよび「プロトコル」（例えば、「TCP」）指定されたドメインです。これらの用語の定義は、正確されることなく（例えば、そのプロトコルがUDPまたはTCPのいずれかでなければならない）特定の事を意味しています。 UDPとTCPへの制限は、ここで説明する用途には不十分です。
The basic answer is that SRV records provide mappings from protocol names to host and port. The use cases described herein require an additional layer -- from some service label to servers that may in be hosted within different administrative domains. We could tweak SRV to say that the next lookup could be something other than an address record, but this is more complex than is necessary for most applications of SRV.
基本的な答えは、SRVレコードは、ホストとポートにプロトコル名からのマッピングを提供するということです。中に異なる管理ドメイン内でホストされるサーバーへのいくつかのサービスラベルから - 本明細書中に記載の使用事例には、追加の層が必要となります。私たちは、次のルックアップは、アドレスレコード以外の何かかもしれないと言うことはSRVを微調整することもできますが、これはSRVのほとんどのアプリケーションで必要以上に複雑です。
This is a trick question. NAPTR records cannot appear in the wild; see [4]. They must be part of a DDDS application.
これはトリックの質問です。 NAPTRレコードは野生で表示することはできません。 [4]を参照。彼らはDDDSアプリケーションの一部でなければなりません。
The purpose here is to define a single, common mechanism (the DDDS application) to use NAPTR when all that is desired is simple DNS-based location of services. This should be easy for applications to use -- a few simple IANA registrations, and it's done.
ここでの目的は、所望される全てのサービスの単純なDNSベースの位置である場合NAPTRを使用する単一の共通機構（DDDSアプリケーション）を定義することです。これは、アプリケーションが使用するのは簡単なはずです - いくつかの簡単なIANA登録をし、それが行われています。
Also, NAPTR has very powerful tools for expressing "rewrite" rules. This power (==complexity) makes some protocol designers and service administrators nervous. The concern is that these rewrites can translate into unintelligible, noodle-like rule sets that are difficult to test and administer.
また、NAPTRは「リライト」のルールを表現するための非常に強力なツールがあります。この電力（==複雑さは）いくつかのプロトコル設計者とサービス管理者が神経質になります。懸念は、これらの書き換えをテストし、管理することが困難な理解不能、麺のようなルール・セットに変換できるということです。
The proposed DDDS application specifically uses a subset of NAPTR's abilities. Only "replacement" expressions are allowed, not "regular expressions".
提案DDDSアプリケーションは、具体的NAPTRの能力のサブセットを使用しています。唯一の「交換」の表現ではなく、「正規表現」許可されています。
6. Formal Definition of <Application Service Location> Application of DDDS
DDDSの<アプリケーションサービスロケーション]> [アプリケーションの6.正式な定義
This section formally defines the DDDS application, as described in [4].
[4]で説明されるように、このセクションでは、正式に、DDDSアプリケーションを定義します。
The Application Unique String is domain label for which an authoritative server for a particular service is sought.
アプリケーション固有文字列は、特定のサービスのための権威サーバが求められているドメインのラベルです。
The "First Well-Known Rule" is identity -- that is, the output of the rule is the Application-Unique String, the domain label for which the authoritative server for a particular service is sought.
「まずよく知られているルールは、」アイデンティティである - つまり、ルールの出力は、アプリケーション固有文字列、特定のサービスのための権威サーバが求められているドメインのラベルです。
The expected output of this Application is the information necessary for a client to connect to authoritative server(s) (host, port, protocol) for a particular application service within a given domain.
このアプリケーションの予想される出力は、所与のドメイン内の特定のアプリケーション・サービスのために認証サーバ（複数可）（ホスト、ポート、プロトコル）に接続するクライアントのために必要な情報です。
This DDDS Application uses only 2 of the Flags defined for the URI/ URN Resolution Application ([6]): "S" and "A". No other Flags are valid.
"S" と "A"：このDDDSアプリケーションは、2 URI / URN解像度アプリケーション（[6]）のために定義されたフラグの使用します。他のフラグが有効ではありません。
Both are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a domain label for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain.
どちらも、端末のルックアップのためのものです。これは、ルールが最後のものであることを、フラグが次のステージがどうあるべきかを決定することを意味します。 「S」フラグは、このルールの出力は、1つ以上のSRV [3]のレコードが存在するドメインのラベルであることを意味します。 「」ルールの出力は、ドメイン名で、そのドメインのアドレスレコードを検索するために使用されるべきであることを意味しています。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
フラグ文字列が空の場合DDDSアルゴリズムと一致して、次のルックアップは、（置換対象のために）別のNAPTRレコードのためです。
Service Parameters for this Application take the form of a string of characters that follow this ABNF ([2]):
このアプリケーションのためのサービスパラメータは、このABNFに続く文字列の形をとる（[2]）：
service-parms = [ [app-service] *(":" app-protocol)] app-service = experimental-service / iana-registered-service app-protocol = experimental-protocol / iana-registered-protocol experimental-service = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-protocol = ALPHA *31ALPHANUM ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." ALPHANUMSYM = ALPHA / DIGIT / SYM ; The app-service and app-protocol tags are limited to 32 ; characters and must start with an alphabetic character. ; The service-parms are considered case-insensitive.
サービスPARMS = [[アプリケーションサービス] *（ "：" アプリケーション・プロトコル）] APP-サービス=実験的なサービス/ IANAに登録されたサービスアプリケーションプロトコル=実験プロトコル/ IANAに登録されたプロトコルの実験サービス= "X-" 1 * 30ALPHANUMSYM実験プロトコル= "X-" 1 * 30ALPHANUMSYM IANAに登録されたサービス= ALPHA * 31ALPHANUMSYM IANAに登録されたプロトコル= ALPHA * 31ALPHANUM ALPHA =％x41-5A /％x61-7A。 -Z / Z-DIGIT =％x30-39。 0-9 SYM =％X2B /％x2D /％x2E。 "+" / " - " / "" ALPHANUMSYM = ALPHA / DIGIT / SYM;アプリケーションサービスとアプリケーションプロトコルタグ32に限定されます。文字と英字で開始する必要があります。 ;サービス-PARMSは、大文字と小文字を区別しないと考えられています。
Thus, the Service Parameters may consist of an empty string, an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
「：」記号従って、サービスパラメータは、空の文字列、アプリケーションサービス、またはで区切られた1つ以上のアプリケーションプロトコル仕様のアプリケーションサービスから構成されてもよいです。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application ([6]). The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). As "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
これと同様であるが、URI DDDSアプリケーションで使用される構文と同じではない（[6]）。 DDDS DNSデータベースには、許容サービス文字列の構文を定義するために、各DDDSアプリケーションが必要です。ここでの構文は、任意のURIスキーム名（[8]を参照）で有効な文字を許可するように拡張されます。 「+」として（RFC3404サービスパラメータ文字列で使用される区切り）、URIスキーム名の許可された文字である「：」ここにセパレータとして選択されています。
The "app-service" must be an IANA-registered service; see Section 7 for instructions on registering new application service tags.
「アプリサービス」IANA-登録されたサービスでなければなりません。新しいアプリケーションサービスタグを登録する方法については、セクション7を参照してください。
The protocol identifiers valid for the "app-protocol" production are standard, registered protocols; see section 7 for instructions on registering new application protocol tags.
「アプリ・プロトコル」の生産のための有効なプロトコル識別子は、登録されたプロトコルの標準です。新しいアプリケーションプロトコルタグを登録する方法については、セクション7を参照してください。
Only substitution Rules are permitted for this application. That is, no regular expressions are allowed.
唯一の置換規則は、このアプリケーションに許可されています。つまり、何の正規表現は許可されません。
At present only one DDDS Database is specified for this Application. [5] specifies that a DDDS Database using the NAPTR DNS resource record contain the rewrite rules. The Keys for this database are encoded as domain-names.
現時点では唯一のDDDSデータベースは、このアプリケーションのために指定されています。 [5] NAPTR DNSリソースレコードを使用してDDDSデータベースが書き換えルールが含まれていることを指定します。このデータベースのキーは、ドメイン名としてエンコードされています。
The First Well-Known Rule produces a domain name, and this is the Key used for the first look up. The NAPTR records for that domain are requested.
まず、よく知られているルールは、ドメイン名を生成し、これが最初のルックアップのために使用されるキーです。そのドメインのNAPTRレコードが要求されています。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of [5] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNSサーバは、フラグの値を解釈し、適切なNAPTR、SRV、またはDNSパケットの追加情報部分のレコードを含めるようにその情報を使用することができます。クライアントは、追加情報を確認することをお勧めしますが、その必要はありません。 NAPTRレコードの詳細情報やDNS応答パケットの追加情報セクションの[5]の追加情報の処理を参照してください。
This document calls for two IANA registries: one for application service tags, and one for application protocol tags.
アプリケーション・サービス・タグの1、およびアプリケーションプロトコルタグの1：この文書では、2つのIANAレジストリのために呼び出します。
IANA has established and will maintain a registry for S-NAPTR Application Service Tags, listing at least the following information for each such tag:
IANAは確立していますこのような各タグのために、少なくとも以下の情報をリストし、S-NAPTRアプリケーションサービスタグのレジストリを維持します。
o Application Service Tag: A string conforming with the IANA-registered-service defined in section 6.5.
Oアプリケーションサービスタグ：セクション6.5で定義されているIANA登録サービスに準拠した文字列。
o Defining publication: The RFC used to define the Application Service Tag, as defined in the registration process, below.
O定義出版：以下、登録プロセスで定義され、アプリケーション・サービス・タグを定義するために使用されるRFC。
An initial Application Service Tag registration is contained in [9].
最初のアプリケーション・サービス・タグの登録は、[9]に含まれています。
IANA has established and will maintain a registry for S-NAPTR Application Protocol Tags, listing at least the following information for each such tag:
IANAは確立していますこのような各タグのために、少なくとも以下の情報をリストし、S-NAPTRアプリケーションプロトコルタグのレジストリを維持します。
o Application Protocol Tag: A string conforming with the iana-registered-protocol defined in section 6.5.
Oアプリケーションプロトコルタグ：セクション6.5で定義され、IANAに登録プロトコルに準拠ストリング。
o Defining publication: The RFC used to define the Application Protocol Tag, as defined in the registration process, below.
O定義出版：以下、登録プロセスで定義されRFCは、アプリケーションプロトコルタグを定義するために使用されます。
An initial Application Protocol Tag registration is defined in [10].
最初のアプリケーションプロトコルタグの登録は[10]で定義されています。
All application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk.
「X-」で始まるすべてのアプリケーションサービスとプロトコルタグが実験的とみなされ、そして何の規定は同じ文字列の重複使用を防止するために行われません。実装者は、自分の責任でそれらを使用しています。
All other application service and protocol tags are registered based on the "specification required" option defined in [7], with the further stipulation that the "specification" is an RFC (of any category).
他のすべてのアプリケーションサービスとプロトコルタグが「仕様」は、（任意のカテゴリの）RFCであることをさらに規定して、[7]で定義された「仕様必要」オプションに基づいて登録されています。
No further restrictions are placed on the tags except that they must conform with the syntax defined below (Section 6.5).
それ以上の制限は、それらが以下に定義構文（セクション6.5）に準拠しなければならないことを除いて、タグに配置されていません。
The defining RFC must clearly identify and describe, for each tag being registered,
定義RFCは明らかに、登録されている各タグの識別及び記述しなければなりません
o application protocol or service tag,
、アプリケーションプロトコル又はサービスタグO
o intended usage,
Oの使用を意図し、
o interoperability considerations,
O相互運用性の考慮、
o security considerations (see section 8 of this document for further discussion of the types of considerations that are applicable), and
Oのセキュリティ上の考慮事項（適用可能な考慮事項の種類のさらなる議論は、このドキュメントのセクション8を参照）、および
o any relevant related publications.
関連するすべての関連資料O。
The security of this approach to application service location is only as good as the security of the DNS queries along the way. If any of them is compromised, bogus NAPTR and SRV records could be inserted to redirect clients to unintended destinations. This problem is hardly unique to S-NAPTR (or NAPTR in general). A full discussion of the security threats pertaining to DNS can be found in [11].
アプリケーションサービスの場所へのこのアプローチのセキュリティは唯一の道に沿ってDNSクエリのセキュリティと同じくらい良いです。それらのいずれかが侵害された場合、偽のNAPTRとSRVレコードが意図しない宛先にクライアントをリダイレクトするために挿入することができます。この問題は、S-NAPTR（または一般にNAPTR）にほとんど独特です。 DNSに関連するセキュリティの脅威の完全な議論は[11]に記載されています。
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] can be used to ensure the validity of the DNS records received.
DNS-ベクタ攻撃から保護するために、セキュアなDNS（DNSSEC）[12]は、レコードは、受信したDNSの有効性を確認するために使用することができます。
Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to ensure that the correct destination has been reached. Many application protocols such as HTTPS, BEEP, and IMAP define the necessary handshake mechanisms to accomplish this task. Newly defined application protocols should take this into consideration and incorporate appropriate mechanisms.
DNSSECが使用されているか否か、アプリケーションは、正しい宛先に到達したことを確認するために、エンドツーエンド認証のいくつかのフォームを定義する必要があります。そのようなHTTPS、BEEP、およびIMAPなどの多くのアプリケーションプロトコルは、このタスクを達成するために必要なハンドシェークメカニズムを定義します。新たに定義されたアプリケーションプロトコルはこれを考慮すると適切なメカニズムを組み込むべきです。
The basic mechanism works as follows:
基本機能は以下のとおり
1. During some portion of the protocol handshake, the client sends to the server the original name of the desired destination (i.e., no transformations that may have resulted from NAPTR replacements, SRV targets, or CNAME changes). In certain cases where the application protocol does not have such a feature but TLS may be used, it is possible to use the "server_name" TLS extension.
プロトコルハンドシェイクの一部中1は、クライアントがサーバに送信所望の目的地の元の名前（即ち、NAPTR置換、SRVターゲット、またはCNAMEの変化に起因しているかもしれない変換）。アプリケーションプロトコルは、このような特徴を持っていないが、TLSを使用することができる特定の場合には、「サーバ名」TLS拡張子を使用することが可能です。
2. The server sends back to the client a credential with the appropriate name. For X.509 certificates, the name would be in either the subjectDN or the subjectAltName field. For Kerberos, the name would be a service principle name.
2.サーバーは、クライアントに適切な名前を持つ資格を送り返します。 X.509証明書の場合、名前はなsubjectDNかのsubjectAltNameフィールドのいずれかになります。 Kerberosの場合、名前は、サービス原則名になります。
3. Using the matching semantics defined by the application protocol, the client compares the name in the credential with the name sent to the server.
3.アプリケーションプロトコルによって定義されたマッチングのセマンティクスを使用して、クライアントがサーバーに送信された名前を持つ資格で名前を比較します。
4. If the names match and the credentials have integrity, there is reasonable assurance that the correct end point has been reached.
4.名前が一致し、資格情報が整合性を持っている場合は、正しいエンドポイントに達したことを合理的な保証があります。
Note that this document does not define either the handshake mechanism, the specific credential naming fields, nor the name-matching semantics. Definitions of S-NAPTR for particular application protocols MUST define these.
この文書は握手メカニズム、特定の資格命名フィールド、また名前マッチングセマンティクスのいずれかを定義していないことに注意してください。特定のアプリケーションプロトコルのためのS-NAPTRの定義はこれらを定義しなければなりません。
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted Hardie for discussion and input that have (hopefully!) provoked clarifying revisions to this document.
（うまくいけば！）この文書に改訂を明確に挑発している議論や入力のためのデーブBlacka、パトリックFaltstrom、サリーフロイド、およびテッドハーディーに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[6] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[9]ニュートン、A.およびM.サンス、 "IRIS：ドメインレジストリ（DREG）インターネットレジストリ情報サービス（IRIS）のための型"、RFC 3982、2005年1月。
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
[10]ニュートン、A.とM.サンス、RFC 3983 "ブロック拡張可能交換プロトコル（BEEP）を介してインターネットレジストリ情報サービス（IRIS）の使用" を、2005年1月。
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
[11]アトキンス、D.とR. Austeinと、「ドメインネームシステムの脅威分析」、進歩、2004年4月に作業。
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[12]アレンズ、R.、ラーソン、M.、Austeinと、R.、およびD.マッセイ、 "DNSセキュリティ拡張のためのプロトコル変更"、進歩、2004年5月での作業。
Appendix A. Pseudo-Pseudocode for S-NAPTR
付録A.擬似擬似コードS-NAPTRのための
A.1. Finding the First (Best) Target
A.1。まず（ベスト）ターゲットを見つけます
Assuming the client supports 1 protocol for a particular application service, the following pseudocode outlines the expected process to find the first (best) target for the client, using S-NAPTR.
クライアントは、特定のアプリケーション・サービスのための1つのプロトコルをサポートしていますと仮定すると、次の擬似コードは、S-NAPTRを使用して、クライアントのための最初の（最高の）ターゲットを見つけることが期待されるプロセスの概要を示します。
target = [initial domain] naptr-done = false
ターゲット= [初期ドメイン] NAPTR-行わ=偽
while (not naptr-done) { NAPTR-RRset = [DNSlookup of NAPTR RRs for target] [sort NAPTR-RRset by ORDER, and PREF within each ORDER] rr-done = false cur-rr = [first NAPTR RR]
[順序によってソートNAPTR-RRセット、およびPREF各ORDER内（NAPTR-行われていない）{NAPTR-RRセット= [ターゲットのためのNAPTR RRのDNSlookup]一方RR-行わ=偽CUR-RR = [最初のNAPTR RR]
while (not rr-done) if ([SERVICE field of cur-rr contains desired application service and application protocol]) rr-done = true target= [REPLACEMENT target of NAPTR RR] else cur-rr = [next rr in list]
一方（不RR行わ）RR-行わ=真の目標= [NAPTR RRの交換対象]他CUR-RR =（[CUR-RRのSERVICEフィールドは、所望のアプリケーションサービスとアプリケーションプロトコルが含まれている]）場合は、[リスト内の次のRR]
if (not empty [FLAG in cur-rr]) naptr-done = true }
IF（空でない[CUR-RRにFLAG]）=真NAPTR-行わ}
port = -1
ポート= -1
if ([FLAG in cur-rr is "S"]) { SRV-RRset = [DNSlookup of SRV RRs for target] [sort SRV-RRset based on PREF] target = [target of first RR of SRV-RRset] port = [port in first RR of SRV-RRset] }
（[CUR-RRのフラグが "S" である]）場合{SRV-RRセット= [DNSlookupターゲットのSRV RRの]ポート目標= [SRV-RRセットの最初のRRの目標] [PREFに基づいてソートSRV-RRセット] = [SRV-RRセットの最初のRRにおけるポート]}
; now, whether it was an "S" or an "A" in the NAPTR, we ; have the target for an A record lookup host = [DNSlookup of target]
;今、それは、私たち「S」またはNAPTRで「A」であったかどうか。レコード検索ホスト= [ターゲットのDNSlookup]のターゲットを持っています
return (host, port)
リターン（ホスト、ポート）
A.2. Finding Subsequent Targets
A.2。その後ターゲットを見つけます
The pseudocode in Appendix A is crafted to find the first, most preferred host-port pair for a particular application service and protocol. If, for any reason, that host-port pair did not work (connection refused, application-level error), the client is expected to try the next host-port in the S-NAPTR tree.
付録Aの擬似コードは、特定のアプリケーション・サービスおよびプロトコルの最初の、最も好ましい宿主ポートペアを見つけるために細工されています。 、何らかの理由で、そのホスト・ポートのペアが（接続は、アプリケーション・レベルのエラーを拒否した）動作しなかった場合、クライアントは、S-NAPTRツリー内の次のホスト・ポートを試すことが予想されます。
The pseudocode above does not permit retries -- once complete, it sheds all context of where in the S-NAPTR tree it finished. Therefore, client software writers could
上記の擬似コードは、再試行を許可していません - 完了すると、それが終了したS-NAPTRツリー内のすべてのコンテキストを投げかけています。そのため、クライアントソフトウェアの作家ができました
o entwine the application-specific protocol with the DNS lookup and RRset processing described in the pseudocode and continue the S-NAPTR processing if the application code fails to connect to a located host-port pair;
O擬似コードに記載のDNSルックアップと資源レコード集合処理とアプリケーション固有のプロトコルを絡め、アプリケーションコードが位置するホスト・ポートのペアへの接続に失敗した場合、S-NAPTR処理を継続します。
o use callbacks for the S-NAPTR processing; or
O S-NAPTR処理のためのコールバックを使用します。または
o use an S-NAPTR resolution routine that finds *all* valid servers for the required application service and protocol from the originating domain and that provides them in a sorted order for the application to try.
O元のドメインから必要なアプリケーションサービスとプロトコルのための*すべての*有効なサーバを見つけ、それをしようとするアプリケーションのためのソート順序でそれらを提供してS-NAPTR解消ルーチンを使用します。
Appendix B. Availability of Sample Code
サンプルコードの付録B.可用性
Sample Python code for S-NAPTR resolution is available from http://www.verisignlabs.com/pysnaptr-0.1.tgz
S-NAPTR解決するためのサンプルPythonコードhttp://www.verisignlabs.com/pysnaptr-0.1.tgzから入手可能です
Authors' Addresses
著者のアドレス
Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
レスリーDaigle氏ベリサイン社21355 Ridgetopサークルダレス、VA 20166米国
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
メールアドレス：leslie@verisignlabs.com。 leslie@thinkingcat.com
Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
アンドリュー・ニュートンベリサイン社21355 Ridgetopサークルダレス、VA 20166米国
EMail: anewton@verisignlabs.com
メールアドレス：anewton@verisignlabs.com
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機能のための基金は現在、インターネット協会によって提供されます。