[要約] RFC 6116は、E.164番号をURIに変換するためのDDDSアプリケーション（ENUM）に関するものであり、ENUMの動的委任発見システムの目的は、E.164番号をURIに関連付けるための一貫性のある方法を提供することです。
Internet Engineering Task Force (IETF) S. Bradner
Request for Comments: 6116 Harvard University
Obsoletes: 3761 L. Conroy
Category: Standards Track Roke Manor Research
ISSN: 2070-1721 K. Fujiwara
JPRS
March 2011
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
E.164からユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（列挙）
Abstract
概要
This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761.
このドキュメントでは、E.164番号に関連付けられたデータの保存、およびテレフォニーコールのセットアップで使用できるURIにそれらの数値を解決するためのドメイン名システム（DNS）の使用について説明します。このドキュメントでは、DNSを使用してE.164番号に関連付けられたサービスを識別する方法についても説明しています。このドキュメントは、RFC 3761を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6116.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6116で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Use of These Mechanisms for Private Dialing Plans ...............4
3. The ENUM Application Specifications .............................4
3.1. Application Unique String ..................................4
3.2. First Well Known Rule ......................................5
3.3. Expected Output ............................................5
3.4. Valid Databases ............................................5
3.4.1. Optional Name Server Additional Section Processing ..6
3.4.2. Flags ...............................................6
3.4.3. Service Parameters ..................................7
3.4.3.1. ENUM Services ..............................7
3.4.3.2. Compound NAPTRs and Implicit
ORDER/PREFERENCE Values ....................8
3.5. The ENUM Algorithm Always Returns a Single Rule ............8
3.6. Case Sensitivity in ENUM ...................................8
3.7. Collision Avoidance ........................................9
4. ENUM Service Example ...........................................10
5. Clarification of DDDS Use in ENUM ..............................10
5.1. Collected Implications for ENUM Provisioning ..............11
5.2. Collected Implications for ENUM Clients ...................13
5.2.1. Non-Terminal NAPTR Processing ......................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. DNS Security ..............................................17
7.2. Caching Security ..........................................18
7.3. Call Routing Security .....................................19
7.4. URI Resolution Security ...................................19
8. Acknowledgements ...............................................19
9. Changes from RFC 3761 ..........................................19
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
This document discusses the use of the Domain Name System (DNS) [RFC1034] [RFC1035] for storage of data associated with E.164 [E.164] numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document includes a Dynamic Delegation Discovery System (DDDS) Application specification, as detailed in the document series described in [RFC3401]. This document obsoletes [RFC3761].
このドキュメントでは、E.164 [E.164]数に関連するデータの保存と、使用できるURIにそれらの数値を解決するために、ドメイン名システム（DNS）[RFC1034] [RFC1035]の使用について説明します（たとえば）テレフォニーコールセットアップで。このドキュメントでは、DNSを使用してE.164番号に関連付けられたサービスを識別する方法についても説明しています。このドキュメントには、[RFC3401]で説明されているドキュメントシリーズで詳述されているように、動的委任ディスカバリーシステム（DDDS）アプリケーション仕様が含まれています。この文書は廃止[RFC3761]。
Using the process defined in this document, International Public Telecommunication Numbers in the international format defined in International Telecommunications Union (ITU) Recommendation E.164 [E.164] (called here "E.164 numbers") can be transformed into DNS names. Using existing DNS services (such as delegation through NS records and queries for NAPTR resource records), one can look up the services associated with that E.164 number. This takes advantage of standard DNS architectural features of decentralized control and management of the different levels in the lookup process.
このドキュメントで定義されているプロセスを使用して、国際電気通信連合（ITU）推奨e.164 [E.164]で定義されている国際的な形式の国際的な通信数値（ここでは「E.164番号」と呼ばれます）はDNS名に変換できます。既存のDNSサービス（NAPTRリソースレコードのNSレコードやクエリを介した委任など）を使用すると、そのe.164番号に関連するサービスを検索できます。これにより、ルックアッププロセスのさまざまなレベルの分散制御と管理の標準的なDNSアーキテクチャの特徴を活用します。
The domain "e164.arpa" has been assigned to provide an infrastructure in the DNS for storage of data associated with E.164 numbers. To facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers who want these numbers to be listed in the DNS should contact the appropriate zone administrator as listed in the policy attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations.
ドメイン「E164.ARPA」は、E.164番号に関連付けられたデータを保存するためにDNSにインフラストラクチャを提供するように割り当てられています。分散操作を促進するために、このドメインはサブドメインに分割されます。これらの数値をDNSにリストしたいE.164番号の保有者は、ゾーンに添付されているポリシーにリストされている適切なゾーン管理者に連絡する必要があります。通常のDNS操作と同様に、ゾーンに関連付けられたSOAリソースレコードを調べることにより、この情報を探し始める必要があります。
Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.
もちろん、他のドメインと同様に、そのようなリストのポリシーはサブドメインベースで制御され、世界のさまざまな地域で異なる場合があります。
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 BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
DNS resource record types mentioned in this document are defined, respectively, in [RFC1035] (NS, SOA, A, MX), [RFC3403] (NAPTR), and [RFC2782] (SRV).
このドキュメントに記載されているDNSリソースレコードタイプは、それぞれ[RFC1035]（NS、SOA、A、MX）、[RFC3403]（NAPTR）、および[RFC2782]（SRV）で定義されています。
All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in [RFC3402].
他のすべての大文字は、[RFC3402]で見つかったDDDSアルゴリズムの仕様にある語彙から取得されます。
Similar mechanisms might be used for other kinds of digit strings (such as numbers in private dialing plans). If these mechanisms are used for dialing plans (or for other unrelated digit strings), the domain apex used for such translation MUST NOT be e164.arpa, to avoid conflict with this specification.
同様のメカニズムは、他の種類の桁の文字列に使用される場合があります（プライベートダイヤルプランの数字など）。これらのメカニズムがダイヤルプラン（または他の無関係な数字文字列）に使用される場合、この仕様との競合を避けるために、そのような翻訳に使用されるドメインの頂点はE164.ARPAであってはなりません。
Also, the Application Unique String (see Section 3.1) used with dialing plans SHOULD be the full number as specified, without the leading '+' character. The '+' character is used to further distinguish E.164 numbers in international format from dialed digit strings or other digit sequences.
また、ダイヤルプランで使用されるアプリケーションの一意の文字列（セクション3.1を参照）は、指定された完全な番号であり、主要な「」文字なしでなければなりません。''文字は、ダイヤルされた数字文字列またはその他の桁のシーケンスと国際形式のE.164数をさらに区別するために使用されます。
For example, to address the E.164 number +44-3069-990038 a user might dial "03069990038" or "00443069990038" or "011443069990038". These dialed digit strings differ from one another, but none of them start with the '+' character.
たとえば、E.164番号44-3069-990038に対処するために、ユーザーは「03069990038」または「0044306999999999999999999999999999999999999999999999998」をダイヤルする可能性があります。これらのダイヤルされた数字文字列は互いに異なりますが、どれも「キャラクター」から始まりません。
Finally, if these techniques are used for dialing plans or other digit strings, implementers and operators of systems using these techniques for such purpose MUST NOT describe these schemes as "ENUM". The initial "E" in ENUM stands for E.164, and the term "ENUM" is used exclusively to describe application of these techniques to E.164 numbers according to this specification.
最後に、これらの手法がプランまたは他の数字文字列のダイヤルに使用されている場合、これらの手法を使用してこれらの技術を使用してこれらのスキームを「列挙」として説明してはなりません。Enumの最初の「E」はE.164の略で、「Enum」という用語は、この仕様に従ってこれらの手法をE.164数に適用するためにのみ使用されます。
This template defines the ENUM DDDS Application according to the rules and requirements found in [RFC3402]. The DDDS database used by this Application is found in [RFC3403], which is the document that defines the NAPTR DNS resource record type.
このテンプレートは、[RFC3402]で見つかったルールと要件に従って列挙DDDSアプリケーションを定義します。このアプリケーションで使用されるDDDSデータベースは、[RFC3403]にあります。これは、NAPTR DNSリソースレコードタイプを定義するドキュメントです。
ENUM is designed as a way to translate from E.164 numbers to URIs using NAPTR records stored in DNS. The First Well Known Rule for any ENUM query creates a key (a fully qualified domain name, or FQDN, within the e164.arpa domain apex) from an E.164 number. This FQDN is queried for NAPTR records and returned records are processed and interpreted according to this specification.
Enumは、DNSに保存されているNAPTRレコードを使用して、E.164の数値からURIに翻訳する方法として設計されています。Enum Queryの最初のよく知られているルールは、E.164番号からキー（E164.ARPAドメインAPEX内の完全に適格なドメイン名、またはFQDN）を作成します。このFQDNはNAPTRレコード用にクエリされ、返されたレコードはこの仕様に従って処理および解釈されます。
The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters except for the '+' character that appears at the beginning of the number. The '+' is kept to provide a well-understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.
アプリケーションユニークな文字列（AUS）は、数字の先頭に表示される「文字」を除き、完全に資格のあるE.164番号を差し引いて非桁の文字を差し引いています。''は、e.164ネームスペースの一部ではない他の電話番号と区別するために、AUSの十分に理解されたアンカーを提供するために保持されています。
For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non-digits except for '+' are removed, yielding "+441164960348".
たとえば、E.164数は「44-116-496-0348」として開始できます。構文砂糖がAUSに許可されないようにするために、「 '」を除くすべての非桁が除去され、「441164960348」が得られます。
The First Well Known Rule converts an AUS into an initial key. That key is used as an index into the Application's Rules Database. For ENUM, the Rules Database is the DNS, so the key is a fully qualified domain name (FQDN).
最初によく知られているルールは、AUを初期キーに変換します。そのキーは、アプリケーションのルールデータベースへのインデックスとして使用されます。列挙の場合、ルールデータベースはDNSであるため、キーは完全に適格なドメイン名（FQDN）です。
In order to convert the AUS to a unique key in this database, the string is converted into a domain name according to this algorithm:
このデータベースのAUSを一意のキーに変換するために、このアルゴリズムに従って文字列がドメイン名に変換されます。
1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148" (which would then have been converted into an AUS of "+442079460148"), this step would simply remove the leading '+', producing "442079460148". 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots ('.') between each digit. Example: "8.4.1.0.6.4.9.7.0.2.4.4" 4. Append the string ".e164.arpa." to the end and interpret as a domain name. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
1. 数字を除き、すべての文字を削除します。たとえば、E.164番号「44-20-7946-0148 "（その後、「442079460148」のAUSに変換されます）を考えると、このステップは単に「442079460148」を生成する主要な「」を削除します。2.数字の順序を逆にします。例： "841064970244" 3.各数字の間にドット（ '。'）を置きます。例：「8.4.1.0.6.4.4.9.7.0.2.4.4」4。文字列「E164.ARPA」を追加します。」最後まで、ドメイン名として解釈します。例：8.4.1.0.6.4.4.9.7.0.2.4.4.E164.ARPA。
The E.164 namespace and this Application's database are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself, so no further processing is required to generate the initial key.
E.164名空間とこのアプリケーションのデータベースは、名前自体から直接名前から名前空間の最小の粒度に直接移動できるように整理されているため、初期キーを生成するためにさらに処理する必要はありません。
This domain name is used to request NAPTR records. Each of these records may contain the end result or, if its flags field is empty, produces a new key in the form of a domain name that is used to request further NAPTR records from the DNS.
このドメイン名は、NAPTRレコードを要求するために使用されます。これらの各レコードには、最終結果が含まれている場合があります。フラグフィールドが空の場合、DNSからさらにNAPTRレコードを要求するために使用されるドメイン名の形で新しいキーを生成します。
The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the <absolute-URI> production in the Collected ABNF found in [RFC3986].
最後のDDDSループの出力は、[RFC3986]で見つかった収集されたABNFの<Absolute-uri>生成に従って、その絶対形式の均一なリソース識別子です。
At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite Rules. The keys for this database are encoded as domain names.
現在、このアプリケーションに指定されているDDDSデータベースは1つだけです。「動的委任発見システム（DDDS）パート3：DNSデータベース」[RFC3403]は、NAPTR DNSリソースレコードを使用して書き直しルールを含めるDDDSデータベースを指定します。このデータベースのキーは、ドメイン名としてエンコードされています。
The character set used for the substitution expression is UTF-8 [RFC3629]. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a key are those that are currently defined for DNS domain names.
置換式に使用される文字セットは、UTF-8 [RFC3629]です。許可された入力文字は、E.164番号のどこでも許可されているすべての文字です。キーに入れることが許可されている文字は、現在DNSドメイン名で定義されている文字です。
Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information.
一部の名前サーバーの実装は、特定のDNS応答の追加情報セクションに挿入されたアイテムについてインテリジェントになろうとします。たとえば、Bindは、パケットに1つをエンコードするたびに、ドメインに対して権威あるかどうかを判断しようとします。もしそうなら、パケットが許容される最大長に達するまで、そのドメインに対して見つけたレコードを答えの追加情報セクションに挿入します。したがって、クライアントがこの追加情報を確認することは潜在的に役立ちます。
It is also easy to contemplate an ENUM enhanced nameserver that understands the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret flag values and use that information to include appropriate resource records in the additional information section of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See Section 4.2 of [RFC3403] ("Additional Information Processing") for more information on NAPTR records and the additional information section of a DNS response packet.
また、提供されているNAPTRレコードの実際の内容を理解し、応答の追加情報セクションにより適切な情報を挿入するEnum Enhanced NameServerを熟考することも簡単です。したがって、DNSサーバーはフラグ値を解釈し、その情報を使用して、DNSパケットの追加情報セクションに適切なリソースレコードを含めることができます。クライアントは追加情報を確認することをお勧めしますが、そうする必要はありません。NAPTRレコードとDNS応答パケットの追加情報セクションの詳細については、[RFC3403]（「追加情報処理」）のセクション4.2を参照してください。
This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [RFC3986]. See Section 4.3 of [RFC3404].
このデータベースには、DDDSアルゴリズムが終了したときに信号を送信するフラグを含むフィールドが含まれています。現時点では、「u」というフラグが1つだけです。これは、このルールが最後のルールであり、ルールの出力がURI [RFC3986]であることを意味します。[RFC3404]のセクション4.3を参照してください。
If a client encounters a resource record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.
クライアントが不明なフラグを使用してリソースレコードに遭遇した場合、それを無視して次のルールに移動する必要があります。フラグはフィールドに置かれた解釈を制御できるため、このテストは任意の順序よりも優先されます。
A novel flag might change the interpretation of the Regexp and/or Replacement fields such that it is impossible to determine if a resource record matched a given target.
新しいフラグは、リソースレコードが特定のターゲットと一致するかどうかを判断することが不可能になるように、正規表現および/または交換場の解釈を変更する可能性があります。
If this flag is not present, then this Rule is non-terminal. If a Rule is non-terminal, then the result produced by this rewrite Rule MUST be an FQDN. Clients MUST use this result as the new Key in the DDDS loop (i.e., the client will query for NAPTR resource records at this FQDN).
このフラグが存在しない場合、このルールは非末端です。ルールが非末端である場合、この書き換えルールによって生成された結果はFQDNでなければなりません。クライアントは、この結果をDDDSループの新しいキーとして使用する必要があります（つまり、クライアントはこのFQDNでNAPTRリソースレコードをクエリします）。
Service Parameters for this Application take the following Augmented Backus-Naur Form (ABNF, specified in [RFC5234]) and are found in the Services field of the NAPTR record that holds a terminal Rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content.
このアプリケーションのサービスパラメータは、以下の拡張されたバックナウル形式（ABNF、[RFC5234]で指定）を取り、端末ルールを保持するNAPTRレコードのサービスフィールドにあります。NAPTRが非ターミナルルールを保持している場合、サービスフィールドは空になり、クライアントはコンテンツを無視する必要があります。
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT / "-")
subtype = 1*32(ALPHA / DIGIT / "-")
In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) is followed by one or more Enumservices that indicate the class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.
言い換えれば、非オプションの「E2U」（記録衝突を緩和するために列挙のみを表現するためにルールを書き直すために使用されるために使用）に続いて、特定のエンドポイントが提供する機能のクラスを示す1つ以上のエンスムサービスが続きます。各Enumserviceは、最初の「文字」で示されます。
Enumservices may be specified and registered via the process defined in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]. This registration process is not open to any Enumservice that has '-' as the second character in its type string.
Enumservicesは、「EnumservicesのIANA登録：ガイド、テンプレート、およびIANAの考慮事項」で定義されたプロセスを介して指定および登録できます[RFC6117]。この登録プロセスは、タイプの文字列の2番目の文字として「 - 」を持つEnumserviceには開かれていません。
In particular, this registration process is not open to Enumservice types starting with the facet "X-". This "X-" facet is reserved for experimental or trial use, and any such Enumservices cannot be registered using the normal process.
特に、この登録プロセスは、ファセット「X-」から始まるEnumserviceタイプに対して開かれていません。この「X-」ファセットは、実験または試行用の使用のために予約されており、そのようなエンスムサービスは通常のプロセスを使用して登録することはできません。
Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered.
最後に、ファセット「P-」から始まるエンマムサービスタイプは、プライベートネットワークでのみ使用することを目的としています。そのため、「P-」を開始するEnumserviceタイプを含むNAPTRは、グローバルインターネットでは見られないはずです。EnumクライアントがEnumserviceを認識して関与できる場合でも、含まれるNAPTRによって生成されたURIを解決できない場合があります。これらのEnumservicesは登録されません。
Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets (RRSets) from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.
このようなEnumservicesは、これらのEnamservicesが使用することを目的としているプライベートネットワークコンテキストの外側のエンティティからのNAPTRリソースレコードセット（RRSET）のDNSクエリへの回答を提供するシステムにプロビジョニングしてはなりません。Enumクライアントが、これらのNAPTRがプロビジョニングおよび意図されているプライベートネットワークに接続されていると確信していない限り、「P-」ファセットで始まるEnumserviceタイプでNAPTRを破棄する必要があります。
It is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. The Services field in that case would be "E2U+voice:tel+sms:tel".
単一のNAPTRに関連付けられている複数のEnumserviceを持つことができます。これらのEnumservicesは同じregexpフィールドを共有するため、同じURIを生成します。このような「化合物」NAPTRは、「Voice：Tel」と「SMS：Tel」Enamservicesの両方をサポートする携帯電話を示すために使用できます。その場合のサービスフィールドは、「E2U Voice：Tel SMS：Tel」です。
A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. A left-to-right priority is assumed.
化合物NAPTRは、それぞれが単一のencresviceを保持するNAPTRのセットとして扱うことができます。これらの再構築されたNAPTRSは、同じ順序と優先度/優先度のフィールド値を共有しますが、それぞれが論理的に異なる優先度を持っているかのように扱う必要があります。左から右への優先度が想定されています。
The ENUM algorithm always returns a single Rule. Individual applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm.
Enumアルゴリズムは常に単一のルールを返します。個々のアプリケーションには、複数の結果または速度選択を提示できるアプリケーション固有の知識または施設がある場合がありますが、これらはアルゴリズムの動作を変更することはありません。
Case sensitivity was not mentioned at all in [RFC3761] (or [RFC2916]), but has been seen as an issue during interoperability test events since then. There are a lot of case-sensitive clients in current deployment.
症例感度は[RFC3761]（または[RFC2916]）ではまったく言及されていませんが、それ以来相互運用性テストイベント中に問題と見なされています。現在の展開には、多くのケースに敏感なクライアントがいます。
The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field (see Section 3.2 of [RFC3402] for Regexp field definitions). In that sub-field, case must be preserved when generating the record output. Elsewhere, case sensitivity is not used.
NAPTRフィールドコンテンツがケースに敏感である唯一の場所は、Regexpフィールドの定義については[RFC3402]のセクション3.2を参照）。そのサブフィールドでは、レコード出力を生成するときにケースを保存する必要があります。他の場所では、ケースの感度は使用されません。
Where ENUM clients can be exposed to NAPTR records that may hold field content of different capitalization, clients MUST use case-insensitive processing. ENUM clients that operate using the Internet to send their queries, typically called "Public ENUM" scenarios, fall into this category.
列挙クライアントを異なる資本化のフィールドコンテンツを保持する可能性のあるNAPTRレコードに公開できる場合、クライアントはケース非感受性処理を使用する必要があります。インターネットを使用して動作する列挙クライアントは、通常は「パブリックエインム」シナリオと呼ばれるクエリを送信し、このカテゴリに分類されます。
Some ENUM clients operate within closed networks; for example, within isolated data networks operated by Communication Service Providers. These are typically called "Infrastructure ENUM" scenarios. All zones provisioned within such closed networks usually have a known capitalization for ENUM record string content, as provisioning systems for such networks are often carefully controlled. In such an environment, clients are never exposed to records with capitalization that is "unexpected" and so can be (and have been) designed with case sensitive processing. Only if a client is known to operate in an environment in which capitalization of all ENUM records it will encounter is known and controlled MAY that client use case sensitive processing.
一部の列挙クライアントは、閉じたネットワーク内で動作します。たとえば、通信サービスプロバイダーが運営する孤立したデータネットワーク内。これらは通常、「インフラストラクチャ列挙」シナリオと呼ばれます。このような閉じたネットワーク内でプロビジョニングされたすべてのゾーンは、通常、そのようなネットワークのプロビジョニングシステムが慎重に制御されるため、列挙記録のコンテンツの既知の資本化を持っています。このような環境では、クライアントは「予期しない」資本化の記録にさらされることはありません。そのため、ケースに敏感な処理で設計されています（そして、設計されています）。クライアントが遭遇するすべてのenumレコードの大文字化が既知で制御される環境で動作することがわかっている場合にのみ、クライアントがケースに敏感な処理を使用する可能性があります。
An ENUM-compliant application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g., it MUST NOT pass dialed digit strings to the ENUM query process).
Enumに準拠したアプリケーションは、E.164番号であると考えられるEnumクライアントクエリプロセスに番号のみを渡す必要があります（たとえば、ダイヤルされた数字文字列を列挙クエリプロセスに渡さないでください）。
Since number plans may change over time, it can be impossible for a client to know if the number it intends to query is assigned and active within the current number plan. Thus it is important that such clients can distinguish data associated with the E.164 number plan from that associated with other digit strings (i.e., numbers NOT in accordance with the E.164 number plan).
数値計画は時間とともに変化する可能性があるため、クライアントがクエリする意図した番号が現在の数値計画内で割り当てられ、アクティブであるかどうかをクライアントが知ることは不可能です。したがって、このようなクライアントは、E.164番号計画に関連付けられたデータと他の桁の文字列に関連するデータを区別できることが重要です（つまり、E.164番号計画に従っていない番号）。
It is the responsibility of operators that are provisioning data into domains to ensure that data associated with a query on an E.164 number cannot be mistaken for data associated with other uses of NAPTRs.
E.164番号のクエリに関連するデータがNAPTRの他の使用に関連するデータと間違えられないことを保証するために、ドメインにデータをプロビジョニングしているのはオペレーターの責任です。
Three techniques are used to achieve this:
これを達成するために3つの手法が使用されます。
o the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be e164.arpa.
o E.164番号計画に関連付けられたデータ以外の目的に使用されるドメイン頂点は、E164.ARPAであってはなりません。
o for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character.
o e.164番号以外に使用するには、アプリケーションの一意の文字列は「文字」から始めるべきではありませんが、列挙の使用の場合、AUSはこのキャラクターで開始する必要があります。
o NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token.
o 他のDDDSアプリケーションを対象としたNAPTRSは、サービスフィールドにE2Uトークンを含めてはなりませんが、列挙用に使用するNAPTRSはこのトークンを含める必要があります。
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . NAPTR 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . NAPTR 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
$ origin 3.8.0.0.6.9.2.3.6.1.4.4.E164.ARPA。naptr 100 50 "u" "e2u sip" "！^（\\ 441632960083）$！sip：\\ 1@example.com！"。Naptr 100 51 "U" "E2U H323" "！^\\ 441632960083 $！H323：operator@example.com！"。Naptr 100 52 "U" "e2uメール：mailto" "！^。*$！mailto：info@example.com！"。
This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the Enumservice tokens "sip", "h323", and "email" are Enumservice Types registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names.
これは、ドメイン3.8.0.0.6.9.2.3.6.1.4.4.E164.ARPAであることを説明しています。SIPによって、2番目にH.323を介して音声を介して、3番目はメッセージングのSMTPによって連絡することが望ましい。Enumserviceトークン「SIP」、「H323」、および「電子メール」は、IANAに登録されているEnumserviceタイプであり、同じ名前のプロトコルまたはURIスキームとの暗黙の接続がないことに注意してください。
In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols (specified by the URI schemes sip, h323, and mailto) to know what node to contact.
すべての場合において、解決プロセスの次のステップは、各プロトコル（URIスキームSIP、H323、およびMailToで指定）の解像度メカニズムを使用して、接触するノードを知ることです。
In each of the first two records, the ERE sub-field matches only queries that have been made for the telephone number +441632960083. In the last record, the ERE matches any Application Unique String value. The first record also demonstrates how the matched pattern can be used in the generated URI.
最初の2つのレコードのそれぞれで、EREサブフィールドは、電話番号441632960083に対して作成されたクエリのみを一致させます。最後のレコードでは、EREはアプリケーションの一意の文字列値と一致します。また、最初のレコードは、生成されたURIで一致したパターンをどのように使用できるかを示しています。
Note that where NAPTR resource records are shown in DNS master file syntax (as in this example above), each backslash must itself be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash in each case.
NAPTRリソースレコードがDNSマスターファイルの構文（上記の例のように）に表示されている場合、各バックスラッシュ自体が2番目のバックスラッシュを使用して逃げる必要があることに注意してください。DNSオンザワイヤパケットは、それぞれの場合に単一のバックスラッシュしかありません。
ENUM is a DDDS Application. This means that it relies on the DDDS for its operation. DDDS is designed to be flexible, but that opens the possibility of differences of interpretation. This section is intended to cover ENUM-specific interpretation of text within the DDDS specifications. The goal is to ensure interoperability between ENUM clients and provisioning systems used to populate domains with E2U NAPTRs.
EnumはDDDSアプリケーションです。これは、操作のためにDDDに依存していることを意味します。DDDSは柔軟になるように設計されていますが、解釈の違いの可能性が開かれます。このセクションは、DDDS仕様内のテキストの列挙固有の解釈をカバーすることを目的としています。目標は、ENUMクライアントとE2U NAPTRSにドメインを入力するために使用されるプロビジョニングシステム間の相互運用性を確保することです。
As part of on-going development work on the ENUM specifications, [RFC5483] provides an (informative) analysis of the way in which ENUM client and provisioning system implementations behave and the interoperability issues that have arisen. The following recommendations reflect that analysis, and further narrative explaining the issues can be found in that RFC.
列挙仕様に関する継続的な開発作業の一環として、[RFC5483]は、列挙クライアントとプロビジョニングシステムの実装がどのように動作するか、および発生した相互運用性の問題をどのようにして（有益な）分析を提供します。次の推奨事項は、その分析を反映しており、問題を説明するさらなる物語はそのRFCにあります。
ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly. If ENUM zone provisioning systems require non-ASCII characters, these systems MUST encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism (such as those in [RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.
Enum Naptrsは、印刷可能なUS-ASCII同等の範囲（U 0020からU 007E）の外側の文字を含めるべきではありません。Enum Zone Provisioningシステムに非ASCII文字が必要な場合、これらのシステムは、適切なメカニズム（[RFC3492]、[RFC3987]など）を適用することにより、非ASCIIデータのみをEMIT US-ASCII文字のみにエンコードする必要があります。Enumクライアントは、人間が読み取る形式でNAPTRコンテンツを提示する必要がある場合があるため、印刷できない文字を使用しないでください。
The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs.
症例感度フラグ（ 'i'）は列挙には不適切であり、E2U NaptrsのRegexpフィールドにプロビジョニングするべきではありません。
The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.
登録者および列挙ゾーンプロビジョニングシステムは、enum naptrsの注文の価値と優先/優先フィールドのみを考慮して、列挙クライアントに依存してはいけません。したがって、登録者は自分のゾーンにのみゾーンのみを配置する必要があります。最悪の順序と好み/優先度の値を持つ人でさえ、エンドユーザーが選択することができます。
All E2U NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, as it seems to be used in most provisioned domains.
すべてのE2U NAPTRSは、注文フィールドにデフォルト値を保持する必要があります。ほとんどのプロビジョニングドメインで使用されているように見えるため、「100」の値が推奨されます。
Some ENUM clients have been known to pre-discard NAPTRs within an RRSet simply because these records do not have the lowest ORDER value found in that RRSet. Other ENUM client implementations appear to have confused ORDER and PREFERENCE/PRIORITY fields, using the latter as the major sort term rather than the former as specified. Conversely, ENUM zones have been provisioned within which the ORDER value varies but the PREFERENCE/PRIORITY field value is static. This may have been intentional, but given the different client behavior in the face of varying ORDER field values, it may not produce the desired response.
一部の列挙クライアントは、これらのレコードがそのRRSetで見つかった最低の注文値を持っていないという理由だけで、RRSet内でNAPTRを事前にディスカードすることが知られています。他の列挙クライアントの実装は、指定された前者ではなく、主要なソート用語として後者を使用して、順序と優先順位/優先度フィールドを混乱させたようです。逆に、列挙ゾーンはプロビジョニングされており、順序値は変化しますが、優先順位/優先フィールド値は静的です。これは意図的なものである可能性がありますが、順序フィールド値が変化する場合に異なるクライアントの動作を考えると、望ましい応答が生成されない場合があります。
Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.
同一の順序と同一の優先順位/優先度フィールド値を持つ複数のNAPTRは、これらのNAPTRが本当に同一であり、それらの間に優先度がないという意図がない限り、RRSetにプロビジョニングされるべきではありません。実装者は、DNSが特定のシーケンスでRRSET内のNAPTRSを配信すると仮定してはなりません。
An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left-to-right order within such NAPTRs.
enumゾーンプロビジョニングシステムは、複合Naptrsを生成する場合、エンスムサービスは通常、そのようなNaptr内で左から右への順序で処理されると想定する必要があります。
ENUM zone provisioning systems SHOULD assume that, once a non-terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet).
列挙ゾーンプロビジョニングシステムは、処理のために非末端NAPTRが選択されると、その非末端NAPTRによって言及されるドメインの順序フィールド値は、その参照ドメインのコンテキスト内でのみ見なされると想定する必要があります（すなわち、、注文値は、現在のRRSet内での並べ替えにのみ使用され、他のRRSetのNAPTRの処理には使用されません）。
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character.
Enum Zone Provisioningシステムは「！」を使用する必要があります。（U 0021）regexpデリミッター文字として。
If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
RegexpデリミッターがREPLサブフィールドの静的テキストの文字である場合、[RFC3402]のセクション3.2に示されているBNF仕様の脱出型削除生産を使用して「脱出」する必要があります（つまり、「\！」、U 005C U 0021）。NAPTRリソースレコードがDNSマスターファイルの構文に入力されている場合、2番目のバックスラッシュを使用してバックスラッシュ自体を逃れる必要があることに注意してください。
If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
Enum naptrのeREサブフィールドに存在する場合、リテラルキャラクター「\」（つまり、u 005c u 002b）として逃げる必要があります。いつものように、DNSマスターファイルの構文にNAPTRリソースレコードが入力されている場合、2回目のバックスラッシュを使用してバックスラッシュ自体を脱出する必要があることに注意してください。
Whilst this client behavior is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been detected with poor (or no) support for non-trivial ERE sub-field expressions.
このクライアントの動作は非準拠ですが、列挙プロビジョニングシステムとそのユーザーは、一部の列挙クライアントが、自明でないeREサブフィールド式のサポートが不十分であることを検出していることに注意する必要があります。
ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs. These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs.
列挙プロビジョニングシステムは、提供するNAPTRSのREPLサブフィールドで複数の背面参照パターンを使用する際に慎重にする必要があります。一部のクライアントは、URIを生成するときに文字拡張のためのバッファスペースが限られています。これらのプロビジョニングシステムは、使用している後方参照置換パターンをチェックし、正規表現処理が過度の長さのURIを生成しないようにする必要があります。
ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in which the Services field is according to Section 3.4.3 of this document.
[RFC2916]の時代遅れの構文に従って、列挙ゾーンをNAPTRSでプロビジョニングする必要はなく、このドキュメントのセクション3.4.3に従ってサービスフィールドがあるNAPTRでプロビジョニングする必要があります。
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404] and by this document, respectively.
[RFC2915]および[RFC2916]は、それぞれ[RFC3401] - [RFC3404]およびこの文書によって廃止されています。
Enumservices in which the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use.
Enumservice型がファセットで始まるEnumservices "p-"は、これらのencrervicesが使用することを目的としているプライベートネットワークコンテキストの外側からのエンティティからのNAPTRリソースレコードセットのDNSクエリへの回答を提供するシステムにプロビジョニングしてはなりません。
As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these.
現在のサポートが限られているため、非末端NAPTRは、この環境がサポートしているすべての列挙クライアントがこれらを処理できることが明らかでない限り、列挙ゾーンにプロビジョニングされるべきではありません。
When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query.
ドメインのセットにNAPTRSを入力する場合、Enum Zone Provisioning Systemsは非末端NAPTRを構成しないようにして、5つ以上のそのようなNAPTRが列挙クエリで処理されるようにします。
In a non-terminal NAPTR that may be encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.
列挙クエリ（つまり、空のフラグフィールドを持つもの）で遭遇する可能性のある非末端NAPTRでは、サービスフィールドは空にする必要があります。
A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field, as this field will be interpreted as holding the FQDN that forms the next key output from this non-terminal Rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.
このフィールドは、この非末端ルールから次のキー出力を形成するFQDNを保持していると解釈されるため、非末端NAPTRには（空の非）置換フィールドにターゲットドメインを含める必要があります。Regexpフィールドは、列挙クエリ中に遭遇することを目的とした非末端NAPTRで空でなければなりません。
If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned RRSet.
NAPTRが破棄された場合、これにより、列挙クエリ全体が終了し、処理が返されたRRSETの次のNAPTRで処理されるべきではありません。
ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).
列挙クライアントは、US-ASCIIの印刷可能な範囲外の文字（0x20〜0x7eヘキサデシマル）の外側の文字を検出するNaptrを破棄すべきではありません。
ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F). Clients MUST be ready to encounter NAPTRs with such values without failure.
列挙クライアントは、フラグ、サービス、または米国ASCII同等の範囲外（つまり、0x7Fを超えるバイト値）の外側にバイト値を持つReGEXPフィールドにオクテットを持つNAPTRを破棄できます。クライアントは、失敗することなく、そのような価値でNAPTRに遭遇する準備ができている必要があります。
ENUM clients MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records. The ORDER is to be treated as the major sort term, with lowest numerical values being earlier in the sequence. The PREFERENCE/PRIORITY field is to be treated as the minor sort term, with lowest numerical values being earlier in the sequence.
Enumクライアントは、これらのレコードの順序と設定フィールドを使用して、取得したNAPTR RRSTのレコードをシーケンスに並べ替える必要があります。順序は主要な並べ替え用語として扱われ、最低数値値はシーケンスの早い段階です。優先度/優先度フィールドは、マイナーソート用語として扱われ、最低数値値はシーケンスの早い段階です。
ENUM clients SHOULD NOT discard a NAPTR record until it is considered or a record previous to it in the evaluation sequence has been accepted.
Enumクライアントは、NAPTRレコードが考慮されるまでNAPTRレコードを破棄したり、評価シーケンスでその前のレコードを受け入れたりする必要があります。
Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query.
特に、レコードがこのRRSetの他の人よりも「悪い」注文値を持っている場合、この列挙クエリの結果としてレコードが受け入れられない限り、そのレコードは考慮前に破棄する必要はありません。
Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the lowest currently unprocessed ORDER field value. The client SHOULD observe the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.
Enumクライアントが、選択のために可能なURLのリストをエンドユーザーに提示する場合、すべてのNaptrを提示する場合があります - 現在最低の未処理の注文フィールド値を持つものだけでなく。クライアントは、登録者によって指定された順序と優先度/優先度の値を遵守する必要があります。
ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response. (There is no benefit in further randomizing the order in which these are processed, as intervening DNS Servers might have done this already).
Enumクライアントは、すべてのNAPTRを同一の順序と同一の優先順位/優先フィールド値で受け入れ、DNS応答に表示されるシーケンスでそれらを処理する必要があります。（介在するDNSサーバーがすでにこれを行っている可能性があるため、これらが処理される順序をさらにランダム化することに利点はありません）。
ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references.
Enumクライアントは、単一のRRSet内でNAPTRをソートする場合にのみ、注文フィールド値を考慮する必要があります。非末端NAPTR参照のトラバーサルによって作成されたDNSクエリのシーケンスにわたってNAPTRを処理する場合、順序フィールド値を考慮すべきではありません。
ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one.
化合物NAPTRを受け取っているクライアント（つまり、複数のEnumserviceを備えたクライアント）は、左から右へのソート順序を使用してこれらのエンスムサービスを処理する必要があります。1。
ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.
enumクライアントは、「！」とは異なる文字を使用するNAPTRを処理する準備ができている必要があります。故障せずにregexpデリミッターとして。
ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.
列挙クライアントは、区切り文字がregexpフィールドの最後の文字であると想定してはなりません。
Unless they are sure that in their environment this is the case, in general an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario.
彼らが彼らの環境でこれが事実であると確信していない限り、一般に、列挙クライアントは、次の「I」（ケース非感受性）フラグでプロビジョニングされたNAPTRに遭遇する可能性がありますが、そのフラグはまったく効果がありませんが列挙シナリオ。
ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.
列挙クライアントは、regexpフィールド内の区切り文字の3つの無効なインスタンスが多いか少ないNAPTRを破棄する必要があります。
In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, it MAY choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters. If it is not clear how the Regexp field should be interpreted, the client MUST discard the NAPTR.
列挙クライアントがregexpフィールドをどのように解釈するかを確信している場合、それが受け入れるものにリベラルであるという精神で、誤った数の非脱型のデリミタ文字に直面してもNAPTRを処理することを選択するかもしれません。regexpフィールドをどのように解釈すべきかが明らかでない場合、クライアントはNAPTRを破棄する必要があります。
ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.
Enumクライアントは、誤解せずにサブフィールド値に自明でないパターンを持つNAPTRを処理する準備ができている必要があります。
ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure.
Enumクライアントは、故障せずにREPLサブフィールド内のバックリファレンスパターンの多くのコピーを使用してNAPTRを処理する準備ができている必要があります。
ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.
Enumクライアントは、障害なしに「E2U」以外のDDDSアプリケーション識別子でNAPTRを処理する準備ができている必要があります。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognize one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.
列挙クライアントが化合物NAPTR（つまり、複数のEnumserviceを含むもの）に遭遇し、その中のencervicesの1つを処理できないか、または認識できない場合、Enumクライアントはこのencresviceを無視し、このNAPTRのサービスフィールド内の次のenyserviceを継続する必要があります。NAPTRを廃棄して、含まれるEnumservicesのいずれかを処理できない場合にのみ。これらの条件はエラーと見なされるべきではありません。
ENUM clients MUST support ENUM NAPTRs according to syntax defined in Section 3.4.3. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs. The informational [RFC3824] recommended such support.
Enumクライアントは、セクション3.4.3で定義されている構文に従ってenum naptrsをサポートする必要があります。列挙クライアントは、[RFC2916]の時代遅れの構文に従ってenum naptrsをサポートする必要があります。「古い」構文naptrsを保持するゾーンがまだあります。情報[RFC3824]はそのようなサポートを推奨しました。
Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.
Enumクライアントが、これらのNAPTRがプロビジョニングおよび意図されているプライベートネットワークに接続されていると確信していない限り、「P-」ファセットで始まるEnumserviceタイプでNAPTRを破棄する必要があります。
ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure. More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter.
Enumクライアントは、空のフラグフィールド（「非末端」NAPTRS）を使用してNAPTRSを障害なく処理する準備ができている必要があります。より一般的には、非末端NAPTR処理を実装する必要がありますが、列挙クライアントは遭遇する非末端NAPTRを破棄する場合があります。
ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.
Enumクライアントは、空のフラグフィールドで非末端NAPTRに遭遇したときに、サービスフィールドのコンテンツを無視する必要があります。
ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the FQDN to be used in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid FQDN. By definition, it follows that the Regexp field will be empty in such a non-terminal NAPTR. If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients.
空のフラグフィールドを使用して非末端NAPTRを受信する列挙クライアントは、列挙クエリの次のラウンドで使用されるFQDNを保持するものとして交換フィールドを扱う必要があります。列挙クライアントは、交換場が空であるか、有効なFQDNが含まれていない場合、そのような非末端NAPTRを破棄する必要があります。定義上、そのような非末端NAPTRでは、regexpフィールドが空になることになります。非末端NAPTRに存在する場合、Enumクライアントは、空でないRegexpフィールドを無視する必要があります。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.
複数のドメインにわたって列挙クエリを処理するときに問題が検出された場合（非末端NAPTR参照に従うことにより）、列挙クエリは放棄されるべきではありませんが、代わりに処理は次のNAPTRで次のNAPTRで続行する必要があります。問題が発生したドメイン。
If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal).
非末端NAPTRの参照の結果として通過したドメイン内のすべてのNAPTRが破棄された場合、列挙クライアントは「参照」rrset（つまり、非末端を含む次のNAPTRで処理を継続する必要がありますトラバーサルを引き起こしたnaptr）。
ENUM clients MUST be prepared to encounter a referential loop in which a sequence of non-terminal NAPTRs are retrieved within an ENUM query that refer back to an earlier FQDN. ENUM clients MUST be able to detect and recover from such a loop, without failure.
列挙クライアントは、以前のFQDNを参照する列挙クエリ内で一連の非末端NAPTRSが取得される参照ループに遭遇するように準備する必要があります。Enumクライアントは、失敗することなく、そのようなループから検出して回復できる必要があります。
ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered.
列挙クライアントは、参照ループが入力されたことを示すものとして、単一の列挙クエリで横断された5つの「非末端」NAPTRSのチェーンを考慮することができます。
When a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR.
非末端NAPTRの参照の結果としてドメインを入力しようとしている場合、列挙クライアントが潜在的な参照ループを検出した場合、クライアントは非末端NAPTRを処理から廃棄し、次のNAPTRを続行する必要がありますそのリストに。その非末端NAPTRで示されるDNSクエリを作成しないでください。
RFC 2916 and then RFC 3761 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions that were provided by the IAB (as described in [RFC3245]). The domain was delegated according to those instructions (which are published at <http://www.ripe.net/data-tools/dns/enum/iab-instructions>).
RFC 2916、そしてRFC 3761（このドキュメントが置き換える）は、IABによって提供された命令に従って、e164.ARPAドメインを委任するようにIANAに要求しました（[RFC3245]で説明されています）。ドメインは、これらの指示に従って委任されました（<http://www.ripe.net/data-tools/dns/enum/iab-instructions>で公開されています）。
Names within this zone are to be delegated to parties consistent with ITU Recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.
このゾーン内の名前は、ITUの推奨事項E.164と一致する当事者に委任されます。割り当てられた名前は、ITUの推奨事項E.164に従って階層的である必要があり、コードはその推奨に従って割り当てる必要があります。
The IAB is to coordinate with the ITU Telecommunications Standardization Bureau (TSB) if the technical contact for the domain e164.arpa is to change, as ITU TSB has an operational working relationship with this technical contact that would need to be reestablished.
IABは、ITU TSBが再確立する必要があるこの技術的接触と運用上の作業関係を持っているため、ドメインE164.ARPAの技術的な連絡先が変更されるため、ITU Telecommunications Standardization Bureau（TSB）と調整することです。
See [RFC6117] for Enumservice-related IANA Considerations.
Enumservice関連のIANAの考慮事項については、[RFC6117]を参照してください。
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kinds of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.
EnumはDNSを使用しているため、現在の形式では不安定なプロトコルであるため、データが戻ってくるデータが本物であることを保証するメカニズムはありません。列挙はグローバルなインターネットに展開されるため、さまざまな種類の攻撃の一般的なターゲットになると予想され、基礎となるDNSインフラストラクチャを攻撃することは、Enumサービス自体を攻撃する1つの方法です。
There are multiple types of attacks that can happen against DNS that ENUM implementations should consider. See Threat Analysis of the Domain Name System [RFC3833] for a review of the various threats to the DNS.
列挙の実装を考慮すべきDNSに対して発生する可能性のある攻撃には、複数のタイプがあります。DNSに対するさまざまな脅威のレビューについては、ドメイン名システム[RFC3833]の脅威分析を参照してください。
Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate these threats. Most of the threats can be solved by verifying the authenticity of the data via mechanisms such as DNS Security (DNSSEC) [RFC4033].
これらの脅威のため、展開された列挙サービスには、これらの脅威を軽減するメカニズムを含める必要があります。ほとんどの脅威は、DNSセキュリティ（DNSSEC）[RFC4033]などのメカニズムを介してデータの信頼性を確認することで解決できます。
Others, such as Denial-Of-Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV, and A records).
サービス拒否攻撃などのその他は、データ認証によって解決することはできません。これらの脅威には、NAPTRルックアップ自体だけでなく、サービスが有用であるために必要なさまざまなレコード（NS、MX、SRV、Aレコードなど）も含まれることを覚えておくことが重要です。
Even if DNSSEC is deployed, it cannot protect against every kind of attack on DNS. ENUM is often used for number or address translation; retrieving an address through an ENUM lookup with DNSSEC support does not, however, ensure that the service is immune to attack. It is unwise for a service blindly to trust that the address it has retrieved is valid and that the entity to which it connects using that address is the service peer it intended to contact. A service SHOULD always authenticate the entity to which it connects during the service setup phase, and not rely on address or identity data retrieved outside that service.
DNSSECが展開されていても、DNSに対するあらゆる種類の攻撃から保護することはできません。列挙は、多くの場合、番号または住所の翻訳に使用されます。ただし、DNSSECサポートを使用した列挙ルックアップを介して住所を取得しても、サービスが攻撃の影響を受けないことを確認しません。サービスが盲目的に、取得したアドレスが有効であり、そのアドレスを使用して接続するエンティティが連絡先を意図したサービスピアであることを盲目的に信頼することは賢明ではありません。サービスは、サービスセットアップフェーズ中に接続するエンティティを常に認証する必要があり、そのサービス外で取得された住所またはIDデータに依存しないでください。
Finally, as an ENUM service will be implementing some type of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses and other EDNS0 signaling (see [RFC2671]), unknown resource records (see [RFC3597]), and so on.
最後に、Enumサービスが何らかのタイプのセキュリティメカニズムを実装するため、列挙を実装するソフトウェアをDNSSECおよびその他の標準化されたDNSセキュリティ応答を受信するために準備する必要があります。[RFC3597]）などを参照してください。
The DNS architecture makes extensive use of caching of records at intermediary nodes to improve performance. The propagation time (for changes to resource records to be reflected in query responses to end nodes) approaches the "time to live" value for those records. There may be a number of different resource records involved in the resolution of a communication target. Changes to these records may not be synchronized (particularly if these resource records indicate different times to live). Thus a change in any one of these records may cause inappropriate decisions on communications targets to be made. Given that DNS Update (specified in [RFC2136]) can introduce quite rapid changes in content in different zones, these transient states may become important.
DNSアーキテクチャは、パフォーマンスを改善するために、中間ノードでのレコードのキャッシュを広範囲に使用しています。伝播時間（エンドノードへのクエリ応答に反映されるリソースレコードの変更の場合）は、それらのレコードの「生きる時間」値に近づきます。通信ターゲットの解決には、さまざまなリソースレコードが含まれる場合があります。これらのレコードの変更は同期されない場合があります（特に、これらのリソースレコードがライブに異なる時間を示している場合）。したがって、これらの記録のいずれかの変更により、通信ターゲットが不適切な決定を下す可能性があります。DNSアップデート（[RFC2136]で指定）が異なるゾーンのコンテンツに非常に急速な変化をもたらす可能性があることを考えると、これらの一時的な状態が重要になる可能性があります。
Consider a typical set of queries that follow an ENUM query that returns a SIP URI (for details, see [RFC3263]):
SIP URIを返す列挙クエリに従う典型的なクエリのセットを考えてみましょう（詳細については、[RFC3263]を参照）：
o Evaluation of the SIP URI triggers a query on the SIP domainpart for D2U/D2T NAPTRs.
o SIP URIの評価は、D2U/D2T NAPTRSのSIPドメインパートのクエリをトリガーします。
o This in turn triggers a query on that record's target domain for SRV records.
o これにより、SRVレコードのレコードのターゲットドメインのクエリがトリガーされます。
o The SRV records will return the SIP server hostname, which will trigger a further query on that hostname for an A record to get the server's associated IP address.
o SRVレコードは、SIPサーバーのホスト名を返します。これにより、サーバーの関連するIPアドレスを取得するためのAレコードのホスト名のさらにクエリがトリガーされます。
o Finally, the local SIP User Agent Client will then attempt to initiate a communications session to that IP address.
o 最後に、ローカルSIPユーザーエージェントクライアントは、そのIPアドレスへの通信セッションを開始しようとします。
The E2U NAPTR may have changed its URI, indicating a new SIP identity. The D2U NAPTR for the SIP URI domainpart may have changed its target. The SRV record pointed to by that D2U NAPTR may have changed its target hostname. The hostname's A record may have changed its IP address. Finally, if the server exists in an environment where IP-addresses are dynamically assigned (for example, when using DHCP [RFC2131]), an unexpected end point may have been allocated to the IP address returned from the SIP resolution chain.
E2U NAPTRはURIを変更し、新しいSIP IDを示している可能性があります。SIP URIドメインパートのD2U Naptrがターゲットを変更した可能性があります。D2U NAPTRが指摘したSRVレコードは、ターゲットホスト名を変更した可能性があります。ホスト名のレコードがIPアドレスを変更した可能性があります。最後に、サーバーがIPアドレスが動的に割り当てられている環境に存在する場合（たとえば、DHCP [RFC2131]を使用する場合）、SIP解像度チェーンから返されたIPアドレスに予期しないエンドポイントが割り当てられた可能性があります。
In environments where changes to any of the chain of resource records or dynamic assignments to IP addresses occur, those systems provisioning this data SHOULD take care to minimize changes and to consider the respective times to live of resource records and/or DHCP lease times. Users of this data SHOULD take care to detect and recover from unintended communications session attempts; in a transient environment, these may occur.
リソースレコードのチェーンまたはIPアドレスへの動的な割り当てのいずれかの変更が発生する環境では、このデータをプロビジョニングするシステムは、変更を最小限に抑え、リソースレコードおよび/またはDHCPリース時間のライブにそれぞれの時間を考慮するように注意する必要があります。このデータのユーザーは、意図しない通信セッションの試みを検出して回復するように注意する必要があります。一時的な環境では、これらが発生する可能性があります。
There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name-translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.
コールルーティングと番号/名前翻訳サービスの複数のプロバイダーがある国（および他の番号付け環境）があります。これらの領域では、ユーザーまたはユーザーの推定エージェントを許可するシステムは、ルーティングまたはサプライヤー情報を変更することを許可します。このような環境は、変更を要求するものを識別し、認証し、それらの変更を許可するための適切なメカニズムで設計する必要があります。
A large amount of security issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the Enumservice used, as specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117].
大量のセキュリティ問題は、解像度プロセス自体、およびDDDSメカニズムによって生成されるURIの使用に関係しています。これらは、「EnumservicesのIANA登録：ガイド、テンプレート、およびIANAの考慮事項」で指定されているように、使用されるEnumserviceの登録で指定する必要があります[RFC6117]。
This document is an update of RFC 3761, which was edited by Patrik Faltstrom and Michael Mealling. Please see the Acknowledgements section in that RFC for additional acknowledgements. The authors would also like to thank Alfred Hoenes and Bernie Hoeneisen for their detailed reviews.
このドキュメントは、Patrik FaltstromとMichael Mearlingによって編集されたRFC 3761の更新です。追加の謝辞については、そのRFCの謝辞セクションをご覧ください。著者はまた、詳細なレビューについてAlfred HoenesとBernie Hoeneisenに感謝したいと思います。
A section has been added to explain the way in which DDDS is used with this specification. These recommendations have been collected from experience of ENUM deployment. Differences of interpretation of the DDDS specifications led to interoperability issues; this document updates RFC 3761 to add many clarifications, intended to ameliorate interoperability.
この仕様でDDDが使用される方法を説明するためにセクションが追加されました。これらの推奨事項は、列挙展開の経験から収集されています。DDDS仕様の解釈の違いにより、相互運用性の問題が発生しました。このドキュメントは、RFC 3761を更新して、相互運用性を改善することを目的とした多くの説明を追加します。
Clarifications include a default value for the ORDER field and for the Regexp delimiter character, required use of Replacement field in non-terminal NAPTRs, and that string matching is case insensitive (Section 3.6).
明確化には、オーダーフィールドとregexpデリミッター文字のデフォルト値が含まれ、非末端NAPTRでの交換場の使用が必要であり、その文字列マッチングは症例鈍感です（セクション3.6）。
Other substantive changes include removing the discussion of registration mechanisms, (now specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]), correcting an existing error by adding "-" as a valid character in the type and subtype fields specified in Services Parameters (Section 3.4.3) and adding the "P-" private service type (Section 3.4.3.1).
その他の実質的な変更には、登録メカニズムの議論の削除（現在は「Enumservices：Guide、Template、およびIANAの考慮事項」で指定されています[RFC6117]）、タイプの有効な文字として「 - 」を追加することで既存のエラーを修正することが含まれます。サービスパラメーター（セクション3.4.3）で指定されたサブタイプフィールドと「P-」プライベートサービスタイプ（セクション3.4.3.1）を追加します。
[E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E.164] ITU-T、「国際公開通信番号計画」、推奨事項E.164、2005年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[RFC3404] Mealling、M。、「動的委任ディスカバリーシステム（DDDS）パート4：ユニフォームリソース識別子（URI）」、RFC 3404、2002年10月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[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月。
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2915] Mealling、M。and R. Daniel、「The Naming Authority Pointer（NAPTR）DNSリソースレコード」、RFC 2915、2000年9月。
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC2916] Faltstrom、P。、「E.164番号とDNS」、RFC 2916、2000年9月。
[RFC3245] Klensin, J., Ed., and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.
[RFC3245] Klensin、J.、ed。、およびIAB、「電話番号マッピング（列挙）運用上の決定の履歴とコンテキスト：ITU-T研究グループ2（SG2）に貢献した情報文書、RFC 3245、2002年3月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824] Peterson、J.、Liu、H.、Yu、J。、およびB. Campbell、「セッション開始プロトコル（SIP）でE.164番号を使用」、RFC 3824、2004年6月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and Experiences", RFC 5483, March 2009.
[RFC5483] Conroy、L。およびK. Fujiwara、「Enumの実装の問題と経験」、RFC 5483、2009年3月。
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" RFC 6117, March 2011.
[RFC6117] Hoeneisen、B.、Mayrhofer、A。、およびJ. Livingood、「EnumservicesのIANA登録：ガイド、テンプレート、およびIANAの考慮事項」RFC 6117、2011年3月。
Authors' Addresses
著者のアドレス
Scott Bradner Harvard University 29 Oxford St. Cambridge MA 02138 USA
スコットブラッドナーハーバード大学29オックスフォードセントケンブリッジMA 02138 USA
Phone: +1-617-495-3864
EMail: sob@harvard.edu
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイロークマナーリサーチロークマナーオールドソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://lawrence.tel
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0165 JAPAN
Kazunori Fujiwara Japan Registry Services Co.、Ltd。Chiyoda First Bldg。イースト13F 3-8-1西カンダチヨーダ - キュー東京101-0165日本
EMail: fujiwara@jprs.co.jp
URI: http://jprs.jp/en/