Network Working Group L. Daigle
Request for Comments: 4848 Cisco Systems
Category: Standards Track April 2007
Domain-Based Application Service Location Using URIs 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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application.
このドキュメントの目的は、特定のアプリケーションサービスとプロトコルのためのURIにドメイン名のマッピングを可能にするための新しい、簡単なダイナミックな委譲発見サービス（DDDS）アプリケーションを定義することです。 U-NAPTRダビング新しいDDDSアプリケーションとして定義するが、これは効果的にわかりやすいNAPTR（S-NAPTR）DDDSアプリケーションの拡張です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3
2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4
3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4
4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5
4.1. Application Unique String . . . . . . . . . . . . . . . . . 5
4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5
4.5.1. Application Services . . . . . . . . . . . . . . . . . 6
4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6
4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) [7] application to allow mapping of domain names to URIs for particular application services and protocols. This allows the "lookup" of particular services available for given domains, for example.
このドキュメントの目的は、特定のアプリケーションサービスとプロトコルのためのURIにドメイン名のマッピングを可能にするための新しい、簡単なダイナミックな委譲発見サービス（DDDS）[7]アプリケーションを定義することです。これは、例えば、特定のドメインで利用可能な特定のサービスの「ルックアップ」ことができます。
Although this is defining a new and separate DDDS Application, dubbed U-NAPTR, it is built from the same principles as the Straightforward NAPTR (S-NAPTR) application, specified in [2]. This specification is not an update of S-NAPTR, but the reader is encouraged to review that document for extensive coverage of motivation and implementation considerations.
このU-NAPTRダビング新規かつ別個DDDSアプリケーションを定義しているが、これは[2]で指定されたわかりやすいNAPTR（S-NAPTR）アプリケーション、同じ原理から構築されます。この仕様は、S-NAPTRの更新ではなく、読者が動機と実装の考慮の大規模な報道のためにその文書を確認することが奨励されます。
S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution. A number of applications, specified (e.g., [9]) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs.
S-NAPTRは、硬質ドメインの命名規則に依存しないアプリケーションサービスの場所を提供します。それは（S-NAPTR DDDSアプリケーション用）NAPTRレコード内の正規表現の使用を除外するのでそれは一部には、「簡単な」とみなされます。しかし、それはまた、DDDS解像度のターゲットとしてURIを提供する可能性を除外する。指定されたアプリケーションの数は、（例えば、[9]）と提案された、彼らのニーズに合わせてS-NAPTRにニアミスを作り、制限があまりにも限定的見つけます。
This U-NAPTR is effectively a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records.
このU-NAPTRは、NAPTRレコードで可能な正規表現のフルレンジを許可せず、対象となるURIの使用に対応するために、効果的にS-NAPTRへのささやかな拡張機能です。
This document assumes the reader is familiar with the S-NAPTR specification [2]. The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP.
この文書は、読者がS-NAPTR仕様[2]に精通している前提としています。 U-NAPTRの意図は、S-NAPTRはそれがNAPTRレコードの「U」フラグの使用を可能にすることを除いて、行うすべて、とREGEXPの具体的な形を提供することです。
U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must be populated (and, consequently, the REPLACEMENT field is empty). The regular expression in the REGEXP field must be of the limited form described below, and the result of the regular expression evaluation will be a URI that is the result of the DDDS resolution.
U-NAPTRは、S-NAPTR（ "S"、 "A"、または空）、プラス "U" フラグと同じフラグを可能にします。 U-NAPTR DDDSアプリケーションのために、NAPTRレコードの「U」フラグの存在は、REGEXPフィールドが移入されなければならない（及び、従って、予備フィールドが空である）を示しています。 REGEXPフィールドの正規表現は、以下に記載限定形でなければならず、および正規表現の評価の結果は、DDDS分解能の結果であるURIであろう。
U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. This is essentially a dodge around the fact that the REPLACEMENT field in NAPTR is required to produce only a fully qualified domain name (and, therefore, cannot be used for a URI).
U-NAPTRはURIとマッチした文字列の完全な交換を行う形式の正規表現を可能にする、文字列定数として表さ。これは、NAPTRで置換フィールドは（そのため、URIのために使用することができないと、）のみの完全修飾ドメイン名を生成するために必要とされているという事実を中心に、本質的にかわすです。
The specific allowed syntax for U-NAPTR regular expressions is:
U-NAPTR正規表現のための特定の許可構文は次のとおりです。
u-naptr-regexp = "!.*!"<URI>"!"
U-NAPTR-regexpに= "！。*！" <URI> "！"
where <URI> is as defined in STD 66 [8], the URI syntax specification.
ここで、<URI> STD 66で定義されている[8]、URIの構文仕様です。
With this limited form of regular expression, applications using U-NAPTR need not implement full regular expression parsers.
正規表現のこの限定された形で、U-NAPTRを使用するアプリケーションは、完全な正規表現のパーサを実装する必要はありません。
In the sample NAPTR RRs for example.com shown below, "WP" is the imagined application service tag for "white pages", and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
以下に示すexample.comのサンプルNAPTR資源レコードでは、「WP」は、「ホワイトページ」の想像アプリケーション・サービス・タグであり、「EM」は想像「拡張メッセージング」アプリケーションサービスのためのアプリケーション・サービス・タグです。
example.com. ;; order pref flags IN NAPTR 100 10 "" "WP:whois++" ( ; service "" ; regexp bunyip.example.com. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "u" "EM:protA" ( ; service "!.*!prota://someisp.example.com!" ; regexp "" ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement )
example.com。 ;; NAPTR 100 10 "" "WP：WHOIS ++" で県フラグを注文（; ";正規表現bunyip.example.com;置換NAPTR 100 20にサービス"） "秒" "WP：LDAP"（;サービス "";正規表現_ldap ._tcp.myldap.example.com; NAPTR 200 10に置き換え） "U" "EM：。PROTA"（;サービス "* PROTA：！。！！//someisp.example.com";正規表現 "";交換） NAPTR 200 30 "" "EM：protB";サービス「」;正規表現myprotB.example.com;交換用）
This section formally defines the DDDS Application, as described in [7].
記載されているように、このセクションでは、正式に[7]、DDDSアプリケーションを定義します。
The Application Unique String is a fully qualified domain name (FQDN) for which an authoritative server for a particular service is sought.
アプリケーション固有文字列は、特定のサービスのための権威サーバが求められている完全修飾ドメイン名（FQDN）です。
The "First Well Known Rule" is identity -- that is, the output of the rule is the Application Unique String, the FQDN for which the authoritative server for a particular service is sought.
「最初のウェルノウンルールは、」アイデンティティである - つまり、ルールの出力は、特定のサービスのための権限のあるサーバーが求められているアプリケーション固有文字列、FQDNです。
The expected output of this Application is the information necessary to connect to authoritative server(s) (host, port, protocol, or URI) for an application service within a given domain.
このアプリケーションの予想される出力は、所与のドメイン内のアプリケーション・サービスのための権限のサーバ（複数可）（ホスト、ポート、プロトコル、またはURI）に接続するために必要な情報です。
This DDDS Application uses only 3 of the Flags defined for the URI/ URN Resolution Application [5]: "S", "A", and "U". No other Flags are valid. If a client obtains a NAPTR RR for a U-NAPTR-using application that contains any other flag, that NAPTR RR should be ignored and processing continues with the next record (if any).
このDDDSアプリケーションは、3 URI / URN解像度アプリケーション用に定義されたフラグの使用[5]： "S"、 "A"、及び "U"。他のフラグが有効ではありません。クライアントが他のフラグが含まU-NAPTR-使用して、アプリケーションのためのNAPTR RRを取得した場合、そのNAPTR RRは無視され、処理は次のレコード（もしあれば）を継続すべきです。
These flags 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 FQDN 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. "U" means that the output of the Rule is a URI that should be resolved in order to obtain access to the described service.
これらのフラグは、端末のルックアップのためのものです。これは、ルールが最後のものであることを、フラグが次のステージがどうあるべきかを決定することを意味します。 「S」フラグは、このルールの出力は、1つ以上のSRV [3]のレコードが存在するためにFQDNであることを意味します。 「」ルールの出力は、ドメイン名で、そのドメインのアドレスレコードを検索するために使用されるべきであることを意味しています。 「U」は、ルールの出力を説明し、サービスへのアクセスを得るために解決しなければならないURIであることを意味します。
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 [1]:
このアプリケーションのためのサービスパラメータは、このABNFに続く文字列の形をとる[1]：
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 *31ALPHANUMSYM 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 * 31ALPHANUMSYM 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, just 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 [5]. 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]). Since "+" (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アプリケーションで使用される構文と同じではない[5]。 DDDS DNSデータベースには、許容サービス文字列の構文を定義するために、各DDDSアプリケーションが必要です。ここでの構文は、任意のURIスキーム名（[8]を参照）で有効な文字を許可するように拡張されます。 「：」「+」（RFC3404サービスパラメータ文字列で使用される区切り）はURIスキーム名の許可された文字であるので、ここでは、セパレータとして選択されます。
The "app-service" must be an IANA-registered service; see Section 5 for instructions on registering new application service tags.
「アプリサービス」IANA-登録されたサービスでなければなりません。新しいアプリケーションサービスタグを登録する方法については、第5章を参照してください。
The protocol identifiers that are valid for the "app-protocol" production are standard, registered protocols; see Section 5 for instructions on registering new application protocol tags.
「アプリ・プロトコル」の生産のための有効なプロトコル識別子は、登録されたプロトコルの標準です。新しいアプリケーションプロトコルタグを登録する方法については、第5章を参照してください。
Permitted rules are substitution rules and regular expressions of the following syntax (i.e., a regular expression to replace the domain name with a URI):
許可されたルールは、置換ルールと、次の構文の正規表現です（つまり、URIを持つドメイン名を置き換えるために、正規表現）：
u-naptr-regexp = "!.*!"<URI>"!"
U-NAPTR-regexpに= "！。*！" <URI> "！"
where <URI> is as defined in STD 66 [8], the URI syntax specification.
ここで、<URI> STD 66で定義されている[8]、URIの構文仕様です。
At present, only one DDDS Database is specified for this Application. [4] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names.
現時点では、唯一のDDDSデータベースは、このアプリケーションのために指定されています。 [4]書き換えルールを含むようにNAPTR DNSリソースレコードを使用するDDDSデータベースを指定します。このデータベースのキーはドメイン名としてエンコードされています。
The First Well Known Rule produces a domain name, and this is the Key that is used for the first lookup -- 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 [4] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNSサーバは、フラグの値を解釈し、適切なNAPTR、SRV、またはDNSパケットの追加情報部分のレコードを含めるようにその情報を使用することができます。クライアントは、追加情報を確認することをお勧めしますが、その必要はありません。 NAPTRレコードの詳細情報やDNS応答パケットの追加情報セクションの[4]の追加情報の処理を参照してください。
This document does not itself place any requirements on IANA, but provides the basis upon which U-NAPTR-using services can make use of the existing IANA registries for application service tags and application protocol tags (defined in RFC 3958 [2]).
この文書自体はIANA上の任意の要件を置きますが、U-NAPTR-使用してサービスがアプリケーションサービスタグおよびアプリケーションプロトコルタグの既存のIANAレジストリを利用することができ、その上に基礎を提供する（RFC 3958で定義されている[2]）はありません。
As is the case for S-NAPTR, 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. Use them at your own risk.
S-NAPTRの場合のように、「X-」で始まるすべてのアプリケーションサービスとプロトコルタグが実験的とみなされ、そして何の規定は同じ文字列の重複使用を防止するために行われません。ご自身の責任でそれらを使用してください。
All other application service and protocol tags are registered based on the "specification required" option defined in [6], with the further stipulation that the "specification" is an RFC (of any category).
他のすべてのアプリケーションサービスとプロトコルタグが「仕様」は、（任意のカテゴリの）RFCであることをさらに規定して、[6]で定義された「仕様必要」オプションに基づいて登録されています。
There are no further restrictions placed on the tags other than that they must conform with the syntax defined above (Section 4.5).
彼らは上記で定義された構文（セクション4.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 Security considerations (see Section 6 of this document for further discussion of the types of considerations that are applicable)
セキュリティに関する注意事項〇〇相互運用性に関する注意事項（適用可能な考慮事項の種類のさらなる議論については、このドキュメントのセクション6を参照してください）
o Any relevant related publications
O関連するすべての関連資料
The defining RFC may also include further application-specific restrictions, such as limitations on the types of URIs that may be returned for the application service.
定義RFCはまた、アプリケーション・サービスのために戻すことができるURIの種類を限定するものとしてさらに、アプリケーション固有の制約を含むことができます。
U-NAPTR has the same considerations for security as S-NAPTR; see Section 8 of [2]. U-NAPTR has the additional consideration that resolving URIs (from the result of the DDDS resolution) has its own set of security implications, covered in the URI specification (in particular, Section 7 of [8]). In essence, using DNSSEC, client software can be confident that the URI obtained using U-NAPTR is indeed the one specified by the administrator of the domain from which it was retrieved; but the validity of the service reached by resolving that URI is a matter of URI resolution security practices.
U-NAPTRは、S-NAPTRなどのセキュリティのための同じ考慮を持っています。 [2]のセクション8を参照してください。 U-NAPTRは解決のURI（DDDS解像度の結果から）URI仕様で覆われたセキュリティ上の影響、の独自のセットを持つ追加の検討を有する（特に、セクション7 [8]）。本質的には、DNSSECを使用して、クライアントソフトウェアは、URIがU-NAPTRが実際にそれが取得されたドメインの管理者が指定したものです使用して得られることを確信することができます。しかし、サービスの有効性は、URIは、URI解像度のセキュリティ対策の問題であることを解決することによって到達しました。
Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier versions and catching errors!
以前のバージョンを見直し、エラーをキャッチするためのマーティン・トムソン、ジョン・クレンシン、バーナードAboba、アルフレッドHoenes、ダンRomascanu、スレシュクリシュナン、およびラースEggertのおかげ！
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[2] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[2] Daigle氏、L.とA.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[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 Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[7] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[8]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 3986、STD 66、2005年1月。
[9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", RFC 4095, May 2005.
[9]マラマッド、C.、RFC 4095、2005年5月 "勧誘クラスキーワードに意味の取り付け"。
Author's Address
著者のアドレス
Leslie L. Daigle Cisco Systems 13615 Dulles Technology Drive Herndon, VA 20171 US
レスリーL. Daigle氏シスコシステムズ13615ダレステクノロジードライブハーンドン、VA 20171米国
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
メールアドレス：ledaigle@cisco.com。 leslie@thinkingcat.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。