Network Working Group M. Haberler
Request for Comments: 5527 IPA
Category: Informational O. Lendl
enum.at
R. Stastny
Unaffiliated
May 2009
Combined User and Infrastructure ENUM in the e164.arpa Tree
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution.
このメモは、国家の選択肢としてe164.arpaで組み合わせ、ユーザーとインフラストラクチャENUM実装を可能にするためにインフラストラクチャENUMのための暫定的な解決策を定義します。この暫定的な解決策は、長期的な解決策の実施後に廃止されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Interim Solution ................................................3
4. The Algorithm ...................................................4
5. Determining the Position of the Branch ..........................5
6. Transition to the Long-Term Solution ............................6
7. Examples ........................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms E.164 numbers [E164] into domain names and then queries the DNS (Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer) records [RFC3401] in order to look up which services are available for a specific domain name.
ENUM（E.164番号マッピング、[RFC3761]）はNAPTR（権限ポインタを命名）レコードのドメイン名に[E164] E.164番号を変換、その後、DNS（ドメインネームサービス）を照会システム[RFC1034]、[RFC3401あります]ために、特定のドメイン名のために利用可能なサービスをルックアップします。
ENUM, as defined in RFC 3761 (User ENUM), is not well suited for the purpose of interconnection by carriers and voice-service providers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms.
ENUMは、RFC 3761で定義された（ユーザENUM）として、ENUMメカニズムに基づいて、様々な民間ツリー構成の使用によって見られるように、キャリアおよび音声サービスプロバイダによって相互接続する目的のためには適していません。
Infrastructure ENUM is defined as the use of the technology in RFC 3761 [RFC3761] by the carrier-of-record (voice service provider) [RFC5067] for a specific E.164 number [E164] in order to publish a mapping of this telephone number to one or more Uniform Resource Identifiers (URIs) [RFC3986].
インフラストラクチャENUMは、この電話のマッピングを公開するために[E164]特定のE.164番号のRFC 3761における技術の使用キャリアのレコード（ボイス・サービス・プロバイダ）によって[RFC3761]、[RFC5067]のように定義されます一つ以上のユニフォームリソース識別子（URIの）[RFC3986]の数。
Other voice service providers can query the DNS for this mapping and use the resulting URIs as input into their call-routing algorithm. These URIs are separate from any URIs that the end-user who registers an E.164 number in ENUM may wish to associate with that E.164 number.
他の音声サービスプロバイダーは、このマッピングのためにDNSを照会し、そのコールルーティングアルゴリズムへの入力として結果のURIを使用することができます。これらのURIは、ENUMにE.164番号を登録し、エンドユーザーがそのE.164番号に関連付けることができる任意のURIから分離されています。
The requirements, terms, and definitions for Infrastructure ENUM are defined in [RFC5067].
インフラストラクチャENUMの要件、用語、および定義は[RFC5067]で定義されています。
Using the same E.164 number to domain mapping techniques for other applications under a different, internationally agreed-upon apex (instead of e164.arpa) is straightforward on the technical side. This process of defining the Dynamic Delegation Discovery System (DDDS) [RFC3401] application for Infrastructure ENUM is defined in [RFC5526]. This is the long-term solution.
（代わりe164.arpaの）国際的に合意された頂点、異なる下に他のアプリケーションのドメインマッピング技術に同じE.164番号を使用すると、技術的な面で簡単です。インフラENUMためのダイナミックな委譲発見システム（DDDS）[RFC3401]アプリケーションが[RFC5526]で定義されている規定のこのプロセス。これは長期的な解決策です。
This document presents an interim solution for Infrastructure ENUM and a mechanism for transitioning to the long-term solution. The interim solution is based on establishing a branch in the e164.arpa tree, which resolvers may locate by following the algorithm described in Section 4. The location of the branch is dependent upon country-code length, and thus resolvers must determine the position of the branch based on the method described in Section 5. Finally, Section 6 provides a way that implementations following the procedures of Sections 4 and 5 may be seamlessly redirected to the long-term solution, when it becomes available.
この文書では、インフラストラクチャENUMと長期的なソリューションへの移行のためのメカニズムのための暫定的な解決策を提示しています。暫定的な解決策は、セクション4で説明されたアルゴリズムに従うことによって見つけることができるレゾルバe164.arpaツリーブランチの確立に基づいている枝の位置国コードの長さに依存し、従って、リゾルバは、の位置を決定しなければなりませんセクション5に記載された方法に基づいて分岐が最後に、第6節は、それが利用可能になったときセクション4及び5の手順に従って実装がシームレスに、長期的な解決策にリダイレクトすることができる方法を提供します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
The agreements to establish the long-term solution may take some time. It was therefore decided to develop an interim solution that can be used by individual countries to implement an interoperable Infrastructure ENUM tree immediately. The interim solution will be deprecated when the long-term solution [RFC5526] is deployed. It is therefore also required that the interim solution includes a smooth migration path to the long-term solution.
長期的な解決策を確立するための協定は多少時間がかかることがあります。したがって、すぐに、相互運用可能なインフラストラクチャENUMツリーを実装するために、個々の国で使用できる暫定的な解決策を開発することを決定しました。長期的な解決策[RFC5526]が展開されたときに暫定的な解決策は廃止されます。したがってまた、暫定的な解決策は、長期的な解決策へのスムーズな移行パスを含むことが必要です。
It is also required that existing ENUM clients querying User ENUM as defined in RFC 3761 [RFC3761] continue to work without any modification.
また、RFC 3761 [RFC3761]で定義されたユーザENUMを問い合わせるENUMクライアントを既存の任意の変更なしで動作し続けることが必要です。
Because of various reasons (e.g., potentially different delegation points, different reliability requirements, and use of DNS wildcards), sharing a single domain name between the user itself and the respective carrier for a given number is not possible. Hence, a different domain name must be used to store infrastructure ENUM information.
ユーザ自体は不可能である所定の数のそれぞれのキャリア間の単一ドメイン名を共有し、様々な理由（例えば、潜在的に異なる委任点、異なる信頼性要件、及びDNSワイルドカードの使用）のため。したがって、別のドメイン名は、インフラストラクチャENUM情報を格納するために使用する必要があります。
In order to avoid the delays associated with the long-term solution, the existing delegations and agreements around e164.arpa need to be leveraged.
長期的な解決策に関連する遅延を避けるために、e164.arpa周りの既存の代表団との合意が活用する必要があります。
The method most easily fulfilling the requirements is to branch off the e164.arpa tree into a subdomain at the country-code delegation level below e164.arpa and deploy an Infrastructure ENUM subtree underneath, without touching User ENUM semantics at all.
最も簡単な要件を満たす方法がe164.arpa以下の国コード委任レベルのサブドメインにe164.arpa木を分岐し、すべてのユーザーENUMセマンティクスを触れることなく、下インフラストラクチャENUMサブツリーを展開することです。
This allows countries using a dedicated country code to introduce the interim solution as a national matter to the concerned National Regulation Authority (NRA). The governing body of a shared country code and the owner of a global network code can also choose to implement this solution within their area of responsibility.
これは、専用の国コードを使用して国が懸念国家規制局（NRA）に全国の問題として暫定的な解決策を導入することができます。共有国コードとグローバルネットワークコードの所有者の管理機関も責任の領域内でこのソリューションを実装することを選択できます。
Under this approach, ITU-T (International Telecommunication Union / Telecommunication Standardization Sector), IETF, and IAB involvement is only lightweight, e.g., to recommend the proper algorithm defined here to enable international interoperability.
このアプローチでは、ITU-T（国際電気通信連合/電気通信標準化部門）、IETF、およびIABの関与は国際的な相互運用を可能にするために、ここで定義され、適切なアルゴリズムを推薦する、例えば、唯一の軽量です。
RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) application according to RFC 3401 [RFC3401]. As such, ENUM defines the following components of the DDDS algorithm:
RFC 3761は、RFC 3401 [RFC3401]に記載のダイナミックな委譲発見システム（DDDS）アプリケーションとしてENUMを定義します。このように、ENUMはDDDSアルゴリズムの次のコンポーネントを定義します。
The "Valid Databases" part contains the transformation of an E.164 telephone number into a domain name. Section 2.4 of RFC 3761 uses the following 4-step algorithm for this:
「有効なデータベース」の部分は、ドメイン名にE.164電話番号の変換が含まれています。 RFC 3761のセクション2.4は、このために、以下の4ステップのアルゴリズムを使用しています：
The interim solution for Infrastructure ENUM uses a modified version of this algorithm:
インフラENUMのための暫定的な解決策は、このアルゴリズムの修正バージョンを使用しています。
1. Determine the proper POSITION parameter for this E.164 number according to the algorithm in Section 5 of this document.
1.このドキュメントのセクション5のアルゴリズムに従って、このE.164番号の適切な位置パラメータを決定します。
2. Build an ordered list of single-digit strings from all digits appearing in the telephone number. All non-digit characters are ignored.
2.電話番号に登場するすべての桁から一桁の文字列の順序付きリストを作成します。すべての数字以外の文字は無視されます。
3. Insert a string consisting of "i" into this list, after POSITION strings. If the list of strings was shorter than POSITION elements, then report an error.
3. POSITION文字列の後に、このリストの中に「I」からなる文字列を挿入します。文字列のリストは、POSITION要素よりも短かった場合は、エラーを報告します。
6. Create a single domain name by joining the list together with dots (".") between each string.
6.各文字列の間（「」）のドットと一緒にリストに参加することにより、単一のドメイン名を作成します。
This is the only point where the interim Infrastructure ENUM (I-ENUM) solution differs from straight RFC 3761 ENUM. All other parts of User ENUM, including the enumservices registrations, apply to I-ENUM as well.
これは、中間インフラストラクチャENUM（I-ENUM）溶液が直線RFC 3761 ENUMと異なる点のみです。 enumservices登録などのユーザーENUMのすべての他の部分は、同様にI-ENUMに適用されます。
In order to allow for the deployment of this interim solution independent of IAB/ITU-T/RIPE-NCC negotiations, the branching label "i" cannot be inserted in the Tier-0 zone (i.e., the e164.arpa zone itself) currently managed by RIPE NCC. This condition acts as a lower bound on the choice of the POSITION parameter.
IAB / ITU-T / RIPE-NCC交渉のこの中間溶液独立の配備を可能にするために、分岐ラベルは、「i」は、現在、ティア0ゾーン（すなわち、e164.arpaゾーン自体）に挿入することができませんRIPE NCCによって管理されます。この条件は、POSITIONパラメータの選択に下限として機能します。
For international E.164-numbers for geographic areas (Section 6.2.1 of [E164]) and for international E.164-numbers for global services (Section 6.2.2 of [E164]), the most sensible choice for POSITION is the number of digits in the country code of the number in question. This places the branch directly under the country-code level within the e164.arpa ENUM tree.
地域（[E164]のセクション6.2.1）用およびグローバル・サービス（[E164]のセクション6.2.2）のための国際E.164-番号の国際E.164-番号については、POSITIONのための最も賢明な選択です問題の番号の国番号の桁数。これは、e164.arpaのENUMツリー内の国コードレベルの直下に支店を置きます。
For international E.164-number for networks (Section 6.2.3 of [E164]), the appropriate choice for POSITION is the combined length of the CC (Country Code) and IC (Identification Code) fields.
ネットワークの国際E.164番号（[E164]のセクション6.2.3）のために、位置についての適切な選択は、CC（国コード）を結合した長さであり、IC（識別コード）フィールド。
For international E.164-number for groups of countries (Section 6.2.4 of [E164]), the value for POSITION is 4.
国のグループの国際E.164番号（[E164]のセクション6.2.4）のために、位置についての値は4です。
The authoritative source for up-to-date country code and network Identification Code allocations is published by the ITU-T as a complement to the recommendation E.164 [E164]. The current version of this complement is available from the ITU website under "ITU-T / Service Publications".
最新の国コードとネットワーク識別コードの割り当てのための信頼できるソースは、推薦E.164 [E164]を補完するものとして、ITU-Tによって発行されます。この補体の現在のバージョンは、「ITU-T /サービス資料」の下のITUのWebサイトから入手可能です。
Please note that country code 1 of the North American Numbering Plan (NANP) does not fall under the ITU classification of "groups of countries", but is a "shared country code" for a geographic area. Thus, the POSITION parameter for the NANP is 1.
北米番号計画（NANP）の国コード1「は国のグループ」のITUの分類に該当しませんのでご注意ますが、地理的地域のための「共有の国コード」ですしてください。このように、NANPのためのPOSITIONパラメータが1です。
As of 2007, the POSITION value for a specific E.164 number can be determined with the following algorithm:
2007年、特定のE.164番号のPOSITION値は、以下のアルゴリズムを用いて決定することができます。
o If the number starts with 1 or 7, then POSITION is 1.
数は1または7で始まる場合、O、その後の位置は1です。
o If the number is in one of the following 2-digit country codes, then POSITION is 2: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, or 98.
20、27、30-34、36、39、40、41、43-49、51-58、60-66、81：番号は以下2桁の国コードのいずれかである場合、Oは、POSITIONは2 、82、84、86、90〜95、または98。
o If the number starts with 388 or 881, then POSITION is 4.
数が388または881で始まる場合、O、次いで、POSITIONは4です。
o If the number starts with 878 or 882, then POSITION is 5.
数が878または882で始まる場合、O、その後、POSITIONは5です。
o If the number starts with 883 and the next digit is < 5, then POSITION is 6.
番号は883で始まり、次の数字である場合、O <5は、位置6です。
o If the number starts with 883 and the next digit is >= 5, then POSITION is 7.
番号は883で始まり、次の数字が> = 5である場合、Oは、POSITIONは7です。
o In all other cases, POSITION is 3.
O他のすべての場合で、POSITIONは3です。
Given the fact that the ITU-T recently allocated only 3-digit country codes, there are no more spare 1- and 2-digit country codes and existing 1- and 2-digit country codes are extremely unlikely to be recovered, the above list of existing 1- and 2-digit country codes can be considered very stable. The only problem may be for a country that has split, as happened recently, for example, to Yugoslavia.
ITU-T最近割り当てられた唯一の3桁の国コード、その事実を考えると、スペア1-および2桁の国コードと既存1-および2桁の国コードはもう存在しない、上記のリスト回復することが極めて低いです1-および2桁の国コードを既存の非常に安定しているとみなすことができます。唯一の問題はユーゴスラビアに、例えば、最近起こったとして、分割した国のためのものであってもよいです。
Regarding network codes, up to 2007, the ITU-T has only allocated 1- and 2-digit ICs. Assignments of 3- and 4-digit ICs started in May 2007 in the +883 country code. Any further change in the ITU-T policy in this respect will need to be reflected in the above algorithm.
ネットワークコードについて2007年まで、ITU-Tは、1-および2-桁ICを割り当てています。 3-および4桁のICの割り当ては、883の国コードで2007年5月に開始しました。この点で、ITU-Tポリシーの更なる変更は、上記のアルゴリズムに反映する必要があります。
The proposed long-term solution for Infrastructure ENUM [RFC5526] is the establishment of a new zone apex for that tree. This apex will play the same role as "e164.arpa" does for User ENUM.
インフラストラクチャENUM [RFC5526]のために提案された長期的な解決策は、そのツリーの新しいゾーンの頂点の確立です。 「e164.arpa」はユーザENUMの場合と同様に、この頂点が同じ役割を果たします。
It is unrealistic to assume that all countries and all ENUM clients will manage to migrate from the interim solution to the long-term solution at a single point in time. It is thus necessary to plan for an incremental transition.
すべての国とすべてのENUMクライアントは、単一の時点で長期的な解決策への暫定的な解決策からの移行を管理すると仮定することは非現実的です。増分移行を計画する必要があります。
In order to achieve this, clients using the interim solution need to be redirected to the long-term I-ENUM tree for all country codes that have already switched to the long-term solution. This SHOULD be done by placing DNAME [RFC2672] records at the branch (the "i") label pointing to the appropriate domain name in the long-term I-ENUM tree. All descendants at that branch label location where the DNAME record is inserted MUST be removed, as required by Section 3 of RFC 2672.
これを達成するためには、暫定的な解決策を使用しているクライアントは、すでに長期的な解決策に切り替えたすべての国コードのための長期的なI-ENUMツリーにリダイレクトする必要があります。これは、長期的なI-ENUMツリーに適切なドメイン名を指すブランチ（「I」）のラベルでDNAME [RFC2672]レコードを置くことによって行われるべきです。 RFC 2672のセクション3で必要とされるDNAMEレコードが挿入された枝のラベルの場所にあるすべての子孫は、削除する必要があります。
Therefore, ALL entities involved in making or answering DNS queries for I-ENUM MUST fully support the DNAME record type and its semantics. In particular, entities involved in I-ENUM lookups MUST correctly handle responses containing synthesized CNAMEs that may be generated as a consequence of DNAME processing by any other element in resolution, typically an iterative mode resolving name server.
したがって、I-ENUM用DNSクエリを作成するか、答えるに関わる全てのエンティティは完全にDNAMEレコードタイプとその意味をサポートしなければなりません。特に、I-ENUM検索に関与するエンティティが正しく解像度、ネームサーバを解決一般的に、反復モードで他の要素によってDNAME処理の結果として生成されてもよい合成のCNAMEを含む応答を処理する必要があります。
These entities MUST also apply adequate measures to detect loops and prevent non-terminating resolutions because of improperly configured DNAME records or combinations of DNAME and CNAME records.
これらのエンティティはまた、ループを検出しているため、不適切に構成されたDNAMEレコードまたはDNAMEとCNAMEレコードの組み合わせの非終了決議を防止するための適切な措置を適用しなければなりません。
Note: Some caching name server implementations are known to handle DNAMEs incorrectly. In the worst case, such bugs could stay undetected until a country transitions to the long-term solution. Therefore, ensuring full DNAME support from the start (and carefully testing that it actually works) is important.
注意：一部のキャッシングネームサーバの実装は間違ってDNAMEsを処理することが知られています。国は長期的なソリューションに移行するまで、最悪の場合には、このようなバグが検出されないとどまることができます。そのため、最初から完全なDNAMEサポートを確保する（と慎重にそれが実際に動作することをテストすること）が重要です。
The domain name for the branch location and its DNAME record SHOULD be removed once the transition to the long-term solution is completed and all entities involved in I-ENUM have migrated to the new zone apex for I-ENUM.
長期的なソリューションへの移行が完了すると、I-ENUMに関わる全てのエンティティは、I-ENUMのための新しいゾーンの頂点に移行した後、分岐する場所やDNAMEレコードのドメイン名を削除する必要があります。
These are two examples of how E.164 numbers translate to Infrastructure ENUM domains according to the interim solution.
これらは、E.164番号は暫定的な解決策に応じたインフラストラクチャENUMドメインに変換する方法の2つの例です。
+1 21255501234 4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa +44 2079460123 3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa
＋１ ２１２５５５０１２３４ ４。３。２。１。０。５。５。５。２。１。２。い。１。え１６４。あｒぱ ＋４４ ２０７９４６０１２３ ３。２。１。０。６。４。９。７。０。２。い。４。４。え１６４。あｒぱ
Here is the list of the intermediate steps for the second example to visualize how the algorithm defined in Section 4 operates on "+44 2079460123":
ここでは第4節で定義されたアルゴリズムは「+44 2079460123」にどのように動作するかを可視化するための第二の例のための中間ステップのリストは、次のとおりです。
1. "+44 2079460123" is within a 2-digit country code; thus, POSITION is 2.
1.「+44 2079460123は」2桁の国コード内にあります。したがって、POSITIONは2です。
2. The list of strings is ("4","4","2","0","7","9","4","6","0","1","2","3")
2.文字列のリストは、（ "4"、 "4"、 "2"、 "0"、 "7"、 "9"、 "4"、 "6"、 "0"、 "1"、 "2であります」、 "3"）
3. POSITION is 2; thus, "i" is inserted between the second and the third string, yielding: ("4","4","i","2","0","7","9","4","6","0","1","2","3")
3. POSITIONは2です。従って、 "i" は降伏、第二及び第三の列の間に挿入される（ "4"、 "4"、 "I"、 "2"、 "0"、 "7"、 "9"、 "4"、 "6"、 "0"、 "1"、 "2"、 "3"）
4. Reversing the list gives: ("3","2","1","0","6","4","9","7","0","2","i","4","4")
4.リストを与える反転：（ "3"、 "2"、 "1"、 "0"、 "6"、 "4"、 "9"、 "7"、 "0"、 "2"、I " 」、 "4"、 "4"）
5. Appending "e164.arpa" yields: ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")
5. "e164.arpa" 収率をアペンド：（ "3"、 "2"、 "1"、 "0"、 "6"、 "4"、 "9"、 "7"、 "0"、 "2" 、 "I"、 "4"、 "4"、 "e164.arpa"）
6. Concatenation with dots yields: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"
ドットの収率で6連結：「3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa」
After the introduction of the long-term Infrastructure ENUM solution, using, for example, "ienum.example.net" as the new apex for I-ENUM, the administrators of +44 can implement a smooth transition by putting the following DNAME record in their zone:
長期的なインフラENUMソリューションの導入後、I-ENUMのための新たな頂点として、例えば、「ienum.example.net」を使用して、44の管理者は、次のようにDNAMEレコードを置くことによってスムーズな移行を実現することができますそのゾーン：
i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net.
i.4.4.e164.arpa。 DNAMEの4.4.ienum.example.net、IN。
This way, clients using the interim I-ENUM solution end up querying the same tree as clients implementing the long-term solution.
このように、暫定I-ENUMのソリューションを使用しているクライアントは、長期的なソリューションを実装するクライアントと同じツリーを照会終わります。
Privacy issues have been raised regarding the unwarranted disclosure of user information that would result from publishing Infrastructure ENUM information in the public DNS. For instance, such disclosure could be used for harvesting numbers in service or obtaining unlisted numbers.
プライバシーの問題は、パブリックDNSにインフラENUM情報を公開から生じる利用者情報の不当な開示に関する提起されています。例えば、そのような開示は、サービス又は非公開番号を得ることに収穫番号を使用することができます。
Given that number-range allocation is public information, we believe the easiest way to cope with such concerns is to fully unroll allocated number ranges in the Infrastructure ENUM subtree, wherever such privacy concerns exist. Whether or not a number is served would be exposed by the carrier-of-record when an attempt is made to contact the corresponding URI. We assume this to be an authenticated operation, which would not leak information to unauthorized parties.
そのようなプライバシーの問題が存在する場所にその番号範囲の割り当てが公開情報で考えると、我々はそのような懸念に対処する最も簡単な方法は、完全に割り当てられた番号をアンロールすることであると信じてすることは、インフラストラクチャENUMサブツリーの範囲です。試みが対応するURIを接触させる際に役立っている数は、キャリアのレコードによって公開されることになるかどうか。私たちは、これが権限のない者に情報を漏洩しないだろう、認証操作、であることを前提としています。
Entering all numbers in an allocated number range, whether serviced or not, or whether listed or unlisted, will prevent mining attempts for such number attributes.
割り当てられた番号の範囲内のすべての数値を入力、またはリストされているか否かを非公開サービスか否か、そのような数の属性の採掘の試みを防止します。
The result will be that the information in the public DNS will mirror number-range allocation information, but no more. Infrastructure ENUM will not tell you more than you can get by just dialing numbers.
結果は、パブリックDNSの情報が数値範囲割当情報が、もはやをミラーリングすることであろう。インフラストラクチャENUMはあなただけの番号をダイヤルすることにより得ることができるより多くを教えてくれません。
The URI pointing to the destination network of the carrier-of-record should also not disclose any privacy information about the identity of the end-user. It is therefore recommended to use either anonymized UserIDs or the E.164 number itself in the user part of the URI, such as in sip:+441632960084@example.com.
キャリア・オブ・レコードの宛先ネットワークへのURIのポインティングまた、エンドユーザの身元に関するあらゆる個人情報を開示するべきではありません。 +441632960084@example.com：したがって、匿名化ユーザID又はSIPのようなURIのユーザ部分にE.164番号自体、のいずれかを使用することが推奨されます。
We gratefully acknowledge suggestions and improvements by Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of AT&T, Lawrence Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of enum.at.
私たちは感謝ジェイソンLivingoodとコムキャストのトム・クレイトン、AT＆TのペンPfautz、Rokeマナー研究所のローレンス・コンロイ、ジム・リード、およびenum.at.のアレクサンダーMayrhoferによって提案や改善を認めます
[E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E164] 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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]クロフォード、M.、 "非ターミナルDNS名リダイレクション"、RFC 2672、1999年8月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[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.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067]リンド、S.とP. Pfautz、 "インフラストラクチャENUM要件"、RFC 5067、2007年11月。
[RFC5526] Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", RFC 5526, April 2007.
[RFC5526] Livingood、J.、Pfautz、P.、およびR. Stastny、 "インフラストラクチャENUMのための統一資源識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション"、RFC 5526、2007年4月。
Authors' Addresses
著者のアドレス
Michael Haberler Internet Foundation Austria Karlsplatz 1/2/9 Wien 1010 Austria
マイケルHaberlerインターネット財団オーストリアカールス1/2/9ウィーンオーストリア
Phone: +43 664 4213465 EMail: ietf@mah.priv.at URI: http://www.nic.at/ipa/
電話：+43 664 4213465 Eメール：URI ietf@mah.priv.at：http://www.nic.at/ipa/
Otmar Lendl enum.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria
オトマールレンドルは1010年オーストリアウィーンGmbH社カールス1/2/9をenum.at
Phone: +43 1 5056416 33 EMail: otmar.lendl@enum.at URI: http://www.enum.at/
電話：+43 1 5056416 33電子メール：URI otmar.lendl@enum.at：http://www.enum.at/
Richard Stastny Unaffiliated Anzbachgasse 43 1140 Vienna Austria
リチャードStastny無所属Anzbachgasse 43 1140ウィーンオーストリア
Phone: +43 664 420 4100 EMail: richardstastny@gmail.com
電話：+43 664 420 4100 Eメール：richardstastny@gmail.com