Network Working Group S. Santesson
Request for Comments: 4985 Microsoft
Category: Standards Track August 2007
Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record.
この文書では、証明書のサブジェクトがDNSサービスリソースレコードのサービス名とドメイン名の構成要素に関連付けることを可能にするX.509サブジェクト代替名の拡張子のotherNameフィールドに含めるための新しい名前フォームを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Name Definitions ................................................2
3. Internationalized Domain Names ..................................4
4. Name Constraints Matching Rules .................................5
5. Security Considerations .........................................6
6. Normative References ............................................6
Appendix A. ASN.1 Syntax ...........................................7
Appendix A.1. 1988 ASN.1 Module .................................7
Appendix A.2. 1993 ASN.1 Module .................................8
This document specifies a name form for inclusion in X.509 certificates that may be used by a certificate relying party to verify that a particular host is authorized to provide a specific service within a domain.
この文書では、特定のホストがドメイン内の特定のサービスを提供することを許可されていることを確認するための証明書依存者によって使用されるX.509証明書に含めるための名前の形式を指定します。
RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the location of services (SRV RR), which allows clients to ask for a specific service/protocol for a specific domain and get back the names of any available servers.
RFC 2782 [N3]は、クライアントが特定のドメインのために特定のサービス/プロトコルを依頼し、任意の利用可能なサーバーの名前を取り戻すことを可能にするサービスの場所（SRV RRを）、指定するためのDNS RR（リソースレコード）を定義します。
Existing name forms in X.509 certificates support authentication of a host name. This is useful when the name of the host is known by the client prior to authentication.
X.509証明書の既存の名前形式は、ホスト名の認証をサポートしています。ホストの名前を認証する前に、クライアントによって知られている場合に便利です。
When a server host name is discovered through DNS RR lookup query based on service name, the client may need to authenticate the server's authorization to provide the requested service in addition to the server's host name.
サーバーのホスト名は、サービス名に基づいてDNSのRRルックアップクエリで発見された場合、クライアントは、サーバのホスト名に加えて、要求されたサービスを提供するために、サーバーの権限を認証する必要があります。
While DNS servers may have the capacity to provide trusted information, there may be many other situations where the binding between the name of the host and the provided service needs to be supported by additional credentials.
DNSサーバーは、信頼できる情報を提供する能力を持っているかもしれないが、ホスト名と提供されるサービス間の結合は、追加の資格情報によってサポートされる必要が他の多くの状況があるかもしれません。
Current dNSName GeneralName Subject Alternative name form only provides for DNS host names to be expressed in "preferred name syntax", as specified by RFC 1034 [N4]. This definition is therefore not broad enough to allow expression of a service related to that domain.
現在のdNSNameのGeneralName件名代替名の形式は、RFC 1034 [N4]で指定されたDNSホスト名は、「好ましい名前構文」で発現されることを提供します。この定義は、したがって、そのドメインに関連するサービスの発現を可能にするのに十分広くありません。
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 RFC 2119 [N1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [N1]に記載されているように解釈されます。
This section defines the SRVName name as a form of otherName from the GeneralName structure in SubjectAltName defined in RFC 3280 [N2].
このセクションでは、RFC 3280 [N2]で定義のSubjectAltNameでいるGeneralName構造からotherNameの形態としてSRVNAME名を定義します。
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
SRVName ::= IA5String (SIZE (1..MAX))
The SRVName, if present, MUST contain a service name and a domain name in the following form:
SRVNAMEは、存在する場合、サービス名と次の形式でドメイン名を含まなければなりません：
_Service.Name
＿せｒゔぃせ。なめ
The content of the components of this name form MUST be consistent with the corresponding definition of these components in an SRV RR according to RFC 2782 [N3].
この名前の形式の成分の含有量は、RFC 2782 [N3]に記載のSRV RRにおけるこれらの成分の対応する定義と一致していなければなりません。
The content of these components are:
これらの成分の含有量は以下のとおりです。
Service The symbolic name of the desired service, as defined in Assigned Numbers [N5] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. Some widely used services, notably POP, don't have a single universal name. If Assigned Numbers names the service indicated, that name is the only name that is allowed in the service component of this name form. The Service is case insensitive.
割り当て番号[N5]または局所的に定義されるように、所望のサービスのシンボル名をサービス。アンダースコア（_）は、自然界に存在DNSラベルとの衝突を避けるために、サービス識別子の前に付加されます。いくつかの広く使用されるサービスは、特にPOP、単一の汎用名前がありません。割り当て番号名はサービスが示されている場合は、その名前は、この名前の形式のサービス・コンポーネントに許可されている唯一の名前です。サービスは、大文字と小文字を区別しません。
Name The DNS domain name of the domain where the specified service is located.
指定されたサービスが配置されているドメインのDNSドメイン名。
If the domain name is an Internationalized Domain Name (IDN), then encoding in ASCII form SHALL be done as defined in section 3.
ドメイン名は国際化ドメイン名（IDN）の場合セクション3で定義されるように、その後、ASCII形式で符号化が行われるものとします。
Even though this name form is based on the service resource record (SRV RR) definition in RFC 2782 [N3] and may be used to enhance subsequent authentication of DNS-based service discovery, this standard does not define any new conditions or requirements regarding use of SRV RR for service discovery or where and when such use is appropriate.
この名前の形式は、[N3] RFC 2782のサービスリソースレコード（SRVのRR）の定義に基づいており、DNSベースのサービス・ディスカバリのその後の認証を強化するために使用することができる、この標準は、使用に関する新たな条件や要件を定義していないにもかかわらず、サービスの発見や、いつどこでのSRV RRのような使用は適切です。
The format of a DNS RR, according to RFC 2782, also includes a protocol component (_Service._Proto.Name). This protocol component is not included in the SRVName specified in this document. The purpose of the SRVName is limited to authorization of service provision within a domain. It is outside the scope of the SRVName to provide any means to verify that the host is using any intended protocol. By omitting the protocol component from the SRVName two important advantages have been achieved:
DNS RRのフォーマットは、RFC 2782によれば、また、プロトコルコンポーネント（_Service._Proto.Name）を含みます。このプロトコルコンポーネントは、この文書で指定SRVNAMEには含まれていません。 SRVNAMEの目的は、ドメイン内のサービス提供の許可に制限されています。これは、ホストが、任意の意図するプロトコルを使用していることを確認するための任意の手段を提供するSRVNAMEの範囲外です。 SRVNAMEからプロトコルコンポーネントを省略することによって、二つの重要な利点が達成されました。
* One certificate with a single SRVName can be issued to a host that offers multiple protocol alternatives.
*シングルSRVNAMEの一つの証明書は、複数のプロトコルの選択肢を提供していますホストに対して発行することができます。
* Name constraints processing rules (specified in section 4)are significantly less complex to define without the protocol component.
（セクション4で指定される）ルールを処理する*名前制約が著しく少ない複雑なプロトコルコンポーネントなしで定義することです。
A present SRVName in a certificate MUST NOT be used to identify a host unless one of the following conditions applies:
次のいずれかの条件が適用される場合を除き、証明書にSRVNAMEはホストを識別するために使用することはできません。
* Use of this name form is specified by the security protocol being used and the identified service has a defined service name according to RFC 2782, or;
*セキュリティプロトコルによって指定され、この名前形態の使用は、使用されていると識別されたサービスは、RFC 2782、又はに従って定義されたサービス名を有しています。
* Use of this name form is configured by local policy.
*この名前のフォームの使用がローカルポリシーで構成されています。
IA5String is limited to the set of ASCII characters. To accommodate internationalized domain names in the current structure, conforming implementations MUST convert internationalized domain names to the ASCII Compatible Encoding (ACE) format as specified in section 4 of RFC 3490 [N6] before storage in the Name part of SRVName. Specifically, conforming implementations MUST perform the conversion operation specified in section 4 of RFC 3490 [N6], with the following clarifications:
IA5Stringは、ASCII文字のセットに限定されています。 SRVNAMEの名前部分に格納する前に、RFC 3490 [N6]のセクション4で指定されるように、現在の構造で国際化ドメイン名に対応するために、適合実装は、ASCII互換エンコーディング（ACE）形式に国際化ドメイン名を変換する必要があります。具体的には、適合実装は、以下の明確化と、RFC 3490 [N6]のセクション4で指定された変換操作を実行する必要があります。
* in step 1, the domain name SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set;
*ステップ1で、ドメイン名は、「保存された文字列」とみなされます。それはAllowUnassignedフラグがセットされないもの、です。
* in step 3, set the flag called "UseSTD3ASCIIRules";
*ステップ3で、「UseSTD3ASCIIRules」と呼ばれるフラグを設定します。
* in step 4, process each label with the "ToASCII" operation; and
*工程4、工程「もしToASCII」操作で各ラベルにおいて、そして
* in step 5, change all label separators to U+002E (full stop).
*ステップ5で、U + 002E（フルストップ）に、すべてのラベルの区切りを変更します。
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire domain name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis.
平等のためのDNS名を比較するとき、適合実装は、全体のドメイン名に大文字と小文字を区別しない完全一致を実行しなければなりません。名前制約を評価するとき、適合実装は、ラベル・バイ・ラベル毎に、大文字と小文字を区別しない完全一致を実行しなければなりません。
Implementations SHOULD convert IDNs to Unicode before display. Specifically, conforming implementations SHOULD perform the conversion operation specified in section 4 of RFC 3490 [N6], with the following clarifications:
実装は、ディスプレイの前にUnicodeにIDNのを変換する必要があります。具体的には、適合実装は、以下の明確化と、RFC 3490 [N6]のセクション4で指定された変換操作を実行する必要があります。
* in step 1, the domain name SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set;
*ステップ1で、ドメイン名は、「保存された文字列」とみなされます。それはAllowUnassignedフラグがセットされないもの、です。
* in step 3, set the flag called "UseSTD3ASCIIRules";
*ステップ3で、「UseSTD3ASCIIRules」と呼ばれるフラグを設定します。
* in step 4, process each label with the "ToUnicode" operation; and
*ステップ4、処理「のToUnicode」動作と各ラベルにおいて、そして
* skip step 5.
*ステップ5をスキップしてください。
Note: Implementations MUST allow for increased space requirements for IDNs. An IDN ACE label will begin with the four additional characters "xn--" and may require as many as five ASCII characters to specify a single international character.
注意：実装は、IDNのための増加スペース要件を考慮しなければなりません。 IDNのACEラベルは「xn--」の4つの追加文字で開始し、単一の国際文字を指定するなど、多くの5つのASCII文字を必要とするかもしれません。
Name constraining, as specified in RFC 3280, MAY be applied to the SRVName by adding name restriction in the name constraints extension in the form of an SRVName.
制約名、RFC 3280で指定され、SRVNAMEの形で名前制約拡張で名前の制限を加えることでSRVNAMEに適用することができます。
SRVName restrictions are expressed as a complete SRVName (_mail.example.com), just a service name (_mail), or just as a DNS name (example.com). The name restriction of the service name part and the DNS name part of SRVName are handled separately.
SRVNAMEの制限は、完全なSRVNAME（_mail.example.com）、単にサービス名（_mail）、または単にDNS名（example.com）などのように表現されています。サービス名の部分の名前の制限とSRVNAMEのDNS名の部分を別々に処理されています。
If a service name is included in the restriction, then that restriction can only be satisfied by an SRVName that includes a corresponding service name. If the restriction has an absent service name, then that restriction is satisfied by any SRVName that matches the domain part of the restriction.
サービス名が制限に含まれている場合、その制限は、対応するサービス名を含むSRVNAMEことによって満たすことができます。制限がないサービス名を持っている場合、その制限は、制限のドメイン部分と一致する任意のSRVNAMEによって満たされます。
DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding subdomains to the left-hand side of the name satisfies the DNS name part of the name constraint. For example, www.host.example.com would satisfy the constraint (host.example.com) but 1host.example.com would not.
DNS名の制限は、host.example.comとして表現されています。単に名前の左側にサブドメインを追加することによって構築することができる任意のDNS名は、名前制約のDNS名の部分を満たします。例えば、www.host.example.comは制約（host.example.com）を満たすだろうが、1host.example.comはないでしょう。
Examples:
例：
Name Constraints
SRVName restriction Matching SRVName non-matching SRVName
=================== ================ ====================
example.com _mail.example.com _mail.1example.com
_ntp.example.com
_mail.1.example.com
_mail _mail.example.com _ntp.example.com _mail.1example.com
_mail _mail.example.com _ntp.example.com _mail.1example.com
_mail.example.com _mail.example.com _mail.1example.com _mail.1.example.com _ntp.example.com
＿まいｌ。えぁｍｐぇ。こｍ ＿まいｌ。えぁｍｐぇ。こｍ ＿まいｌ。１えぁｍｐぇ。こｍ ＿まいｌ。１。えぁｍｐぇ。こｍ ＿んｔｐ。えぁｍｐぇ。こｍ
Assignment of services to hosts may be subject to change. Implementers should be aware of the need to revoke old certificates that no longer reflect the current assignment of services and thus make sure that all issued certificates are up to date.
ホストへのサービスの割り当ては変更される場合があります。実装者は、もはやサービスの現在の割り当てを反映していないので、すべての発行された証明書が最新であることを確認して古い証明書を失効させる必要性を認識する必要があります。
When X.509 certificates enhanced with the name form specified in this standard is used to enhance authentication of service discovery based on an SRV RR query to a DNS server, all security considerations of RFC 2782 applies.
この標準で指定された名前のフォームで強化X.509証明書がDNSサーバーにSRV RRのクエリに基づいてサービスディスカバリの認証を強化するために使用された場合は、RFC 2782のすべてのセキュリティの考慮事項が適用されます。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[N2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[N2] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[N3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[N3] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[N4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987
[N4] Mockapetris、P.、 "ドメイン名 - CONCEPTS AND FACILITIES"、STD 13、RFC 1034、1987年11月
[N5] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[N5]レイノルズ、J.、：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。
[N6] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[N6] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
Appendix A. ASN.1 Syntax
付録A. ASN.1構文
As in RFC 2459, ASN.1 modules are supplied in two different variants of the ASN.1 syntax.
RFC 2459のように、ASN.1モジュールは、ASN.1構文の2つの異なる流儀で提供されています。
This section describes data objects used by conforming Public Key Infrastructure (PKI) components in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with the 1993 UNIVERSAL Type UTF8String.
このセクションでは、「ASN.1様」構文で公開鍵基盤（PKI）コンポーネントを準拠で使用されるデータオブジェクトを記述します。この構文は1988年と1993年のASN.1構文のハイブリッドです。 1988 ASN.1構文は、1993 UNIVERSALタイプUTF8Stringをして強化されています。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1構文はASN.1モジュール内の型宣言文を含めることを許可せず、1993年ASN.1標準は、1988年の構文を使用して、モジュールに新しいUNIVERSALタイプの使用を許可していません。その結果、このモジュールは、ASN.1標準のいずれかのバージョンに準拠していません。
Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
付録A.1は、「ANY」1988キャッチオールでUNIVERSALタイプの定義を置き換えることによって、1988 ASN.1パーサによって解析することができます。
Appendix A.2 may be parsed "as is" by a 1997-compliant ASN.1 parser.
付録A.2は1997に準拠したASN.1パーサーによって「そのまま」に解析することができます。
In case of discrepancies between these modules, the 1988 module is the normative one.
これらのモジュール間の不一致の場合には、1988モジュールは、規範的なものです。
Appendix A.1. 1988 ASN.1 Module
付録A.1。 1988 ASN.1モジュール
PKIXServiceNameSAN88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dns-srv-name-88(39) }
PKIXServiceNameSAN88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-DNS-SRV-名-88（ 39）}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- UTF8String, / move hyphens before slash if UTF8String does not -- resolve with your compiler
あなたのコンパイラで解決 - - UTF8Stringをがいない場合はUTF8Stringを、/スラッシュの前にハイフンを移動
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- from RFC3280 [N2]
-- Service Name Object Identifier and Syntax
-- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7}
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
SRVName ::= IA5String (SIZE (1..MAX))
END
終わり
Appendix A.2. 1993 ASN.1 Module
付録A.2。 1993 ASN.1モジュール
PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dns-srv-name-93(40) }
PKIXServiceNameSAN93 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-DNS-SRV-名-93（ 40）}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
id-pkix FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; -- from RFC 3280 [N2]
PKIX1Explicit88からID-PKIX {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（18） }。 - RFC 3280から[N2]
-- In the GeneralName definition using the 1993 ASN.1 syntax -- includes:
- 1993 ASN.1構文を使用しているGeneralName定義で - 含まれています。
OTHER-NAME ::= TYPE-IDENTIFIER
-- Service Name Object Identifier
- サービス名オブジェクト識別子
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
-- Service Name
- サービス名
srvName OTHER-NAME ::= { SRVName IDENTIFIED BY { id-on-dnsSRV }}
SRVName ::= IA5String (SIZE (1..MAX))
END
終わり
Author's Address
著者のアドレス
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
ステファンSantessonマイクロソフトツボルグ大通り12 2900ヘレラップデンマーク
EMail: stefans@microsoft.com
メールアドレス：stefans@microsoft.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に情報を記述してください。