[要約] RFC 4848は、URIとDDDSを使用したドメインベースのアプリケーションサービスの場所特定に関するものです。このRFCの目的は、アプリケーションサービスの場所を効率的に特定するための仕組みを提供することです。
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)
URISと動的委任ディスカバリーサービス（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）The IETF Trust（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.
このドキュメントの目的は、特定のアプリケーションサービスとプロトコルのためにURISへのドメイン名のマッピングを可能にするために、新しい、単純な動的委任ディスカバリーサービス（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.
このドキュメントの目的は、特定のアプリケーションサービスとプロトコルのためにURISにドメイン名をマッピングできるようにするために、新しい、単純な動的委任ディスカバリーサービス（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は、厳格なドメインの命名規則に依存しないアプリケーションサービスの場所を提供します。NAPTRレコードでの正規表現の使用を排除することを排除するため、「単純な」とみなされます（S-NAPTR DDDSアプリケーション用）。ただし、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」フラグが存在することは、再gExpフィールドに入力する必要があることを示しています（その結果、交換場は空です）。正規表現フィールドの正規表現は、以下で説明する限られた形式でなければならず、正規表現評価の結果は、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>"!"
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.
以下に示すnaptr rrsのサンプルでは、「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
)
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.
「最初によく知られているルール」はIDです。つまり、ルールの出力は、特定のサービスの権威あるサーバーが求められる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アプリケーションでは、URI/ URN解像度アプリケーション[5]で定義されたフラグのうち3つのみを使用します：「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であることを意味します。「a」とは、ルールの出力がドメイン名であり、そのドメインのアドレスレコードを検索するために使用する必要があることを意味します。「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.
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.
「App-Protocol」生産に有効なプロトコル識別子は、標準の登録プロトコルです。新しいアプリケーションプロトコルタグの登録に関する手順については、セクション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>"!"
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データベースは1つだけです。[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サーバーは、フラグ値を解釈し、その情報を使用して、DNSパケットの追加情報部分に適切なNAPTR、SRV、またはレコードを含めることができます。クライアントは追加情報を確認することをお勧めしますが、そうする必要はありません。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).
他のすべてのアプリケーションサービスとプロトコルタグは、[6]で定義されている「必要な仕様」オプションに基づいて登録されており、「仕様」が（任意のカテゴリの）RFCであるというさらなる規定があります。
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)
o 相互運用性の考慮事項oセキュリティに関する考慮事項（適用可能な考慮事項のタイプの詳細については、このドキュメントのセクション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の仕様（特に[8]のセクション7）でカバーされているURIS（DDDS解像度の結果から）を解決するという追加の考慮事項があります。本質的に、DNSSECを使用して、クライアントソフトウェアは、U-NAPTRを使用して取得したURIが実際にそれが取得されたドメインの管理者によって指定されたものであると確信できます。しかし、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!
マーティン・トムソン、ジョン・クレンシン、バーナード・アボバ、アルフレッド・ホーネス、ダン・ロマスカヌ、スレシュ・クリシュナン、ラース・エガートに感謝します。
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1] Crocker、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。and A. Newton、「SRV RRSおよびDynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[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 RR（DNS SRV）」、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。、「Dynamic Delogation Discovery System（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）パート4：ユニフォームリソース識別子（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。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的な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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 3986、STD 66、2005年1月。
[9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", RFC 4095, May 2005.
[9] Malamud、C。、「勧誘クラスのキーワードへの意味の添付」、RFC 4095、2005年5月。
Author's Address
著者の連絡先
Leslie L. Daigle Cisco Systems 13615 Dulles Technology Drive Herndon, VA 20171 US
Leslie L. Daigle Cisco Systems 13615 Dulles Technology Drive Herndon、VA 20171 US
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。