RFC4282 日本語訳
4282 The Network Access Identifier. B. Aboba, M. Beadles, J. Arkko, P.Eronen. December 2005. (Format: TXT=34421 bytes) (Obsoletes RFC2486) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 4282 マイクロソフトは以下を時代遅れにします。 2486年のM.用務員カテゴリ: 標準化過程ENDFORCE J.ArkkoエリクソンP.Eronenノキア2005年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
ローミング・サービスを提供するために、ユーザを特定するための標準化法を持つのが必要です。 このドキュメントはNetwork Access Identifier(NAI)のために構文を定義します、とユーザアイデンティティがネットワーク認証の間、クライアントで提出しました。 「ローミング」は1だけとの正式な顧客ベンダー関係を維持している間、緩く複数のインターネットサービスプロバイダ(ISP)のどれかを使用する能力と定義されるかもしれません。 ローミング能力が必要であるかもしれないところに関する例はISP「同盟者」とISPに提供された企業ネットワークアクセスサポートを含んでいます。 このドキュメントはRFC2486の改訂版です。(RFCは元々、NAIsを定義しました)。 増進は国際的な人物セット、プライバシーサポート、および多くの修正をオリジナルのRFCに含んでいます。
Aboba, et al. Standards Track [Page 1] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[1ページ]。
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
1. 序論…2 1.1. 用語…3 1.2. 要件言語…4 1.3. 目的…4 2. NAI定義…4 2.1. 正式な構文…4 2.2. NAI長さの問題…6 2.3. ユーザ名には、プライバシーをサポートしてください…6 2.4. 国際的な人物はセットします…7 2.5. メールユーザ名との互換性…8 2.6. DNSとの互換性…8 2.7. 分野工事…8 2.8. 例…10 3. セキュリティ問題…10 4. IANA問題…11 5. 参照…11 5.1. 標準の参照…11 5.2. 有益な参照…12 付録A.はRFC2486から変化します…14 付録B.承認…14
1. Introduction
1. 序論
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:
相当な興味はネットワークアクセスのための「ローミング能力」の一般的なカテゴリの中で合う1セットの特徴のために存在しています、ダイアルアップインターネットユーザ、Virtual兵士のNetwork(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 国のグループか大陸の上で、より包括的なダイアルアップサービスを提供するためにもう1人の国の1つ以上のISPのものに彼らの操作を結合したがっている国家のISP。
o Wireless LAN hotspots providing service to one or more ISPs.
o 1つ以上のISPに対するサービスを提供する無線LANホットスポット。
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を通して企業イントラネットにアクセスして、トンネルを堀っているプロトコルを可能にしたインターネットを含むかもしれません。
Aboba, et al. Standards Track [Page 2] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[2ページ]。
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].
指すポイントTunnelingプロトコル(PPTP)[RFC2637]、Layer2Forwarding(L2F)は[RFC2341]、Layer2Tunnelingプロトコル(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].
ローミング・サービスの相互運用性を高めるために、ユーザを特定するための標準化法を持つのが必要です。 このドキュメントはNetwork Access Identifier(NAI)のために構文を定義します。 [RFC2194]でNAIを使用する実装に関する例、および意味論の記述を見つけることができます。
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.
このドキュメントはRFC2486[RFC2486]の改訂版です。(RFCは元々、NAIsを定義しました)。 RFC2486と比較された違いと増進はAppendix Aに記載されています。
1.1. Terminology
1.1. 用語
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.
Network Access Identifier(NAI)はネットワークアクセス認証の間にクライアントによって提出されたユーザアイデンティティです。 ローミングでは、NAIの目的は、ユーザを特定して、認証要求のルーティングを助けることです。 ユーザのEメールアドレスかユーザアイデンティティが応用層認証で提出したようにNAIは必ず同じであるかもしれないというわけではありません。
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.
Network Access Server(NAS)はクライアントがネットワークに近づく手段を得るために接続するデバイスです。 PPTP用語で、これはPPTP Access Concentrator(PAC)と呼ばれます、そして、L2TP用語で、それはL2TP Access Concentrator(LAC)と呼ばれます。 IEEE802.11では、それはAccess Pointと呼ばれます。
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.
1だけとの正式な顧客ベンダー関係を維持している間、緩く複数のインターネットサービスプロバイダ(ISP)のどれかを使用する能力とローミング能力を定義できます。 ローミング能力が必要であるかもしれないケースに関する例はISP「同盟者」とISPに提供された企業ネットワークアクセスサポートを含んでいます。
Aboba, et al. Standards Track [Page 3] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[3ページ]。
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トンネルモードなどのトンネリングプロトコルによって可能にされたあらゆるネットワーク・サービスです。 トンネリングサービスの1つの例はVirtual兵士のNetwork(VPN)を通した企業イントラネットへの安全なアクセスです。
1.2. Requirements Language
1.2. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[RFC2119]で説明されるように解釈されることになっていてください、」であるべきです
1.3. Purpose
1.3. 目的
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.
ローミング能力を提供できるように、要件の1つはユーザのホーム認証サーバを特定することであることができます。ローミングにおける使用において、この機能はユーザによって初期のネットワーク認証でNASに提出されたNetwork Access Identifier(NAI)を通して達成されます。 また、NASesが新しいトンネルを開けるプロセスの一部としてNAIを使用すると予想されます、トンネル終点を決定するために。
2. NAI Definition
2. NAI定義
2.1. Formal Syntax
2.1. 正式な構文
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].
[RFC4234]に記録されるようにAugmented BN記法(ABNF)で説明されて、NAIのための文法を以下に与えます。 ユーザ名のための文法は[RFC0821]に基づいています、そして、分野への文法は[RFC1035]のアップデートされたバージョンです。
nai = username nai =/ "@" realm nai =/ username "@" realm
naiはユーザ名nai=/"@"分野nai=/ユーザ名"@"分野と等しいです。
username = dot-string dot-string = string dot-string =/ dot-string "." string string = char string =/ string char char = c char =/ "\" x
「ユーザ名=ドットストリングドットストリングはストリングドットストリングドット=/ストリングと等しいです」。c/ストリング炭」 ストリングストリング=炭ストリング=炭=炭は/「\」xと等しいです。
Aboba, et al. Standards Track [Page 4] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[4ページ]。
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=%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を許容しませんでした。 許容された''--'Z'。 '[''\'、']'はc=/%x5Eを許容しませんでした。 '^'はc=/%x5Fを許容しました。 '_'はc=/%x60を許容しました。 ''許容c=/%'x61-7A'。 'a'--'z'はc=/%x7Bを許容しました。 ''許容c=/%x7C'| '許容c=/%x7D''はc=/%x7Eを許容しました。 許容された'~'。 DELはc=/%x80-FFを許容しませんでした。 許容された(どんなRFC2486でも、そうしません)UTF8八重奏。 UTF8八重奏があらゆる八重奏であるところ、。 aのマルチ八重奏UTF-8表現。 %x7Fの上のユニコードcodepoint。 ; また、そのcが規則を満たさなければならないことに注意してください。 セクション2.4、例えば、包含。 いいえが出力を禁止したのをチェックするのは、そうです。 中古である、(また、セクション2.3を見てください、; [RFC4013) x=%x00-FF。 128人のASCII文字、すべての例外がありません。 ; 定義されるとしてのすべてのUTF8八重奏と同様に。 上では、(これが中に許容されませんでした; RFC2486。) それにもかかわらず、xがそうしなければならないことに注意してください。 もう一度セクション2.4規則を満たしてください。
realm = 1*( label "." ) label label = let-dig *(ldh-str)
「分野=1*、(ラベル、」、」、)、皮肉をさせている*とラベル=をラベルしてください。(ldh-str)
Aboba, et al. Standards Track [Page 5] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[5ページ]。
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'
ldh-strが*と等しい、(アルファ/ケタ/「-」)皮肉をさせる、皮肉をさせる、=アルファ/ケタアルファー=%x41-5A。 ''--'Z'アルファ=/%x61-7A。 'a'--'z'ケタ=%x30-39。 '0'-'9'
2.2. NAI Length Considerations
2.2. NAI長さの問題
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:
デバイス取り扱いNAIsは、NAIが少なくとも72の八重奏の長さであるとサポートしなければなりません。 253の八重奏のNAIの長さのサポートはRECOMMENDEDです。 しかしながら、以下の導入問題は考えられるべきです:
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 NAIsは中のRemote Authentication Dial User Service(RADIUS)プロトコルのUser-名前属性でしばしば輸送されます。 残念ながら、「少なくとも63の八重奏を扱う能力はお勧めです。」と、RFC2865[RFC2865](セクション5.1)は述べます。 その結果、すべてのデバイスを通して63の八重奏を超えてNAIsを移すのは可能でないかもしれません。 さらに、RADIUSにただ一つのUser-名前属性だけを含んでもよいので、メッセージと最大の属性の長さは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.
o また、Diameter[RFC3588]のUser-名前属性でNAIsを輸送できます--9つの八重奏。Diameterはコンテンツの長さが最大2^24であるとサポートします。 その結果、Diameterノードだけによって処理されたNAIsは非常に長い場合があります。 残念ながら、Diameterの上で輸送されたNAIは結局RADIUSに翻訳されるかもしれません、その場合、上の制限が適用されます。
2.3. Support for Username Privacy
2.3. ユーザ名プライバシーのサポート
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の意味で)したがって、「ユーザ名」パートSHOULDの分野。
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.
いくつかの状況で、NAIsはプライバシーを増強するために、より安全な方法でユーザ名部分を移すことができる別々の認証方法と共に使用されます。 この場合、ユーザ名部分を省略することによって、簡略化されたフォームにNAIsを提供するかもしれません。 ユーザ名部分を省略するのは、固定ユーザ名部分を使用する上のRECOMMENDEDです、「匿名であること」のように、ユーザ名が唯一シングルユーザーを特定することを意図するかどうか決定する明白な方法を提供するので。
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
ローミング目的に、認証の会話が続くことができる前に与えられたNAIのための適切なバックエンド認証サーバの場所を見つけるのが通常必要です。 結果、分野として
Aboba, et al. Standards Track [Page 6] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[6ページ]。
portion is typically required in order for the authentication exchange to be routed to the appropriate server.
部分が、認証交換が適切なサーバに発送されるのに通常必要です。
2.4. International Character Sets
2.4. 国際的な人物セット
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].
この仕様は国際的なユーザ名と分野の両方を許容します。国際ユーザ名は、正準な表現を確実にするためにユニコード文字の使用に基づいていて、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 MUSTのユーザ名部分のキャラクタは[RFC4013]で指定された要件と同様にこの仕様にABNFを実現させます。 これらの要件は以下から成ります:
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で指定されるように要件を写像します。 マッピングは正しく実行された比較の可能性を広げるために他のもの(SPACEなどの)への確信しているキャラクタを写像するのから成ります。
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に続く正しく形成されたストリングで受入れられません。 NAIsが彼らのABNFに従うのを確実にするのは十分ではありません。 また、禁止された出力を含まないのを保証するのも必要です。
o Bidirectional characters are handled as specified in Section 2.4 of [RFC4013].
o 双方向のキャラクタは[RFC4013]のセクション2.4で指定されるように扱われます。
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.
入力されるように国際的なテキストを取るエンドシステムでマッピング、正常化、および双方向の文字処理を実行しなければなりません。 ネットワークアクセス設定では、そのようなシステムは、通常クライアントと、Authenticationと、Authorizationと、Accounting(AAA)サーバです。彼らの標準形でワイヤの上にNAIsを送ります、そして、正常化などのタスクはただNAIsを回すか、またはネットワークから彼らを受けるノードで通常実行する必要はありません。 また、エンドシステムは禁止された出力と割り当てられなかったコード・ポイントのための照合を実行しなければなりません。 特定のデータ項目がNAIであることを知っているとき、他のシステムはそのようなチェックを実行するかもしれません。
Aboba, et al. Standards Track [Page 7] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[7ページ]。
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操作を使用して、実装はInternationalized Domain Names(IDNs)をサポートするかもしれません。 詳しい情報に関して[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サーバのように。 同様に、私たちは、ドメイン名比較、マッチング、解決、およびAAAルーティングが国際化ドメイン名のASCII版に実行されると予想します。 これを、正準な表現を前提として、AAAプロキシなどの中間システムが翻訳を実行する必要はないのを確実にして、国際的な人物セットに気づかない状態でシステムを終えると予想できます。
2.5. Compatibility with E-Mail Usernames
2.5. メールユーザ名との互換性
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.
本書では提案されるように、Network Access Identifierはフォーム user@realm のものです。 NAIのユーザ部分は[RFC0821]で説明されたBNFに基づいていますが、それは、国際化サポートとセクション2.7の目的のために拡張されて、必ずメールで使用されるユーザ名と互換性があるというわけではありません。 また、NAIsとEメールアドレスのための国際化要件が異なっていることに注意してください、前者が、他のものではなく、単にユーザ自身と彼自身のオペレータによってタイプされる必要があるので。
2.6. Compatibility with DNS
2.6. DNSとの互換性
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などのFully Qualified Domain Names(FQDNs)を一般的に使用して、受け入れます。
2.7. Realm Construction
2.7. 分野工事
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.
NAIsはルーティング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
かかわったパーティーに用法が許容されている合意がないなら、そのような用法は相互運用性を防ぐかもしれません。 送付者には、形式知があります。特に、NAIsがホーム分野と異なった分野を使用してはいけない、(b) (a) 指定された他の分野は利用可能であり、もう片方の分野はそのような用法をサポートします。 送付者
Aboba, et al. Standards Track [Page 8] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[8ページ]。
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.
ここで指定されなかったデータベース、ダイナミックな発見、または他の手段によるこれらの状態の遂行を決定するかもしれません。 最初の状態がローミングで影響を受けることに注意してください、もう片方の分野の有用性がユーザの位置か必要なアプリケーションによるとき。
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
user@homerealm.example.net
MAY be represented as in
同じくらい中に表されるかもしれません。
homerealm.example.net!user@otherrealm.example.net
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を受けるとき、トランザクションのために適切なトリプルAルーティングを適用することと同様にNAIを前方へパスするとき、もう片方の分野は" 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
変換プロセスは再帰的にも適用されるかもしれません。 すなわち、変換の後に、結果に、1つ以上の'!'キャラクタがユーザ名にまだあるかもしれません。 例えば、NAI
other2.example.net!home.example.net!user@other1.example.net
other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to
1番目はother1.example.netで変換されるでしょう。
home.example.net!user@other2.example.net
home.example.net!user@other2.example.net
and then at other2.example.net finally to
other2.example.netのその時、最終的
user@homerealm.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のユーザ名一部でまた、他の目的に見えるかもしれません、そして、それらの場合では、ここに概説された規則は申し込まれません。 ユーザ名の解釈は特定されたユーザと分野との間'@'キャラクタの後に与えられた協定まで達しています。
Aboba, et al. Standards Track [Page 9] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[9ページ]。
2.8. Examples
2.8. 例
Examples of valid Network Access Identifiers include the following:
有効なNetwork Access Identifiersに関する例は以下を含んでいます:
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
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.
最後の例はASCII表現に変換されたIDNを使用します。
Examples of invalid Network Access Identifiers include the following:
無効のNetwork Access Identifiersに関する例は以下を含んでいます:
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
fred@example fred@example_9.com fred@example.net@example.net fred.@example.net eng: nancy@example.net eng; nancy@example.net(ユーザ) @example.net <nancy>@example.net
3. Security Considerations
3. セキュリティ問題
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]と[RFC2866]で説明されたRADIUSなどのほとんどの関心のものです。 ユーザ名について詮索するのを防ぐために、プロトコルはそれらを輸送しながら、プロトコルによって提供された秘密性サービスを利用するかもしれません、IPsecによって保護されたRADIUS[RFC3579]やTLSによって保護されたDiameter[RFC3588]のように。
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
この仕様はNAIにそれを省略することによってユーザ名部分を隠す可能性を加えます。 NAIsが安全な方法によるユーザ名を移すことができる別々の認証方法と共に使用されるときだけ、セクション2.3で議論するように、これは可能です。 いくつかでは、ケース、アプリケーション特有のプライバシーメカニズムはそうしました。
Aboba, et al. Standards Track [Page 10] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[10ページ]。
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.
また、NAIsと共に使用されます。 例えば、いくつかの拡張認証プロトコル(EAP)メソッドがNAI[RFC3748]のユーザ名部分でメソッド特有の匿名を当てはまります。 これらのアプローチのどちらも分野の部分を保護できませんが、輸送保護よりそれらの利点はユーザ名のプライバシーが保護されるということです、NASesなどの中間的ノードさえを通して。
4. IANA Considerations
4. IANA問題
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分野を使用する権利は特定のFully Qualified Domain Name(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の認証サーバの位置の使用を必要としないことに注意してください。Diameter[RFC3588]がDNSの認証サーバの位置の使用をサポートしている間、既存のRADIUS実装は、ドメインの中で認証サーバの場所を見つけて、認証ルーティングを実行するのにプロキシ構成ファイルを通常使用します。 [RFC2194]で説明された実装は認証サーバの位置にドメインの中でDNSを使用しませんでした。 同様に、既存の実装はグローバルなルーティング情報のダイナミックルーティングプロトコルか伝播の必要性を見つけていません。 また、NAIが有効なEメールアドレスを表すという要件が全くないことに注意してください。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
Aboba, et al. Standards Track [Page 11] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[11ページ]。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
5.2. Informative References
5.2. 有益な参照
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
1997年9月の[RFC2194]AbobaとB.とLuとJ.とAlsopとJ.と鐘の音、J.とW.ワング、「ローミング実装のレビュー」RFC2194。
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2341]バレンシア(A.、リトルウッド、M.、およびT.コラール、「コクチマス層Twoの推進(プロトコル)"L2F"」RFC2341)は、1998がそうするかもしれません。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、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.ゾルン、「二地点間トンネリングプロトコル」、RFC2637(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.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、「半径会計」、RFC2866、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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
Aboba, et al. Standards Track [Page 12] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[12ページ]。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、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月に働いています。
Aboba, et al. Standards Track [Page 13] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[13ページ]。
Appendix A. Changes from RFC 2486
RFC2486からの付録A.変化
This document contains the following updates with respect to the original NAI definition in RFC 2486 [RFC2486]:
このドキュメントはRFC2486[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 国際的な人物セットサポートはユーザ名と分野の両方のために加えられます。これが、キャラクタが128--255をコード化するのを含意するというメモはユーザ名部分で使用されるかもしれません。(それは、RFCが2486であることを支えるだけであるノードに容認できないかもしれません)。 しかしながら、多くのデバイスが既にこのふるまいを許容します。
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 ユーザ名プライバシーサポートは加えられます。 ユーザ名(プライバシーのための)のないNAIsが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.
o NAIが少なくとも253の八重奏の長さであるとサポートするという推薦は加えられます、そして、この仕様によるNAIの長さの中の互換性問題と様々なAAAプロトコルについて議論します。 長いNAIsが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-問題]で定義されるように発見と選択の必要性をネットワークでつないでください。 むしろ、それはRFC2486の明確化として意図します。
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 いくつかの明確化と改良をNAIsのための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
この問題スペースの多くの役に立つ議論のためのGlenゾルンと、そして、仲介の表現を示すためのAdrangiがNAIsでネットワークでつなぐファリドをありがとうございます。 ジョナサン・ローゼンバーグはBNF誤りを報告しました。 デール・ウォーリーはxと特別なBNFエントリーの明確化を勧めました。 アーンNoreforsはRFC2486とRFC2865の長さの差を報告しました。 ポール・ホフマンは国際的な人物セット問題で助けました。 Kalleタンメラ、Stefaan De Cnodder、奈義Jonnala、バートWijnen、ブレアBullock、芳広オオバ、イグナシオGoyret、ジョンLoughney、Henrik Levkowetz、テッド・ハーディー、ビル・フェナー、サム・ハートマン、およびリチャード・パールマンはこの多くの役に立つコメントを提供しました。
Aboba, et al. Standards Track [Page 14] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[14ページ]。
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.
記録します。 http://www.apps.ietf.org/abnf.html のABNF validatorは、セクション2.1のABNFの構文の正当性について確かめるのに使用されました。
Authors' Addresses
作者のアドレス
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: bernarda@microsoft.com
メール: bernarda@microsoft.com
Mark A. Beadles ENDFORCE 565 Metro Place South Suite 300 Dublin OH 43017 USA
おお、マークA.用務員ENDFORCE565の地下鉄の場所の南Suite300ダブリン43017米国
EMail: mbeadles@endforce.com
メール: mbeadles@endforce.com
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソンJorvas02420フィンランド
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フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Aboba, et al. Standards Track [Page 15] RFC 4282 The Network Access Identifier December 2005
Aboba、他 規格はネットワークアクセス識別子2005年12月にRFC4282を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Aboba, et al. Standards Track [Page 16]
Aboba、他 標準化過程[16ページ]
一覧
スポンサーリンク