RFC 5527 - Combined User and Infrastructure ENUM in the e164.arpa Tree 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5527
タイトル : RFC 5527 - E164.ARPAツリーのユーザーとインフラストラクチャの列挙の組み合わせ
翻訳編集 : 自動生成

[要約] RFC 5527は、e164.arpaツリー内のユーザーとインフラストラクチャのENUMを組み合わせたものであり、電話番号とインターネットリソースの関連付けを可能にする。目的は、電話番号とインターネットリソースの統合を促進し、通信の効率と柔軟性を向上させること。

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

E164.ARPAツリーのユーザーとインフラストラクチャの列挙の組み合わせ

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

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でのユーザーとインフラストラクチャの列挙の実装を全国的な選択として許可するために、インフラストラクチャ列挙の暫定ソリューションを定義します。この暫定ソリューションは、長期ソリューションの実装後に廃止されます。

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

1. Introduction

1. はじめに

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]）は、E.164番号[E164]をドメイン名に変換し、NAPTR（命名権限ポインター）レコードの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.

RFC 3761（ユーザー列挙）で定義されている列挙は、列挙メカニズムに基づいたさまざまなプライベートツリーアレンジメントの使用によって見ることができるように、キャリアと音声サービスプロバイダーによる相互接続の目的ではあまり適していません。

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].

インフラストラクチャの列挙は、この電話のマッピングを公開するために、特定のE.164番号[E164]に対して、キャリアの録音（Voice Service Provider）[RFC5067]によって、RFC 3761 [RFC3761] [RFC3761]のテクノロジーの使用として定義されます。1つ以上の均一なリソース識別子（URIS）[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数に関連付けたい場合があるというurisとは別です。

The requirements, terms, and definitions for Infrastructure ENUM are defined in [RFC5067].

インフラストラクチャ列挙の要件、用語、および定義は、[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.

同じE.164番号を使用すると、異なる国際的に合意されたApex（E164.ARPAの代わりに）の下で他のアプリケーションのドメインマッピング手法を使用することは、技術的な面では簡単です。動的委任ディスカバリーシステム（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.

このドキュメントでは、インフラストラクチャの列挙の暫定ソリューションと、長期ソリューションに移行するメカニズムを提示します。暫定ソリューションは、E164.ARPAツリーにブランチを確立することに基づいています。これは、セクション4で説明したアルゴリズムに従うことでリゾルバーが位置する可能性があります。ブランチの位置は国コードの長さに依存するため、リゾルバーはの位置を決定する必要があります。セクション5で説明した方法に基づくブランチは、最後に、セクション4および5の手順に従って実装が利用可能になったときに長期ソリューションにシームレスにリダイレクトされる方法を説明します。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。

3. Interim Solution

3. 暫定ソリューション

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.

長期的なソリューションを確立するための契約には時間がかかる場合があります。したがって、個々の国で使用して、相互運用可能なインフラストラクチャ列挙ツリーをすぐに実装できる暫定ソリューションを開発することが決定されました。暫定ソリューションは、長期ソリューション[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ワイルドカードの使用）のため、ユーザー自体と特定の番号のそれぞれのキャリアの間で単一のドメイン名を共有することは不可能です。したがって、インフラストラクチャの列挙情報を保存するために、別のドメイン名を使用する必要があります。

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未満の国コード委任レベルでサブドメインに分岐し、その下にインフラストラクチャエインムサブツリーを展開することです。

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の関与は、国際的な相互運用性を可能にするためにここに定義されている適切なアルゴリズムを推奨するために、軽量のみです。

4. The Algorithm

4. アルゴリズム

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]に従って、enumを動的委任ディスカバリーシステム（DDDS）アプリケーションとして定義します。そのため、EnumはDDDSアルゴリズムの次のコンポーネントを定義します。

1. Application Unique String

1. アプリケーション一意の文字列

2. First Well-Known Rule

2. 最初によく知られているルール

3. Expected Output

3. 予想出力

4. Valid Databases

4. 有効なデータベース

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段階アルゴリズムを使用しています。

1. Remove all characters with the exception of the digits.

1. 数字を除き、すべての文字を削除します。

2. Put dots (".") between each digit.

2. 各数字の間にドット（ "。"）を置きます。

3. Reverse the order of the digits.

3. 数字の順序を逆にします。

4. Append the string ".e164.arpa" to the end.

4. 文字列「.e164.arpa」を最後に追加します。

The interim solution for Infrastructure ENUM uses a modified version of this algorithm:

インフラストラクチャ列挙の暫定ソリューションは、このアルゴリズムの変更されたバージョンを使用しています。

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. 電話番号に表示されるすべての数字から1桁の文字列の注文リストを作成します。すべての非桁の文字は無視されます。

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. 位置文字列の後に、このリストに「I」からなる文字列を挿入します。文字列のリストが位置要素よりも短い場合は、エラーを報告します。

4. Reverse the order of the list.

4. リストの順序を逆にします。

5. Append the string "e164.arpa" to the end of the list.

5. リストの最後に文字列「e164.arpa」を追加します。

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.

これは、暫定インフラストラクチャエインム（I-Enum）ソリューションがストレートRFC 3761列挙とは異なる唯一のポイントです。Enumservices登録を含むユーザーenumの他のすべての部分も、i-Enumにも適用されます。

5. Determining the Position of the Branch

5. ブランチの位置を決定します

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」をTier-0ゾーン（つまり、E164.ARPAゾーン自体）に挿入することはできません。Ripe NCCが管理しています。この条件は、位置パラメーターの選択の下限として機能します。

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.

地理的領域の国際E.164番号（[E164]のセクション6.2.1）およびグローバルサービスの国際E.164番号（[E164]のセクション6.2.2）の場合、ポジションの最も賢明な選択は問題の数の国コードの数字数。これにより、Branchは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-Number（[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 / Service Publications」の下で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の位置パラメーターは1です。

As of 2007, the POSITION value for a specific E.164 number can be determined with the following algorithm:

2007年の時点で、特定のE.164番号の位置値は、次のアルゴリズムで決定できます。

o If the number starts with 1 or 7, then POSITION is 1.

o 数値が1または7で始まる場合、位置は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.

o 数字が次の2桁の国コードのいずれかにある場合、位置は2：20、27、30-34、36、39、40、41、43-49、51-58、60-66、81、82、84、86、90-95、または98。

o If the number starts with 388 or 881, then POSITION is 4.

o 数値が388または881で始まる場合、位置は4です。

o If the number starts with 878 or 882, then POSITION is 5.

o 数値が878または882で始まる場合、位置は5です。

o If the number starts with 883 and the next digit is < 5, then POSITION is 6.

o 数値が883で始まり、次の数字が5である場合、位置は6です。

o If the number starts with 883 and the next digit is >= 5, then POSITION is 7.

o 数値が883で始まり、次の数字が> = 5の場合、位置は7です。

o In all other cases, POSITION is 3.

o 他のすべての場合、位置は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桁のICSの割り当ては、2007年5月に883 Country Codeで開始されました。この点でITU-Tポリシーのさらなる変更は、上記のアルゴリズムに反映される必要があります。

6. Transition to the Long-Term Solution

6. 長期ソリューションへの移行

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.

インフラストラクチャ列挙のための提案された長期ソリューション[RFC5526]は、そのツリーの新しいゾーン頂点の確立です。この頂点は、ユーザーenumで「e164.arpa」が行うのと同じ役割を果たします。

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.

すべての国とすべての列挙クライアントが、暫定的なソリューションから長期的なソリューションに単一の時点で移行することを想定することは非現実的です。したがって、増分遷移を計画する必要があります。

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エナムツリーにリダイレクトする必要があります。これは、長期のi-enumツリーの適切なドメイン名を指すブランチ（「i」）ラベルにDNAME [RFC2672]レコードを配置することで行う必要があります。DNAMEレコードが挿入されているそのブランチラベルの場所にあるすべての子孫は、RFC 2672のセクション3で要求されるように、削除する必要があります。

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.

注：一部のキャッシュネームサーバーの実装は、DNAMEを誤って処理することが知られています。最悪の場合、そのようなバグは、国が長期的な解決策に移行するまで検出されないままになる可能性があります。したがって、最初から完全な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.

ブランチロケーションのドメイン名とそのDNAMEレコードは、長期ソリューションへの移行が完了し、I-Enumに関与するすべてのエンティティがI-Enumの新しいゾーンApexに移行した後に削除する必要があります。

7. Examples

7. 例

These are two examples of how E.164 numbers translate to Infrastructure ENUM domains according to the interim solution.

これらは、E.164の数値が、暫定ソリューションに従ってインフラストラクチャ列挙ドメインにどのように変換されるかの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」でどのように動作するかを視覚化するために、2番目の例の中間手順のリストを次に示します。

1. "+44 2079460123" is within a 2-digit country code; thus, POSITION is 2.

1. 「44 2079460123」は2桁の国コード内にあります。したがって、位置は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. 位置は2です。したがって、「i」は2番目と3番目の文字列の間に挿入され、（ "4"、 "4"、 "i"、 "2"、 "0"、 "7"、 "9"、4 "、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. Appling "e164.arpa" evers：（ "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:

「ienum.example.net」を使用して、長期インフラストラクチャ列挙ソリューションを導入した後、i-enumの新しい頂点として、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で。

This way, clients using the interim I-ENUM solution end up querying the same tree as clients implementing the long-term solution.

これにより、暫定Iエナムソリューションを使用しているクライアントは、長期ソリューションを実装するクライアントと同じツリーをクエリすることになります。

8. Security Considerations

8. セキュリティに関する考慮事項

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でインフラストラクチャの列挙情報を公開したことから生じるユーザー情報の不当な開示に関して提起されています。たとえば、このような開示は、サービスで数値を収穫したり、非上場の数を取得したりするために使用できます。

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.

数字の割り当てが公開情報であることを考えると、このような懸念に対処する最も簡単な方法は、そのようなプライバシーの懸念が存在していれば、インフラストラクチャエニュムサブツリーに割り当てられた数の範囲を完全に展開することだと考えています。対応する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の情報は数値範囲の割り当て情報を反映しますが、それ以上はありません。インフラストラクチャの列挙は、数字をダイヤルするだけで得られる以上のことを伝えません。

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は、エンドユーザーのIDに関するプライバシー情報を開示してはなりません。したがって、SIP：441632960084@example.comなど、URIのユーザー部分に匿名化されたユーザーIDまたはE.164番号自体を使用することをお勧めします。

9. Acknowledgments

9. 謝辞

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.

ComcastのJason LivingoodとTom Creighton、AT＆TのPenn Pfautz、Roke Manor ResearchのLawrence Conroy、Jim Reid、およびEnum.at.

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.

[RFC2672] Crawford、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）パート1：包括的な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。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、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。

10.2. Informative References

10.2. 参考引用

[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.

[RFC5067] Lind、S。およびP. Pfautz、「インフラストラクチャ列要件」、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、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーションインフラストラクチャ列挙のアプリケーション、RFC 5526、2007年4月。

Authors' Addresses

著者のアドレス

Michael Haberler Internet Foundation Austria Karlsplatz 1/2/9 Wien 1010 Austria

マイケルハーバーラーインターネット財団オーストリアカールスプラッツ1/2/9 Wien 1010オーストリア

   Phone: +43 664 4213465
   EMail: ietf@mah.priv.at
   URI:   http://www.nic.at/ipa/

Otmar Lendl enum.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria

Otmar Lendl Enum.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria

   Phone: +43 1 5056416 33
   EMail: otmar.lendl@enum.at
   URI:   http://www.enum.at/

Richard Stastny Unaffiliated Anzbachgasse 43 1140 Vienna Austria

リチャード・スタストニー・アフィリエートされていないアンズバッハガス43 1140ウィーンオーストリア

   Phone: +43 664 420 4100
   EMail: richardstastny@gmail.com