[要約] RFC 4415は、Enumservice VoiceのIANA登録に関する要件を定めています。その目的は、Enumservice Voiceの一貫性と一元管理を確保し、VoIP通信の効率と信頼性を向上させることです。
Network Working Group R. Brandner
Request for Comments: 4415 Siemens AG
Category: Standards Track L. Conroy
Siemens Roke Manor Research
R. Stastny
Oefeg
February 2006
IANA Registration for Enumservice Voice
Enumservice VoiceのIANA登録
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.
このドキュメントは、Enum Specification RFC 3761で定義されているIANA登録プロセスに従って、Enumservice "Voice"（定義されたサブタイプ「Tel」）を登録します。インタラクティブな音声（オーディオ）呼び出しを開始するために使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Voice Service Registration . . . . . . . . . . . . . . . . . . 3
4. Example of voice:tel Enumservice . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms E.164 numbers [2] into domain names and then uses DNS (RFC 1034 [3]) features such as delegation through NS records, and the use of Naming Authority Pointer (NAPTR) records, to look up the communication services available for a specific domain name.
Enum（E.164番号マッピング、RFC 3761 [1]）は、E.164番号[2]をドメイン名に変換し、NSレコードを介した委任などのDNS（RFC 1034 [3]）機能を使用するシステムです。特定のドメイン名で利用可能な通信サービスを検索するために、命名権限ポインター（NAPTR）レコードを使用します。
This document registers an Enumservice according to the guidelines given in RFC 3761 to be used for provisioning in the services field of a NAPTR [4] resource record to indicate what class of functionality a given endpoint offers. The registration is defined within the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7] [8]) hierarchy, for use with the "E2U" DDDS application defined in RFC 3761.
このドキュメントは、NAPTR [4]リソースレコードのサービスフィールドでのプロビジョニングに使用されるRFC 3761に記載されているガイドラインに従って、特定のエンドポイントが提供する機能のクラスを示すために使用されるガイドラインを登録します。登録は、RFC 3761で定義された「E2U」DDDSアプリケーションで使用するために、動的委任ディスカバリーシステム（DDDS、[5] [6] [4] [7] [8]）階層内で定義されます。
Enumservices have a type and subtype. This latter is optional, as it may be implicit in the service type. The type defines the kind of communication session that can be initiated using the contact indicated by the URI generated by the enclosing NAPTR. In telecommunications engineering terms, it reflects the "teleservice".
Enumservicesには、タイプとサブタイプがあります。この後者はオプションであり、サービスタイプに暗黙的である可能性があるためです。このタイプは、囲まれたNAPTRによって生成されたURIによって示される連絡先を使用して開始できる通信セッションの種類を定義します。電気通信工学用語では、「テレサービス」を反映しています。
The subtype defines the subsystem that is to be used to initiate the communication session. Note that the subtype definition is usually associated with the URI scheme that is to be used.
サブタイプは、通信セッションの開始に使用されるサブシステムを定義します。サブタイプ定義は通常、使用するURIスキームに関連付けられていることに注意してください。
Both the type and subtype (where present) must be supported for the NAPTR to be used by a potential correspondent.
NAPTRが潜在的な特派員が使用するには、型とサブタイプ（存在する場所）の両方をサポートする必要があります。
There are a number of DDDS applications in addition to ENUM (for example, see [7] and [8]). However, an Enumservice indication operates only within the context of the "E2U" (ENUM) DDDS Application.
列挙に加えて、多くのDDDSアプリケーションがあります（たとえば、[7]および[8]を参照）。ただし、Enumserviceの表示は、「E2U」（Enum）DDDSアプリケーションのコンテキスト内でのみ動作します。
Whilst the protocol elements that make up ENUM are defined in the above documents and in this one, further examples of the use to which these may be put are given in other documents, for example, in ETSI TS 102 172 [11].
列挙を構成するプロトコル要素は、上記のドキュメントとこの文書で定義されていますが、これらの使用の例は、たとえばETSI TS 102 172 [11]など、他のドキュメントに記載されています。
This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call.
このドキュメントは、Enum Specification RFC 3761で定義されているIANA登録プロセスに従って、Enumservice "Voice"（定義されたサブタイプ「Tel」）を登録します。インタラクティブボイス（オーディオ）コール。
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 [9].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [9]に記載されているように解釈される。
Enumservice Name: "voice"
Enumservice名：「Voice」
Enumservice Type: "voice"
Enumserviceタイプ：「Voice」
Enumservice Subtype: "tel"
Enumserviceサブタイプ： "Tel"
URI Scheme: 'tel:'
URIスキーム：「Tel：」
Functional Specification:
機能仕様：
The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data.
このEnumserviceで示されるコミュニケーションの種類は、「インタラクティブな音声」です。プロトコルの観点から、この通信は、オーディオデータを運ぶ双方向のメディアストリームを含むことが期待されています。
A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates his capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR.
クライアントは、このEnumserviceを保持しているNAPTRの人口を制御する人が、このNAPTRによって生成されたURIを使用して連絡したときにインタラクティブな音声セッションに参加する能力を示していることを暗示する場合があります。
Security Considerations:
セキュリティ上の考慮事項：
See Section 5.
セクション5を参照してください。
Intended Usage: COMMON
意図された使用法：共通
Authors:
著者：
Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author contact detail, see Authors' Addresses section)
Rudolf Brandner、Lawrence Conroy、およびRichard Stastny（著者の連絡先の詳細については、著者のアドレスセクションを参照）
Any other information the author deems interesting:
著者が興味深いと思うその他の情報：
This Enumservice indicates that the person responsible for the NAPTR is accessible via the Public Switched Telephone Network (PSTN) or Public Land Mobile Network (PLMN) using the value of the generated URI.
このEnumserviceは、NAPTRの責任者が、生成されたURIの値を使用して、パブリックスイッチ付き電話ネットワーク（PSTN）またはパブリックランドモバイルネットワーク（PLMN）を介してアクセスできることを示しています。
The kind of subsystem required to initiate a Voice Enumservice with this subtype is a "Dialer". This is a subsystem that either provides a local connection to the PSTN or PLMN or provides an indirect connection to those networks. The subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination.
このサブタイプでVoice Enumserviceを開始するために必要なサブシステムの種類は、「ダイヤラー」です。これは、PSTNまたはPLMNへのローカル接続を提供するか、それらのネットワークへの間接的な接続を提供するサブシステムです。サブシステムは、生成されたURIに保持されている電話番号を使用して音声通話を行います。音声呼び出しは、E.164番号を使用して適切な宛先に通話をルーティングするネットワークに配置されます。
Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case, the provider either may accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form.
PSTN/PLMN接続が間接的である可能性があることに注意してください。このNAPTRを受信するエンドユーザーは、SIPやH.323などのIPベースのプロトコルを使用してそのサブシステムからのコール開始要求を受け入れる通信サービスプロバイダーと関係があり、リモートゲートウェイサービスを使用してPSTNへの呼び出しを配置する場合があります。この場合、プロバイダーは「Tel：」を使用してリクエストを受け入れることができます。
The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC 3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination.
「Tel：」URI値は完全に適格でなければなりません（RFC 3966 [10]の「グローバル電話番号」フォームを使用）。NAPTRが表示されるゾーンのコントローラーが、リソースレコードにアクセスできるすべてのクライアントによって明確に区別できること、およびネットワークからの呼び出しがある場合、そのドキュメントで定義されている「ローカル電話番号」は使用すべきではありません。アクセスポイントはその目的地までルーティングできます。
The following is an example of the use of the Enumservice registered by this document in a NAPTR resource record.
以下は、NAPTRリソースレコードでこのドキュメントで登録されたEnumserviceの使用の例です。
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+voice:tel" "!^.*$!tel:+441414960000!" .
$ origin 0.6.9.2.3.6.1.4.4.e164.Arpa。3.8.0 NAPTR 10 100 "U" "E2U音声：Tel"！^。*$！tel：441414960000！ "。
DNS, as used by ENUM, is a global, distributed database. Thus, any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a telephone directory, it does open the data subjects to having "their" information collected automatically without any indication that this has been done or by whom.
enumで使用されるDNSは、グローバルな分散データベースです。したがって、そこに保存されている情報は、匿名で誰にも表示されます。これは電話ディレクトリに公開されることと定性的に違いはありませんが、データ主体は、これが行われたことを示すことなく「彼らの」情報を自動的に収集するように開きます。
Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email sent increases when he or she posts to the mailing list; publication of a telephone number in ENUM is no different, and may be used for attempts to send "junk faxes" or "junk SMS", for example.
サードパーティによるこのようなデータ収穫は、多くの場合、要求されていない情報のターゲットのリストを生成するために使用されます。要するに、それらは「スパム」に対処するために使用されます。Webアーカイブメーリングリストを使用している人なら誰でも、「スパム」電子メールのボリュームがメーリングリストに投稿すると増加することを認識しています。Enumでの電話番号の公開も例外ではなく、たとえば「ジャンクファックス」または「ジャンクSMS」を送信する試みに使用できます。
Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible.
多くのメーリングリストのユーザーは、複数のメールアドレスを持っており、そのようなリストに投稿するときに「犠牲」メールアカウントを使用して、送信されていない要求のない電子メールをフィルタリングするのに役立ちます。これは、公開された電話番号ではそれほど簡単ではありません。PSTN E.164番号割り当てプロセスははるかに関与しており、通常、単一のE.164数（または固定範囲の範囲）が各PSTNアクセスに関連付けられています。したがって、どの出版物でも「犠牲的な」電話番号を提供することは不可能です。
Due to the implications of publishing data on a globally accessible database, as a principle the data subjects MUST give their explicit informed consent to data being published in ENUM.
グローバルにアクセス可能なデータベースにデータを公開することが意味するため、データ主体はenumで公開されているデータに対する明示的なインフォームドコンセントを与えなければなりません。
In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.
さらに、第三者による収穫中にそのようなデータを保存したため、出版物からのデータの削除が取得されたコピーを削除しないことを認識する必要があります。事実上、どの出版物も永続的である可能性があります。
However, regulations in many regions will require that the data subjects can at any time request that the data be removed from publication and that their consent for its publication be explicitly confirmed at regular intervals.
ただし、多くの地域の規制では、データ主体はいつでもデータを公開から削除することを要求し、その出版物の同意を定期的に明示的に確認することを要求します。
When placing a voice call via the PSTN (or from the Public Land Mobile Network), the sender may be charged for this action. In both kinds of networks, calling some numbers is more expensive than sending to others; both kinds of networks have "premium rate" services that can be charged at a rate considerably more than a "normal" call. As such, it is important that end users be asked to confirm placing the call and that the destination number be presented to them. It is the originating user's choice whether or not to place a call to this destination number, but the originating user SHOULD be shown the destination number so that he or she can make this decision.
PSTN（またはPublic Land Mobile Networkから）を介して音声コールを配置する場合、このアクションに対して送信者が請求される場合があります。どちらの種類のネットワークでも、いくつかの数値を呼び出すことは、他の人に送信するよりも高価です。どちらの種類のネットワークにも、「通常の」呼び出しよりもかなり高いレートで請求できる「プレミアムレート」サービスがあります。そのため、エンドユーザーを通話の配置を確認するように求められ、宛先番号を提示することが重要です。この宛先番号に電話をかけるかどうかは、元のユーザーの選択ですが、この決定を下すことができるように、発信者のユーザーに宛先番号を表示する必要があります。
In addition to the specific security considerations given above, all security considerations given in RFC 3761 apply, as well as the DNS-specific threats covered in RFC 3833 [12].
上記の特定のセキュリティ上の考慮事項に加えて、RFC 3761に記載されているすべてのセキュリティ上の考慮事項が適用され、RFC 3833でカバーされているDNS固有の脅威が適用されます[12]。
The IANA has registered the Enumservice "voice" with a single subtype "tel" according to the framework defined in RFC 3761. The current document defines this Enumservice and the expected behaviour of clients.
IANAは、RFC 3761で定義されているフレームワークに従って、単一のサブタイプ「Tel」でEnumservice「Voice」を登録しています。現在のドキュメントは、このエンサムサービスとクライアントの予想される動作を定義しています。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[2] ITU-T、「国際公開通信番号計画」、推奨事項E.164、1997年5月。
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987.
[3] Mockapetris、P。、「ドメイン名 - 概念と施設」、RFC 1034、1987年11月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[6] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[7] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）」、RFC 3404、2002年10月。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[8] Mealling、M。、「動的委任発見システム（DDDS）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[10] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[11] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005.
[11] ETSI、「列挙実装の相互運用性に関する最小要件」、ETSI TS 102 172、2005年1月。
[12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[12] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
Authors' Addresses
著者のアドレス
Rudolf Brandner Siemens AG Hofmannstr. 51 81359 Munich Germany
Rudolf Brandner Siemens AG Hofmannstr。51 81359ミュンヘンドイツ
Phone: +49-89-722-51003
EMail: rudolf.brandner@siemens.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom
ローレンス・コンロイ・シーメンス・ローク・マナー研究ローク・マナー・ロムジー・イギリス
Phone: +44-1794-833666
EMail: lwc@roke.co.uk
Richard Stastny Oefeg Postbox 147 1103 Vienna Austria
リチャード・スタストニー・オフェグ・ポストボックス147 1103ウィーン・オーストリア
Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。