Network Working Group N. Williams
Request for Comments: 5178 Sun
Category: Standards Track A. Melnikov
Isode Ltd.
May 2008
Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）国際化とドメインベースのサービス名と名前タイプ
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 describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
この文書では、一般的なセキュリティサービスアプリケーションプログラミングインターフェイス（GSS-API）のドメイン名ベースのサービスプリンシパル名と対応する名前のタイプを記述する。 GSS-APIの国際化にも覆われています。
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names.
ドメインベースのサービス名、サービス名ベースのホストに似ていますが、ホスト名に加えてドメイン名（必ずしもインターネットドメイン名）を使用。ドメインベースの名前の主な目的は、安全でないサービス発見プロトコルを利用するアプリケーションへの保護の手段を提供することです。これにより、顧客は、彼らのサービス名の認証に基づいてサービスのサーバーを承認することができ、「ドメイン」、彼らはサービスの後にクラスタ化されたサービスに名前を付ける方法を提供することによって達成されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . 4
4.1. Examples of Domain-Based Names . . . . . . . . . . . . . . 5
5. Internationalization (I18N) Considerations . . . . . . . . . . 5
5.1. Importing Internationalized Names . . . . . . . . . . . . . 5
5.2. Displaying Internationalized Names . . . . . . . . . . . . 5
6. Application Protocol Examples . . . . . . . . . . . . . . . . . 6
6.1. NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
6.2. LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Some applications need to discover the names of servers for a specific resource. Some common methods for server discovery are insecure, e.g., queries for DNS [RFC1035] SRV resource records [RFC2782] without using DNSSEC [RFC4033], and are subject to attacks whereby a client can be re-directed to incorrect and possibly malicious servers. A client may even be re-directed to a server that has credentials for itself and thus may authenticate itself to the client, and yet it could be incorrect or malicious (because it has been compromised, say).
一部のアプリケーションでは、特定のリソースのためのサーバーの名前を発見する必要があります。サーバー発見のためのいくつかの一般的な方法は、DNSSEC [RFC4033]を使用せずに、例えば、DNSのクエリ[RFC1035] SRVリソースレコード[RFC2782]安全ではない、とクライアントが正しくないと、おそらく悪意のあるサーバにリダイレクトすることができる攻撃の対象となっています。でも、自分自身のために、したがって、資格情報を持つサーバーにリダイレクトすることができるクライアントは、クライアントに対して自身を認証することができ、まだそれが間違っているか、悪質な可能性があり（それが危険にさらされているため、と言います）。
Domain-based names allow for GSS-API [RFC2743] initiator applications (clients) to authorize acceptor principals (servers) to serve the resource for which the client used insecure server discovery without either securing the server discovery method or requiring an additional protocol for server authorization. That is, either a discovered server has credentials for authenticating the domain-based service names that it is intended to respond to, or it does not. Availability of valid credentials for authenticating domain-based names embodies the authorization of a given server to a domain-wide service.
ドメインベースの名前は、クライアントがいずれかのサーバ発見方法を固定するか、サーバのための追加のプロトコルを必要とすることなく、安全でないサーバーの検出を使用するリソースを提供するアクセプタプリンシパル（サーバー）を許可するGSS-API [RFC2743]イニシエータアプリケーション（クライアント）を可能にします承認。つまり、どちらか検出されたサーバは、に応答することを意図しているドメインベースのサービス名を認証するための資格情報を持っている、またはそれにはありません。ドメインベースの名前を認証するための有効な資格情報の入手可能性は、ドメイン全体のサービスに指定されたサーバーの承認を体現しています。
A domain-based name consists of three required elements:
ドメインベースの名前は、3つの必須の要素で構成されています。
o a service name
Oサービス名
o a domain name
Oドメイン名
o a hostname
Oホスト名
The domain name and the hostname should be Domain Name System (DNS) names, though domain-based names could be used in non-DNS environments. Because of the use of DNS names we must also provide for internationalization of the GSS-API.
ドメインベースの名前は非DNS環境で使用することができても、ドメイン名とホスト名は、ドメインネームシステム（DNS）名でなければなりません。我々はまた、GSS-APIの国際化のために提供しなければならないDNS名の使用のため。
Note that domain-based naming isn't new. According to a report to the KITTEN WG mailing list, there exists at least one implementation of LDAP which uses domain-based service naming, and the DIGEST-MD5 HTTP / Simple Authentication and Security Layer (SASL) mechanism [RFC2831] describes a similar notion. (See section 2.1.2 of [RFC2831] for a description of the "serv-name" field of the digest-response.)
ドメインベースの命名は新しいものではないことに注意してください。 KITTEN WGメーリングリストへの報告によると、そこにドメインベースのサービス・ネーミングを使用してLDAPの少なくとも1つの実装が存在し、DIGEST-MD5 HTTP /簡易認証セキュリティー層（SASL）のメカニズム[RFC2831]は同様の概念を説明します。 （ダイジェストレスポンスの「SERV名」フィールドの説明については、[RFC2831]のセクション2.1.2を参照）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The IANA has recorded the following new name-type OID in IANA's "SMI Security for Name System Designators Codes (nametypes)" registry:
IANAはIANAの「SMIセキュリティネームシステム指定子コード（nametypes）について、」レジストリで次の新しい名前タイプのOIDを記録しました：
5 gss-domain-based-services [RFC5178]
5 GSS-ドメインベース・サービス[RFC5178]
This document creates a new GSS-API name-type, with a symbolic name of "GSS_C_NT_DOMAINBASED_SERVICE" and this OID:
この文書は、「GSS_C_NT_DOMAINBASED_SERVICE」と、このOIDのシンボル名に、新しいGSS-API名型を作成します。
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-domain-based(5)}
{ISO（1）ORG（3）DOD（6）インターネット（1）セキュリティ（5）nametypes（6）GSS-ドメインベース（5）}
There is a single name syntax for domain-based names. It is expressed using the ABNF [RFC5234].
ドメインベースの名前のための単一の名前の構文があります。これは、ABNF [RFC5234]を使用して表現されます。
The syntax is:
構文は次のとおりです。
domain-based-name = service "@" domain "@" hostname
ドメインベース名=サービス「@」ドメイン「@」ホスト名
hostname = domain
ホスト名=ドメイン
domain = sub-domain 1*("." sub-domain)
ドメイン=サブドメイン1 *（「」サブドメイン）
sub-domain = Let-dig [Ldh-str]
サブドメイン=ましょう-掘る[LDH-STR]
Let-dig = ALPHA / DIGIT
簡単あなた= ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
LDH-STR = *（ALPHA / DIGIT / " - "）してみましょう-DIG
Where <service> is defined in Section 4.1 of [RFC2743]. Other rules not defined above are defined in Appendix B.1 of [RFC5234].
ここで、<サービス>は、[RFC2743]のセクション4.1で定義されています。上記で定義されていない他のルールは、[RFC5234]の付録B.1に定義されています。
These examples are not normative:
これらの例は規範的ではありません。
o ldap@somecompany.example@ds1.somecompany.example
LDAP somecompany.example @ @ ds1.somecompany.example
o nfs@somecompany.example@nfsroot1.somecompany.example
O NFS @ somecompany.example @ nfsroot1.somecompany.example
The .example top-level domain is used here in accordance with [RFC2606].
。実施例トップレベルドメインは、[RFC2606]に従って、ここで使用されています。
We introduce new versions of GSS_Import_name() and GSS_Display_name() to better support Unicode. Additionally, we provide for the use of ASCII Compatible Encoding (ACE)-encoded DNS in the non-internationalized interfaces [RFC3490].
私たちは、より良いサポートUnicodeにGSS_Import_name（）とGSS_Display_name（）の新しいバージョンをご紹介します。また、我々は、非国際インターフェイス[RFC3490]でASCIIコンパチブルエンコーディング（ACE）でエンコードDNSの使用を提供します。
When the input_name_type parameter is the GSS_C_NT_DOMAINBASED_SERVICE OID, then GSS_Import_name() implementations and GSS-API mechanisms MUST accept ACE-encoded internationalized domain names in the hostname and domain name slots of the given domain-based name string.
input_name_typeパラメータがGSS_C_NT_DOMAINBASED_SERVICE OIDである場合、次いでGSS_Import_name（）の実装とGSS-API機構は、特定のドメインベースの名前の文字列のホスト名とドメイン名スロットにおけるACEエンコード国際化ドメイン名を受け入れなければなりません。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Import_name_utf8(), that operates exactly like GSS_Import_name() (with the same input and output parameters and behavior), except that it MUST accept internationalized domain names both as UTF-8 strings and as ACE-encoded strings via its input_name_string argument.
非ASCII国際化ドメイン名のサポートは、新しい機能を通じて提供されるべきで、それはのように、両方の国際化ドメイン名を受け入れなければならないことを除いて、（同じ入力および出力パラメータと行動との）正確GSS_Import_name（のように動作GSS_Import_name_utf8（）、） UTF-8文字列とそのinput_name_string引数を経由してACE-エンコードされた文字列として。
Implementations of GSS_Display_name() MUST only output US-ASCII or ACE-encoded internationalized domain names in the hostname and domain name slots of domain-based names (or mechanism names (MN) that conform to the mechanism's form for domain-based names).
GSS_Display_nameの実装（）のみ出力US-ASCIIまたは（ドメインベースの名前のためのメカニズムの形に適合するか、メカニズム名（MN））ドメインベースの名前のホスト名とドメイン名スロットにACEでエンコードされた国際化ドメイン名必要があります。
Support for non-ASCII internationalized domain names SHOULD also be provided through a new function, GSS_Display_name_utf8(), that operates exactly like GSS_Display_name() (with the same input and output parameters and behavior), except that it outputs UTF-8 strings via its name_string output argument. GSS_Display_name_utf8() MUST NOT output ACE-encoded internationalized domain names.
非ASCII国際化ドメイン名のサポートは、新しい機能を通じて提供されるべきで、それはその経由でUTF-8文字列を出力することを除いて、（同じ入力および出力パラメータと行動との）正確GSS_Display_name（のように動作GSS_Display_name_utf8（）、）出力引数をname_stringについて。 GSS_Display_name_utf8（）出力ACE-エンコードされた国際化ドメイン名はなりません。
The following examples are not normative. They describe how the authors envision two applications' use of domain-based names.
次の例では、規範的ではありません。彼らは、著者らは、ドメインベースの名前の2つのアプリケーションの使用を想定する方法について説明します。
Work is ongoing to provide a method for constructing domain-wide NFSv4 [RFC3530] filesystem namespaces where there is a single "root" with one or more servers (replicas) and multiple filesystems glued into the namespace through use of "referrals". Clients could then construct a "global" namespace through use of the DNS domain hierarchy.
作業は、1つまたは複数のサーバ（レプリカ）と「紹介」の使用を介して名前空間に接着され、複数のファイルシステムを有する単一の「ルート」が存在するドメイン全体のNFSv4 [RFC3530]ファイルシステムの名前空間を構築するための方法を提供することで進行中です。クライアントは、DNSのドメイン階層を使用して「グローバル」の名前空間を構築することができます。
Here, clients would always know, from context, when they need to find the root servers for a given DNS domain. Root server discovery would be performed using DNS SRV RR lookups, without using DNSSEC where DNSSEC has not been deployed.
彼らは与えられたDNSドメインのルートサーバを見つける必要があるときここでは、クライアントは常に、文脈から、知っているだろう。ルートサーバの発見は、DNSSECが展開されていないDNSSECを使用せずに、DNS SRV RRのルックアップを使用して実行されるであろう。
When using RPCSEC_GSS [RFC2203] for security, NFSv4 clients would use domain-based names to ensure that the servers named in the SRV RRs are in fact authorized to be the NFSv4 root servers for the target domain.
セキュリティのためにRPCSEC_GSS [RFC2203]を使用する場合は、NFSv4のクライアントは、SRV RRをで指定されたサーバが実際にターゲットドメイン用のNFSv4ルートサーバーであることを許可されていることを保証するために、ドメインベースの名前を使用します。
LDAP clients using the GSS-API through SASL would also benefit from use of domain-based names to protect server discovery through insecure DNS SRV RR lookups, much as described above.
上記のようにSASLを通じてGSS-APIを使用してLDAPクライアントもずっと、安全でないDNSのSRV RRのルックアップを介してサーバの発見を保護するために、ドメインベースの名前を使用することから利益を得るであろう。
Unlike NFSv4 clients, not all LDAP clients always know from context when they should use domain-based names. That's because existing clients may use host-based naming to authenticate servers discovered through SRV RR lookups. Changing such clients to use domain-based naming when domain-based acceptor credentials have not been deployed to LDAP servers, or when LDAP servers have not been modified to allow use of domain-based naming, would break interoperability. That is, there is a legacy server interoperability issue here. Therefore, LDAP clients may require additional configuration at deployment time to enable (or disable) use of domain-based naming.
NFSv4のクライアントとは異なり、すべてのLDAPクライアントは常に彼らは、ドメインベースの名前を使用する必要があり、文脈から分かりません。既存のクライアントは、SRV RRの検索を通じて検出されたサーバを認証するために、ホストベースのネーミングを使用するためです。ドメインベースのアクセプタの資格はLDAPサーバに配備されていない、またはLDAPサーバがドメインベースの命名の使用を許可するように変更されていない場合は、相互運用性を壊す際に、ドメインベースのネーミングを使用するようにクライアントを変更します。これは、従来のサーバーの相互運用性の問題はここにあり、です。そのため、LDAPクライアントは、ドメインベースの命名の使用を有効（または無効）するために、デプロイメント時に、追加設定が必要な場合があります。
Note: whether SASL [RFC4422] or its GSS-API bridges [RFC4752] [GS2] require updates in order allow use of domain-based names is not relevant to the theory of how domain-based naming would protect LDAP clients' server discovery.
注意：SASL [RFC4422]またはそのGSS-APIブリッジ[RFC4752]が[GS2]ため、ドメインベースの名前の使用は、ドメインベースの命名は、LDAPクライアントのサーバーの発見を保護する方法の理論に関連していない許可での更新が必要かどうか。
Use of GSS-API domain-based names may not be negotiable by some GSS-API mechanisms, and some acceptors may not support GSS-API domain-based names. In such cases, the initiators are left to fall back on the use of host-based names, so the initiators MUST also verify that the acceptor's host-based name is authorized to provide the given service for the domain that the initiator had wanted.
GSS-APIのドメインベースの名前を使用すると、いくつかのGSS-APIメカニズムによって交渉ではないかもしれない、といくつかの受容体は、GSS-APIのドメインベースの名前をサポートしていないかもしれません。開始剤はまた、アクセプターのホストベースの名前は、イニシエータが望んでいたドメインの指定されたサービスを提供することを許可されていることを確認しなければならないので、そのような場合には、イニシエータは、ホストベース名の使用に頼るために残されています。
The above security consideration also applies to all GSS-API initiators who lack support for domain-based service names.
上記のセキュリティの考慮事項は、ドメインベースのサービス名をサポートしていないすべてのGSS-APIのイニシエータに適用されます。
Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials.
全てのサービス名と同じように、ドメインベースのサービス名の単なる存在は、許可決定を行うための開始剤が使用することができる意味のある情報を伝える、ということに注意してください。そのため、分散型認証サービスの管理者は、アクセプタの資格を作成するサービス名の重要性を認識する必要があります。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831]リーチ、P.とC.ニューマン、 "SASLメカニズムとしてダイジェスト認証を使用する"、RFC 2831、2000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Work in Progress, October 2007.
[GS2] Josefsson氏、S.、 "SASLでGSS-APIメカニズムの使用：GS2メカニズムファミリー"、進歩、2007年10月の作業を。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]アイスラー、M.、チウ、A.、およびL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイク、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752]メルニコフ、A.、 "ケルベロスV5（" GSSAPI "）簡易認証セキュリティー層（SASL）メカニズム"、RFC 4752、2006年11月。
Authors' Addresses
著者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
ニコラス・ウィリアムズSun Microsystemsの5300 RiataトレースのCt。オースティン、TX 78727米国
EMail: Nicolas.Williams@sun.com
メールアドレス：Nicolas.Williams@sun.com
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
アレクセイ・メルニコフISODE株式会社5つのキャッスルビジネス村、36の駅道ハンプトン、ミドルTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。