Network Working Group B. Aboba
Request for Comments: 4282 Microsoft
Obsoletes: 2486 M. Beadles
Category: Standards Track ENDFORCE
J. Arkko
Ericsson
P. Eronen
Nokia
December 2005
The Network Access Identifier
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
抽象
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC.
ローミングサービスを提供するためには、ユーザを識別するための標準化された方法が必要です。この文書では、ネットワークアクセス識別子（NAI）、ネットワーク認証中に、クライアントによって送信されたユーザーのアイデンティティのための構文を定義します。緩くつのみと正式な顧客ベンダー関係を維持しながら、複数のインターネットサービスプロバイダ（ISP）のいずれかを使用する能力として定義することができる「ローミング」。ローミング機能が必要になることがあります場所の例としては、ISP「コンフェデレーションズ」とISPが提供する企業ネットワークへのアクセスのサポートが含まれています。この文書は、元々のNAIを定義したRFC 2486の改訂版です。機能強化は、国際文字セットおよびプライバシーのサポートだけでなく、オリジナルのRFCに訂正数が含まれます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................4
1.3. Purpose ....................................................4
2. NAI Definition ..................................................4
2.1. Formal Syntax ..............................................4
2.2. NAI Length Considerations ..................................6
2.3. Support for Username Privacy ...............................6
2.4. International Character Sets ...............................7
2.5. Compatibility with E-Mail Usernames ........................8
2.6. Compatibility with DNS .....................................8
2.7. Realm Construction .........................................8
2.8. Examples ..................................................10
3. Security Considerations ........................................10
4. IANA Considerations ............................................11
5. References .....................................................11
5.1. Normative References ......................................11
5.2. Informative References ....................................12
Appendix A. Changes from RFC 2486 ................................14
Appendix B. Acknowledgements .....................................14
Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included the following:
かなりの関心は、ダイヤルアップインターネットユーザー、仮想プライベートネットワーク（VPN）の使用、無線LANの認証、および他のアプリケーションを含む、ネットワークアクセスのために、「ローミング機能」の一般的なカテゴリ内に収まる一連の機能のために存在します。利害関係者は、以下が含まれています：
o Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area.
O地域インターネットサービスプロバイダ（ISP）は、より広い領域に亘ってダイヤルアップサービスを提供するために、他の地域のプロバイダのものと努力を組み合わせるために探して、特定の都道府県内で動作します。
o National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent.
O全国のISPは、国のグループまたは大陸に、より包括的なダイヤルアップサービスを提供するために、別の国での一の以上のISPのものと彼らの操作を組み合わせることを希望します。
o Wireless LAN hotspots providing service to one or more ISPs.
OワイヤレスLANは、一の以上のISPにサービスを提供するホットスポット。
o Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the
O企業はグローバルベースで従業員のダイヤルアップサービスの包括的なパッケージを提供することを望みます。これらのサービスは、次のようなトンネリングプロトコルで有効になって、インターネットアクセス、VPN経由で企業イントラネットへのセキュアなアクセスを含むことができ
Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC2401].
ポイントツーポイントトンネリングプロトコル（PPTP）[RFC2637]、レイヤ2フォワーディング（L2F）プロトコル[RFC2341]、レイヤ2トンネリングプロトコル（L2TP）[RFC2661]、およびIPsecトンネルモード[RFC2401]。
In order to enhance the interoperability of roaming services, it is necessary to have a standardized method for identifying users. This document defines syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [RFC2194].
ローミングサービスの相互運用性を高めるためには、ユーザを識別するための標準化された方法を持っていることが必要です。この文書では、ネットワークアクセス識別子（NAI）のための構文を定義します。 NAI、そのセマンティクスの記述を使用する実装の例は、[RFC2194]に見出すことができます。
This document is a revised version of RFC 2486 [RFC2486], which originally defined NAIs. Differences and enhancements compared to RFC 2486 are listed in Appendix A.
この文書は、もともとのNAIを定義RFC 2486 [RFC2486]の改訂版です。 RFC 2486に比べて違いと機能強化は、付録Aに記載されています
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用しています：
Network Access Identifier
ネットワークアクセス識別子
The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication.
ネットワークアクセス識別子（NAI）はネットワークアクセス認証の際に、クライアントによって送信されたユーザーIDです。ローミングでは、NAIの目的は、ユーザを識別するために、ならびに認証要求のルーティングを補助することです。 NAIは、必ずしもユーザーの電子メールアドレスまたはアプリケーション層認証に提出し、ユーザーIDと同じではないかもしれないことに注意してください。
Network Access Server
ネットワーク・アクセス・サーバ
The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
ネットワークアクセスサーバー（NAS）は、クライアントがネットワークへのアクセスを得るためにに接続するデバイスです。 PPTPの用語では、これは、PPTPアクセスコンセントレータ（PAC）と呼ばれ、L2TPの用語においては、L2TPアクセスコンセントレータ（LAC）と呼ばれています。 IEEE 802.11では、アクセスポイントと呼ばれています。
Roaming Capability
ローミング機能
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
一つだけとの正式な顧客ベンダー関係を維持しながら、ローミング機能が緩く、複数のインターネットサービスプロバイダ（ISP）のいずれかを使用する能力として定義することができます。ローミング機能が必要になる場合があります例例としては、ISP「コンフェデレーションズ」とISPが提供する企業ネットワークへのアクセスのサポートが含まれています。
Tunneling Service
トンネリングサービス
A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One example of a tunneling service is secure access to corporate intranets via a Virtual Private Network (VPN).
トンネリングサービスは、PPTP、L2F、L2TP、およびIPSecトンネルモードのようなトンネリングプロトコルによって有効に任意のネットワークサービスです。トンネリングサービスの一例は、仮想プライベートネットワーク（VPN）経由で企業のイントラネットへのセキュアなアクセスです。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "任意"、 "推奨"、 "SHOULD"、および "the" はならない、[RFC2119]に記載されているように解釈されるべきです。
As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.
[RFC2194]で説明したように、プロバイダの提供するネットワーク・アクセス・サービスの数、およびコンソーシアムが急速に増加しているローミングに関与し、インターネットサービスプロバイダの数があります。
In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the Network Access Identifier (NAI) submitted by the user to the NAS in the initial network authentication. It is also expected that NASes will use the NAI as part of the process of opening a new tunnel, in order to determine the tunnel endpoint.
ローミング機能を提供することができるようにするために、要件の一つは、ユーザのホーム認証サーバを識別できるようにすることです。ローミングで使用するために、この関数は、初期ネットワーク認証でNASにユーザによって提出されたネットワークアクセス識別子（NAI）を介して達成されます。また、のNASは、トンネルエンドポイントを決定するために、新しいトンネルを開くプロセスの一部として、NAIを使用することが期待されます。
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC4234]. The grammar for the username is based on [RFC0821], and the grammar for the realm is an updated version of [RFC1035].
NAIのための文法は[RFC4234]に記載されているように増補バッカス - ナウアフォーム（ABNF）に記載され、以下に与えられます。 usernameの文法は[RFC0821]に基づいて、およびレルムの文法は[RFC1035]のアップデートバージョンです。
nai = username nai =/ "@" realm nai =/ username "@" realm
ない ＝ うせｒなめ ない ＝／ ”＠” れあｌｍ ない ＝／ うせｒなめ ”＠” れあｌｍ
username = dot-string dot-string = string dot-string =/ dot-string "." string string = char string =/ string char char = c char =/ "\" x c = %x21 ; '!' allowed ; '"' not allowed c =/ %x23 ; '#' allowed c =/ %x24 ; '$' allowed c =/ %x25 ; '%' allowed c =/ %x26 ; '&' allowed c =/ %x27 ; ''' allowed ; '(', ')' not allowed c =/ %x2A ; '*' allowed c =/ %x2B ; '+' allowed ; ',' not allowed c =/ %x2D ; '-' allowed ; '.' not allowed c =/ %x2F ; '/' allowed c =/ %x30-39 ; '0'-'9' allowed ; ';', ':', '<' not allowed c =/ %x3D ; '=' allowed ; '>' not allowed c =/ %x3F ; '?' allowed ; '@' not allowed c =/ %x41-5a ; 'A'-'Z' allowed ; '[', '\', ']' not allowed c =/ %x5E ; '^' allowed c =/ %x5F ; '_' allowed c =/ %x60 ; '`' allowed c =/ %x61-7A ; 'a'-'z' allowed c =/ %x7B ; '{' allowed c =/ %x7C ; '|' allowed c =/ %x7D ; '}' allowed c =/ %x7E ; '~' allowed ; DEL not allowed c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486) ; Where UTF-8-octet is any octet in the ; multi-octet UTF-8 representation of a ; unicode codepoint above %x7F. ; Note that c must also satisfy rules in ; Section 2.4, including, for instance, ; checking that no prohibited output is ; used (see also Section 2.3 of ; [RFC4013]). x = %x00-FF ; all 128 ASCII characters, no exception; ; as well as all UTF-8-octets as defined ; above (this was not allowed in ; RFC 2486). Note that x must nevertheless ; again satisfy the Section 2.4 rules.
ユーザ名=ドット列のドット列=文字列のドット列= /ドットの文字列「」文字列文字列=文字列= /列チャーチャー= Cチャー= / "\" ×C =％のX21。 '！'許可; '"' C = /％X23許可されていません。 '＃' は、C = /％X24許さ; '$' C = /％X25可; '％' は、C = /％X26許さ; '＆' C = /％X27許可; '' 'せ; '（'、'）C = /％X2Aは許されない; '*' C = /％X2Bせ; '+' せ;'、」C = /％x2D許されません; ' - '許可; '' C = /％x2F許されない; '/' C = /％x30-39可; '0' - '9' せ; ';'、 '：'、 '<' = C /％X3Dは許されません;「= 「許さ; '>' C = /％からx3F許可されていません。 ''？許可; C = /％x41-5a許可されていない '@'、 'A' - 許可 'Z'、 '['、 '\'、 ']' = C /％x5E許されない; '^ C' を許可= / ％x5F; '_' はC = /％X60せ; ''' C = /％x61-7Aせ; 'A' - 'z' は、C = /％x7Bせ; '{' C = /％x7Cせ;' |」 C = /％x7Dせ; '}' C = /％x7Eせ; '〜' は許可され、DELは、c = /％X80-FFは許されない; UTF-8オクテットは（ないRFC 2486で）許可;ここでUTF-8 ％のx7F上記のUnicodeコードポイント;のマルチオクテットUTF-8表現; -octetは、任意のオクテットであり、例えば、を含む、セクション2.4;ものルールを満たしている必要があり、そのC注全く禁止出力されないことをチェックします。 X =％X00-FF。;全128個のASCII文字、例外なく;（[RFC4013]ものセクション2.3を参照）を使用し、上記（これはで許可されなかった;同様に定義されるようなすべてのUTF-8オクテットとしてRFC 。再び2.4節の規則を満たす; 2486）は、xがそれにもかかわらず、必要があります。
realm = 1*( label "." ) label label = let-dig *(ldh-str) ldh-str = *( alpha / digit / "-" ) let-dig let-dig = alpha / digit alpha = %x41-5A ; 'A'-'Z' alpha =/ %x61-7A ; 'a'-'z' digit = %x30-39 ; '0'-'9'
レルム= 1 *（ラベル ""）ラベルlabel =レット掘削*（LDH-STR）をLDH-STR = *（アルファ/数字/ " - "）のlet-DIGのlet-DIG =アルファ/数字アルファ=％X41 -5A; 'A' - 'Z' =アルファ/％x61-7A。 'A' - 'Z' 桁=％x30-39。 '0' - '9'
Devices handling NAIs MUST support an NAI length of at least 72 octets. Support for an NAI length of 253 octets is RECOMMENDED. However, the following implementation issues should be considered:
NAIを扱うデバイスは、少なくとも72オクテットのNAI長をサポートしなければなりません。 253オクテットのNAI長のサポートが推奨されます。ただし、次の実装上の問題を考慮する必要があります。
o NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may be included in a RADIUS message and the maximum attribute length is 253 octets; RADIUS is unable to support NAI lengths beyond 253 octets.
OのNAIは、多くの場合、リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルのUser-Name属性に輸送されます。残念ながら、RFC 2865 [RFC2865]、セクション5.1は、「少なくとも63オクテットを処理する能力が推奨されています。」と述べていますその結果、すべてのデバイスを介して63個のオクテットを超えてのNAIを転送することはできないかもしれません。また、単一のUser-Name属性をRADIUSメッセージに含まれた最大属性の長さが253個のオクテットであることができるからです。 RADIUSは253個のオクテットを超えてNAIの長さをサポートすることができません。
o NAIs can also be transported in the User-Name attribute of Diameter [RFC3588], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. Unfortunately, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations apply.
9オクテット - OのNAIはまた、2 ^ 24までのコンテンツ長をサポート直径[RFC3588]のUser-Name属性に搬送することができます。結果として、唯一のDiameterノードによって処理のNAIは非常に長くすることができます。残念ながら、直径上で輸送NAIは、最終的に上記の制限が適用される場合には、RADIUSに変換することができます。
Interpretation of the username part of the NAI depends on the realm in question. Therefore, the "username" part SHOULD be treated as opaque data when processed by nodes that are not a part of the authoritative domain (in the sense of Section 4) for that realm.
NAIのユーザ名部分の解釈は、問題の領域に依存します。したがって、「ユーザ名」の部分は、そのレルムの（第4の意味で）権限のあるドメインの一部でないノードによって処理される不透明なデータとして扱われるべきです。
In some situations, NAIs are used together with a separate authentication method that can transfer the username part in a more secure manner to increase privacy. In this case, NAIs MAY be provided in an abbreviated form by omitting the username part. Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user.
いくつかの状況では、のNAIは、プライバシーを高めるために、より安全な方法でユーザ名部分を転送することができ、別の認証方法と一緒に使用されています。この場合、のNAIは、ユーザ名の一部を省略することによって省略形で提供されてもよいです。それは、ユーザ名が一意に単一のユーザを特定することを意図されているかどうかを決定するための明確な方法を提供するので、ユーザ名の一部を省略することは、そのような「匿名」として、固定されたユーザー名の部分を使用して上推奨されます。
For roaming purposes, it is typically necessary to locate the appropriate backend authentication server for the given NAI before the authentication conversation can proceed. As a result, the realm portion is typically required in order for the authentication exchange to be routed to the appropriate server.
目的をローミングするためには、認証の会話を進める前に与えられたNAIのための適切なバックエンド認証サーバを見つけるために通常必要です。結果として、レルム部分は、典型的には、適切なサーバにルーティングする認証交換のために必要とされます。
This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8 and processed with a certain algorithm to ensure a canonical representation. Internationalization of the realm portion of the NAI is based on "Internationalizing Domain Names in Applications (IDNA)" [RFC3490].
この仕様は、国際的なユーザ名とレルムの両方を可能にします。国際ユーザ名は、Unicode文字の使用に基づくUTF-8としてエンコードされ、標準的な表現を確実にするために、特定のアルゴリズムで処理されます。 NAIのレルム部分の国際化は、「アプリケーション（IDNA）で国際化ドメイン名」[RFC3490]に基づいています。
In order to ensure a canonical representation, characters of the username portion in an NAI MUST fulfill the ABNF in this specification as well as the requirements specified in [RFC4013]. These requirements consist of the following:
正規表現を確保するために、NAIにユーザ名部分の文字は、本明細書でABNFならびに[RFC4013]で指定された要件を満たさなければなりません。これらの要件は、次で構成されています。
o Mapping requirements, as specified in Section 2.1 of [RFC4013]. Mapping consists of mapping certain characters to others (such as SPACE) in order to increase the likelihood of correctly performed comparisons.
Oマッピングの要件、[RFC4013]のセクション2.1で指定されています。マッピングが正しく実行される比較の可能性を高めるために（スペースなど）他の人にマッピング特定の文字から成ります。
o Normalization requirements, as specified in Section 2.2 of [RFC4013], are also designed to assist in comparisons.
O正規化要件、[RFC4013]のセクション2.2で指定されるように、また比較を支援するために設計されています。
o Prohibited output. Certain characters are not permitted in correctly formed strings that follow Section 2.3 of [RFC4013]. Ensuring that NAIs conform to their ABNF is not sufficient; it is also necessary to ensure that they do not contain prohibited output.
O出力を禁止。特定の文字は、[RFC4013]のセクション2.3に従って正しく形成された文字列に許可されていません。 NAIは、彼らのABNFに適合していることを保証することは十分ではありません。彼らが禁止され、出力が含まれていないことを確実にするためにも必要です。
o Bidirectional characters are handled as specified in Section 2.4 of [RFC4013].
[RFC4013]のセクション2.4で指定されたO双方向文字が処理されます。
o Unassigned code points are specified in Section 2.5 of [RFC4013]. The use of unassigned code points is prohibited.
O未割り当てコードポイントは、[RFC4013]のセクション2.5で指定されています。未割り当てコードポイントの使用は禁止されています。
The mapping, normalization, and bidirectional character processing MUST be performed by end systems that take international text as input. In a network access setting, such systems are typically the client and the Authentication, Authorization, and Accounting (AAA) server. NAIs are sent over the wire in their canonical form, and tasks such as normalization do not typically need to be performed by nodes that just pass NAIs around or receive them from the network. End systems MUST also perform checking for prohibited output and unassigned code points. Other systems MAY perform such checks, when they know that a particular data item is an NAI.
マッピング、正規化、および双方向文字処理は、入力として、国際テキストを取るエンドシステムによって実行されなければなりません。ネットワークアクセスの設定では、このようなシステムは、典型的には、クライアントと認証、許可、アカウンティング（AAA）サーバです。 NAIは、それらの標準形式のワイヤを介して送信され、そしてそのような正規化などのタスクは、典型的には、ちょうど周りのNAIを渡したり、ネットワークからそれらを受信するノードによって実行される必要はありません。エンド・システムはまた、出力禁止と未割り当てコードポイントをチェックし実行しなければなりません。彼らは、特定のデータ項目がNAIであることを知っている場合、他のシステムは、このようなチェックを実行することができます。
The realm name is an "IDN-unaware domain name slot" as defined in [RFC3490]. That is, it can contain only ASCII characters. An implementation MAY support Internationalized Domain Names (IDNs) using the ToASCII operation; see [RFC3490] for more information.
レルム名は、[RFC3490]で定義されるように「IDN非対応のドメイン名スロット」です。つまり、ASCII文字のみを含めることができ、あります。実装は、もしToASCII操作を使用して、国際化ドメイン名（IDNドメインを）をサポートすることができます。詳細については、[RFC3490]を参照してください。
The responsibility for the conversion of internationalized domain names to ASCII is left for the end systems, such as network access clients and AAA servers. Similarly, we expect domain name comparisons, matching, resolution, and AAA routing to be performed on the ASCII versions of the internationalized domain names. This provides a canonical representation, ensures that intermediate systems such as AAA proxies do not need to perform translations, and can be expected to work through systems that are unaware of international character sets.
ASCIIへの国際化ドメイン名の変換のための責任は、そのようなネットワークアクセスクライアントおよびAAAサーバなどのエンドシステム、放置されています。同様に、我々は、国際化ドメイン名のASCIIバージョンで実行されるドメイン名の比較、照合、解像度、およびAAAルーティングを期待しています。これは、標準的な表現を提供するようAAAプロキシなどの中間システムが翻訳を実行する必要はありませんし、国際文字セットに気づいていないシステムを介して動作することが期待されることを保証します。
As proposed in this document, the Network Access Identifier is of the form user@realm. Please note that while the user portion of the NAI is based on the BNF described in [RFC0821], it has been extended for internationalization support as well as for purposes of Section 2.7, and is not necessarily compatible with the usernames used in e-mail. Note also that the internationalization requirements for NAIs and e-mail addresses are different, since the former need to be typed in only by the user himself and his own operator, not by others.
この文書で提案されているように、ネットワークアクセス識別子は、user @ realmの形式です。 [RFC0821]で説明NAIのユーザ部分はBNFに基づいていることに注意してください、それは国際化をサポートするため、ならびに2.7項の目的のために延長され、必ずしも電子メールで使用されるユーザ名と互換性がありませんされています。かつての必要性が唯一のユーザー自身と彼自身のオペレータではなく、他の人によってによってで入力されるので、のNAIと電子メールアドレスのための国際化要件は、異なっていることにも注意してください。
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035]. This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035], Fully Qualified Domain Names (FQDNs) such as 3com.com are commonly used and accepted by current software.
レルム部分のBNFは、レルムが[RFC1035]に記載のBNFによって許可されていない数字で開始することを可能にします。この変更は、現在の慣行を反映しました。 [RFC1035]に記載のBNFで許可されていないが、そのような3com.comなどの完全修飾ドメイン名（FQDN）が一般的に使用され、現在のソフトウェアにより受け入れられます。
NAIs are used, among other purposes, for routing AAA transactions to the user's home realm. Usually, the home realm appears in the realm portion of the NAI, but in some cases a different realm can be used. This may be useful, for instance, when the home realm is reachable only via another mediating realm.
NAIは、ユーザのホームレルムにAAAトランザクションをルーティングするために、他の目的の中で、使用されています。通常、ホーム領域は、NAIの分野の部分に表示されますが、いくつかのケースで異なるレルムが使用することができます。ホーム領域のみを別の仲介領域を経由して到達可能であるとき、これは、例えば、有用である可能性があります。
Such usage may prevent interoperability unless the parties involved have a mutual agreement that the usage is allowed. In particular, NAIs MUST NOT use a different realm than the home realm unless the sender has explicit knowledge that (a) the specified other realm is available and (b) the other realm supports such usage. The sender may determine the fulfillment of these conditions through a database, dynamic discovery, or other means not specified here. Note that the first condition is affected by roaming, as the availability of the other realm may depend on the user's location or the desired application.
関係者は、使用が許可されていることを相互の合意がない限り、このような使用方法は、相互運用性を防ぐことができます。送信者は、（a）は、指定された他のレルムが利用可能であり、（b）は、他のレルムがこのような使用をサポートしていることを明示的な知識を持っていない限り、特に、のNAIは、ホーム領域とは異なるレルムを使用してはなりません。送信者は、ここで指定されていないデータベース、動的検出、または他の手段を介してこれらの条件の成就を決定してもよいです。他のレルムの可用性、ユーザの位置又は所望の用途に依存することができるように、第1の条件は、ローミングによって影響されることに留意されたいです。
The use of the home realm MUST be the default unless otherwise configured.
それ以外の場合は設定されない限り、ホーム領域の使用がデフォルトでなければなりません。
Where these conditions are fulfilled, an NAI such as
これらの条件は、NAIを満たされている場合など、
user@homerealm.example.net
うせｒ＠ほめれあｌｍ。えぁｍｐぇ。ねｔ
MAY be represented as in
のように表すことができます
homerealm.example.net!user@otherrealm.example.net
ほめれあｌｍ。えぁｍｐぇ。ねｔ！うせｒ＠おてぇっれあｌｍ。えぁｍｐぇ。ねｔ
In this case, the part before the (non-escaped) '!' MUST be a realm name as defined in the ABNF in Section 2.1. This realm name is an "IDN-unaware domain name slot", just like the realm name after the "@" character; see Section 2.4 for details. When receiving such an NAI, the other realm MUST convert the format back to "user@homerealm.example.net" when passing the NAI forward, as well as applying appropriate AAA routing for the transaction.
この場合には、（非エスケープ）の前の部分「！」 2.1節でABNFで定義されたレルム名でなければなりません。このレルム名は「@」文字の後だけレルム名のように、「IDN非対応のドメイン名スロット」です。詳細については、セクション2.4を参照してください。そのようなNAIを受信した場合、前方NAIを渡し、ならびにトランザクションのための適切なAAAルーティングを適用する場合、他の領域は、バック「user@homerealm.example.net」の形式を変換しなければなりません。
The conversion process may apply also recursively. That is, after the conversion, the result may still have one or more '!' characters in the username. For instance, the NAI
変換プロセスは再帰的にも適用される場合があります。これは、変換した後、結果はまだ一つ以上を有していてもよく、あります「！」ユーザ名の文字。例えば、NAI
other2.example.net!home.example.net!user@other1.example.net
おてぇｒ２。えぁｍｐぇ。ねｔ！ほめ。えぁｍｐぇ。ねｔ！うせｒ＠おてぇｒ１。えぁｍｐぇ。ねｔ
would first be converted in other1.example.net to
最初にother1.example.netに変換されます
home.example.net!user@other2.example.net
ほめ。えぁｍｐぇ。ねｔ！うせｒ＠おてぇｒ２。えぁｍｐぇ。ねｔ
and then at other2.example.net finally to
その後、other2.example.netで、最終的に
user@homerealm.example.net
うせｒ＠ほめれあｌｍ。えぁｍｐぇ。ねｔ
Note that the syntax described in this section is optional and is not a part of the ABNF. The '!' character may appear in the username portion of an NAI for other purposes as well, and in those cases, the rules outlined here do not apply; the interpretation of the username is up to an agreement between the identified user and the realm given after the '@' character.
このセクションで説明する構文はオプションであり、ABNFの一部ではないことに留意されたいです。 「！」文字は、他の目的のためにNAIのユーザ名部分に表示されることがあり、それらの例には、ここで説明するルールは適用されません。ユーザ名の解釈は、特定されたユーザと「@」文字の後に指定した領域との間の合意次第です。
Examples of valid Network Access Identifiers include the following:
有効なネットワークアクセス識別子の例としては次のものがあります。
bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.net
alice@xn--tmonesimerkki-bfbb.example.net
The last example uses an IDN converted into an ASCII representation.
最後の例は、IDNは、ASCII表現に変換使用しています。
Examples of invalid Network Access Identifiers include the following:
無効なネットワークアクセス識別子の例としては次のものがあります。
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.net
Since an NAI reveals the home affiliation of a user, it may assist an attacker in further probing the username space. Typically, this problem is of most concern in protocols that transmit the username in clear-text across the Internet, such as in RADIUS, described in [RFC2865] and [RFC2866]. In order to prevent snooping of the username, protocols may use confidentiality services provided by protocols transporting them, such as RADIUS protected by IPsec [RFC3579] or Diameter protected by TLS [RFC3588].
NAIは、ユーザのホーム・所属を明らかにしているので、それはさらに、ユーザー名スペースをプロービングで、攻撃者を助けることができます。典型的には、この問題は、ほとんどの[RFC2865]に記載のようなRADIUSのようにインターネットを介してクリアテキストでのユーザ名を送信するプロトコルで懸念、および[RFC2866]です。ユーザ名のスヌーピングを防止するために、プロトコルは、TLS [RFC3588]で保護のIPsec [RFC3579]または直径によって保護RADIUSなどのそれらの輸送プロトコルが提供する機密性サービスを使用することができます。
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.3, this is possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. In some cases, application-specific privacy mechanism have also been used with NAIs. For instance, some Extensible Authentication Protocol (EAP) methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. While neither of these approaches can protect the realm part, their advantage over transport protection is that privacy of the username is protected, even through intermediate nodes such as NASes.
この仕様は、それを省略することにより、NAIにユーザ名部分を隠す可能性が追加されます。セクション2.3で議論するように、これはのNAIは、安全な方法でユーザ名を転送することができる別の認証方法と一緒に使用される場合にのみ可能です。いくつかのケースでは、アプリケーション固有のプライバシーメカニズムものNAIで使用されています。例えば、いくつかの拡張認証プロトコル（EAP）メソッドはNAI [RFC3748]のユーザー名部分にメソッド固有偽名を適用します。これらのアプローチのどちらがレルム部分を保護することができますが、トランスポート保護を超えるその利点は、ユーザー名のプライバシーがさえなどのNASのような中間ノードを介して、保護されていることです。
In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace.
新たな行政手続きを作成しないようにするためには、NAIレルムの名前空間の管理は、DNS名前空間の管理に便乗します。
NAI realm names are required to be unique, and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Those wishing to use an NAI realm name should first acquire the rights to use the corresponding FQDN. Using an NAI realm without ownership of the corresponding FQDN creates the possibility of conflict and therefore is to be discouraged.
NAIレルム名は一意であることが要求されている、との目的をローミングに与えられたNAIレルムを使用する権利は、特定の完全修飾ドメイン名（FQDN）を使用する権利を取得して一致を得ています。 NAIのレルム名を使用することを希望される方は、最初に対応するFQDNを使用する権利を取得する必要があります。対応するFQDNの所有権なしNAIのレルムを使用すると、衝突の可能性を作成し、したがって、推奨されるべきです。
Note that the use of an FQDN as the realm name does not require use of the DNS for location of the authentication server. While Diameter [RFC3588] supports the use of DNS for location of authentication servers, existing RADIUS implementations typically use proxy configuration files in order to locate authentication servers within a domain and perform authentication routing. The implementations described in [RFC2194] did not use DNS for location of the authentication server within a domain. Similarly, existing implementations have not found a need for dynamic routing protocols or propagation of global routing information. Note also that there is no requirement that the NAI represent a valid email address.
レルム名としてFQDNを使用すると、認証サーバーの場所のためのDNSの使用を必要としないことに注意してください。直径[RFC3588]は、認証サーバの位置のためのDNSの使用をサポートしながら、既存のRADIUS実装は、典型的には、ドメイン内の認証サーバを見つけて認証ルーティングを実行するためにプロキシ設定ファイルを使用します。 [RFC2194]に記載される実施は、ドメイン内の認証サーバの位置については、DNSを使用しませんでした。同様に、既存の実装は、動的ルーティングプロトコルまたはグローバルルーティング情報の伝搬のための必要性を見つけていません。 NAIは、有効なメールアドレスを表す必要はないことにも注意してください。
[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月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[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月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[RFC2194] Aboba、B.、陸、J.、オールソップ、J.、鼎、J.、およびW.ワング、 "ローミング実装のレビュー"、RFC 2194、1997年9月。
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2341]バレンシア、A.、リトルウッド、M.、およびT.コーラール、 "シスコレイヤ二フォワーディング（プロトコル） "L2F""、RFC 2341、1998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.、およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル"、RFC 2637、1999年7月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル" [RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", Work in Progress, October 2005.
[netsel-問題] Arkko、J.、およびB. Aboba、 "ネットワーク探索と選択問題"、進歩、2005年10月に作業。
Appendix A. Changes from
付録A.からの変更点
This document contains the following updates with respect to the original NAI definition in RFC 2486 [RFC2486]:
この文書は、RFC 2486 [RFC2486]でオリジナルのNAIの定義に関して、以下の更新プログラムが含まれています。
o International character set support has been added for both usernames and realms. Note that this implies character codes 128 - 255 may be used in the username portion, which may be unacceptable to nodes that only support RFC 2486. Many devices already allow this behaviour, however.
O国際文字セットのサポートは、ユーザ名とレルムの両方のために追加されました。しかし、唯一既にこの動作を可能にするRFC 2486.多くのデバイスをサポートしているノードに受け入れられないかもしれ255ユーザ名部分に使用することができる、 - これは128文字コードを意味することに注意してください。
o Username privacy support has been added. Note that NAIs without a username (for privacy) may not be acceptable to RFC 2486-compliant nodes. Many devices already allow this behaviour, however.
ユーザー名Oプライバシーのサポートが追加されました。 （プライバシーのための）ユーザ名なしでのNAIは、RFC 2486に準拠したノードに許容されないかもしれないことに留意されたいです。多くのデバイスは、すでにしかし、この動作を可能にします。
o A recommendation to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. Note that long NAIs may not be acceptable to RFC 2486-compliant nodes.
少なくとも253オクテットのNAIの長さをサポートするための推奨が追加されたO、および互換性の考慮NAIの中には、本明細書の長さおよび様々なAAAプロトコルが議論されています。長いのNAIは、RFC 2486準拠のノードに許容可能ではないかもしれないことに注意してください。
o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [netsel-problem]. Rather, it is intended as a clarification of RFC 2486.
仲介ネットワーク構文とその意味oを十分に説明されており、例としてのみ与えられていません。この構文は[netsel-問題]で定義されている発見と選択のニーズをネットワークに完全なソリューションであることが意図されていないことに注意してください。むしろ、それは、RFC 2486の明確化を目的としています。
However, as discussed in Section 2.7, this specification requires that this syntax be applied only when there is explicit knowledge that the peer system supports such syntax.
セクション2.7で議論するようにしかし、本明細書は、ピア・システムは、このような構文をサポートしていることを明示的な知識がある場合にのみ、この構文が適用されることを必要とします。
o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification.
OレルムBNFエントリの定義は、元の仕様に誤り（無限の再帰）を回避するために変更されています。
o Several clarifications and improvements have been incorporated into the ABNF specification for NAIs.
Oのいくつかの明確化と改善がのNAIのためのABNF仕様に組み込まれています。
Appendix B. Acknowledgements
付録B.謝辞
Thanks to Glen Zorn for many useful discussions of this problem space, and to Farid Adrangi for suggesting the representation of mediating networks in NAIs. Jonathan Rosenberg reported the BNF error. Dale Worley suggested clarifications of the x and special BNF entries. Arne Norefors reported the length differences between RFC 2486 and RFC 2865. Paul Hoffman helped with the international character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam Hartman, and Richard Perlman provided many useful comments on this document. The ABNF validator at http://www.apps.ietf.org/abnf.html was used to verify the syntactic correctness of the ABNF in Section 2.1.
NAIでネットワークを媒介する表現を示唆ため、この問題空間の多くの有用な議論のためのグレンツォルンのおかげで、とファリドAdrangiへ。ジョナサン・ローゼンバーグは、BNFのエラーを報告しました。デールウォーリーは、xと特別なBNFエントリーの明確化を示唆しました。アルネNoreforsは、RFC 2486およびRFC 2865ポール・ホフマンとの間の長さの違いを報告した国際的な文字セットの問題を手伝ってくれました。カレTammela、StefaanデCnodder、ナギJonnala、バートWijnen、ブレアBullockの、義弘大場、イグナシオGoyret、ジョンLoughney、ヘンリクLevkowetz、テッドハーディー、ビルフェナー、サム・ハートマン、そしてリチャード・パールマンは、この文書には、多くの有益なコメントを提供しました。 http://www.apps.ietf.org/abnf.htmlでABNFバリデータは、セクション2.1でABNF構文の正しさを検証するために使用しました。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com
Mark A. Beadles ENDFORCE 565 Metro Place South Suite 300 Dublin OH 43017 USA
マーク・A. Beadles ENDFORCE 565メトロ置き南スイート300ダブリンOH 43017 USA
EMail: mbeadles@endforce.com
メールアドレス：mbeadles@endforce.com
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.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 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機能のための基金は現在、インターネット協会によって提供されます。