Network Working Group J. Livingood
Request for Comments: 5278 Comcast Cable Communications
Category: Standards Track D. Troshynski
Acme Packet
July 2008
IANA Registration of Enumservices for Voice and Video Messaging
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type.
この文書では、メッセージングシステムにEnumserviceという名前の音声のリアルタイムのルーティングを容易にするために使用される「VMSG」、ビデオ、およびユニファイドコミュニケーションを登録します。 "voicemsg"、 "videomsg"、および "unifmsg"：このVMSG Enumserviceは3つのEnumserviceタイプを登録します。各タイプは、サブタイプ「SIP」、「すする」、「HTTP」、および「HTTPS」、ならびに「voicemsg」タイプのサブタイプ「TEL」を登録します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Selected Use Cases for Illustrative Purposes ...............4
1.2. Consideration of Other Existing Enumservices ...............5
2. Distribution of Data ............................................5
3. Security Considerations .........................................5
4. ENUM Service Registration for voicemsg ..........................6
4.1. Registration for "voicemsg" with Subtype "sip" .............6
4.2. Registration for "voicemsg" with Subtype "sips" ............7
4.3. Registration for "voicemsg" with Subtype "tel" .............7
4.4. Registration for "voicemsg" with Subtype "http" ............8
4.5. Registration for "voicemsg" with Subtype "https" ...........9
5. ENUM Service Registration for videomsg .........................10
5.1. Registration for "videomsg" with Subtype "sip" ............10
5.2. Registration for "videomsg" with Subtype "sips" ...........10
5.3. Registration for "videomsg" with Subtype "http" ...........11
5.4. Registration for "videomsg" with Subtype "https" ..........12
6. ENUM Service Registration for unifmsg ..........................13
6.1. Registration for "unifmsg" with Subtype "sip" .............13
6.2. Registration for "unifmsg" with Subtype "sips" ............13
6.3. Registration for "unifmsg" with Subtype "http" ............14
6.4. Registration for "unifmsg" with Subtype "https" ...........15
7. Selected Examples for Illustrative Purposes ....................16
7.1. Example Using a 'sip' URI .................................16
7.2. Example Using a 'tel' URI .................................16
7.3. Example Using a Backreference .............................16
7.4. Example Using a 'sip' URI without a Telephone Number ......17
7.5. Example of Failover Using E2U+videomsg:sip ................17
8. Implementation Recommendations .................................17
8.1. Call Processing When Multiple Records Are Returned ........17
8.2. NAPTR Configuration Issues ................................18
9. IANA Considerations ............................................18
10. Acknowledgements ..............................................18
11. Contributors ..................................................19
12. References ....................................................19
12.1. Normative References .....................................19
12.2. Informative References ...................................20
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that transforms E.164 numbers (the International Public Telecommunication Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and then uses DNS (Domain Name System, RFC 1034 [3]) delegation through NS records and Naming Authority Pointer (NAPTR) records (Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 [4]) to look up what services are available for a specific domain name.
ENUM（E.164番号のマッピングは、RFC 3761 [1]）E.164番号（国際公共通信番号計画、ITU-T勧告E.164 [2]）のドメイン名にしてから使用してDNSを変換技術（ありますドメインネームシステム、NSレコードを通してRFC 1034 [3]）代表団と命名権限ポインタ（NAPTR）レコード（ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース、RFC 3403 [4]）見てどのようなアップサービスは、特定のドメイン名のためにご利用いただけます。
This document registers Enumservices according to the guidelines given in RFC 3761 [1] to be used for provisioning in the services field of a NAPTR [4] resource record to indicate the types of functionality associated with an end point and/or telephone number. The registration is defined within the DDDS (Dynamic Delegation Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761.
この文書は、エンドポイント及び/又は電話番号に関連する機能の種類を示すNAPTR [4]リソースレコードのサービスフィールドにプロビジョニングするために使用される[1] RFC 3761に指定されたガイドラインに従ってEnumservices登録します。登録は、RFC 3761で定義された "E2U" DDDSアプリケーションで使用するためのDDDS（ダイナミックな委譲発見システム[4] [5] [6] [7] [8]）階層内で定義されています。
Voice messaging systems are used widely with telephony and voice communication services. The need for a voice messaging service type has become clear in order to provide certain applications with direct access to various voice messaging services (for example, voicemail), most typically via the use of SIP.
ボイスメッセージングシステムは、テレフォニーおよび音声通信サービスで広く使用されています。音声メッセージングサービスタイプの必要性は、最も典型的にはSIPを使用することにより、（例えば、ボイスメール）、さまざまなボイスメッセージサービスに直接アクセスして、特定のアプリケーションを提供するために明らかになりました。
The authors considered the use of Voice Profile for Internet Mail (VPIM) [14] but found that VPIM was best suited to the non-real-time and non-session-based routing of a voice message once it had been deposited into a voice messaging system. Thus, VPIM was a good solution for the non-real-time and non-session-based routing of voice messages between and within domains, but it did not enable real-time interaction with a voice messaging system.
著者は、インターネットメール（VPIM）[14]のための音声プロファイルの使用を検討したが、それは声に寄託された後、VPIMボイスメッセージの非リアルタイムおよび非セッションベースのルーティングに最適であることがわかりましたメッセージングシステム。このように、VPIMは非リアルタイムとの間およびドメイン内の音声メッセージの非セッションベースのルーティングのための良い解決策だったが、それはボイスメールシステムとのリアルタイムの対話を可能にしませんでした。
Thus, a need has been identified for this voice messaging service type that would enable, for example, some of the use cases listed in this section.
したがって、必要性は、例えば、このセクションに記載されているユースケースの一部を可能にする、この音声メッセージングサービスタイプのために同定されています。
Video messaging systems, sometimes called visual voice messaging systems, are beginning to be used with real-time communication services. The need for a video messaging service type has become clear in order to provide certain applications with direct access to various video messaging services, most typically via the use of SIP. Thus, a need has been identified for this video messaging service type that would enable, for example, some of the use cases listed in this section.
時々、ビジュアルボイスメールシステムと呼ばれるビデオメッセージングシステムは、リアルタイム通信サービスで使用され始めています。ビデオメッセージングサービスの種類は、最も一般的にSIPを使用することにより、様々なビデオメッセージングサービスに直接アクセスして、特定のアプリケーションを提供するために明らかになったの必要性。したがって、必要性は、例えば、このセクションに記載されているユースケースの一部を可能にするこのビデオメッセージングサービスタイプのために同定されています。
Finally, several service providers and software developers have indicated that their system for voice messaging and video messaging either have been or soon will be unified into a single system. As such, they desired to have the option of using an Enumservice type that represents a subscriber's mailbox as being a so-called unified messaging repository. Thus, a need has been identified for this unified voice and video messaging service type that would enable, for example, some of the use cases listed in this section.
最後に、いくつかのサービスプロバイダやソフトウェア開発者は、音声メッセージングおよびビデオメッセージングのどちらかのために自分のシステムがされているか、すぐに単一のシステムに統合されることが示されています。そのため、彼らはいわゆるユニファイドメッセージングリポジトリとして加入者のメールボックスを表しEnumserviceタイプを使用するオプションを持っていることが望ましいです。したがって、必要性は、例えば、このセクションに記載されているユースケースの一部を可能にする、この統一された音声とビデオメッセージングサービスタイプのために同定されています。
The following is a partial, non-exclusive list of use cases that the vmsg Enumservice could address:
以下はVMSG Enumserviceが取り組むことができるとユースケースの部分的、非排他的なリストであります：
* A called party is busy or does not answer a call. A client or server then determines that a messaging service should be used and sends the calling party's session to such a service. The client or server needs to be able to determine which server to direct this real-time session to, whether that is within or outside of the called party's domain.
*被呼者が通話中またはコールに応答しません。クライアントまたはサーバは、メッセージングサービスを使用すべきであると判断し、そのようなサービスへの発呼者のセッションを送信します。クライアントまたはサーバは、それが内または被呼者のドメインの外にあるかどうか、このリアルタイムセッションを指示するためにサーバーを決定できるようにする必要があります。
* Similar to the above use case, a real-time session is attempted to a messaging system, but that system is currently unavailable. Since multiple service type records may be returned by the original ENUM query, the client or server could then attempt to initiate a session with one or more backup messaging servers in a manner that is transparent to the calling party and that supports better overall availability of a messaging service.
*上記のユースケースと同様に、リアルタイムのセッションは、メッセージングシステムにしようとしているが、そのシステムは現在使用できません。複数のサービスタイプのレコードは、元のENUMクエリーによって返されることがありますので、クライアントまたはサーバは、発信者に対して透過的な方法で1つ以上のバックアップメッセージングサーバーとのセッションを開始しようとする可能性があり、それがより良い全体の可用性をサポートしていますメッセージングサービス。
* Similar to the above use case, this service type could be used to balance load across multiple messaging servers, whether those are in the same or in different physical locations.
*上記のユースケースと同様に、このサービスタイプは、それらが同じまたは異なる物理的位置にあるかどうか、複数のメッセージングサーバー間で負荷を分散するために使用することができます。
* A user with an account on a messaging service needs to connect to the messaging service in order to retrieve messages. They initiate a real-time session, and an ENUM query is performed to discover the messaging server that holds its mailbox.
*メッセージングサービスのアカウントを持つユーザーは、メッセージを取得するために、メッセージングサービスに接続する必要があります。彼らは、リアルタイムセッションを開始し、ENUMクエリーは、そのメールボックスを保持しているメッセージングサーバーを検出するために行われます。
* In the process of invoking and supporting a real-time, automated and interactive session with a user, whether for message deposit or retrieval, VoiceXML files are referenced and utilized, via either HTTP or HTTPS. Multiple VoiceXML servers could be associated with a user and returned via ENUM query, for the purposes of load balancing, for example.
呼び出し、メッセージデポジットまたは検索のためかどうか、ユーザにリアルタイムで、自動化およびインタラクティブセッションをサポートする過程で、ボイスXMLファイルは、HTTPまたはHTTPSを介して、参照および利用されています*。複数のVoiceXMLサーバは、ユーザーに関連付けられており、例えば、負荷分散の目的で、ENUMクエリーを経由して返すことができます。
The authors considered whether this service type could simply use the SIP Enumservice type [19], but found that it does not satisfy their voice messaging requirements, particularly given the non-SIP URI sub-types specified herein. Even with sub-types for SIP URIs, however, there are challenges to using the SIP Enumservice type. For example, a request for access to such a service could be extended to the requesting SIP client, or User Agent Client (UAC), rather than relying upon the local policy of a SIP server, or User Agent Server (UAS), which means that special routing logic within a UAS cannot be relied upon to solve this problem. More importantly, however, the authors have found that without this service type, a UAC or UAS will be presented with multiple SIP URIs, with no ability other than in non-standards-based routing rules or application logic to recognize which one is related to a voice messaging, video messaging, or unified voice and video messaging service.
著者は、このサービスタイプは、単にSIP Enumserviceタイプ[19]を使用することができるかどうか考えられますが、それは特に、本明細書に指定された非SIP URIのサブタイプ与え、彼らのボイスメッセージの要件を満たしていないことがわかりました。 SIP URIのサブタイプで、しかし、SIP Enumserviceタイプを使用することに課題があります。例えば意味し、そのようなサービスへのアクセス要求は、要求元のSIPクライアントに拡張することができ、またはユーザエージェントクライアント（UAC）ではなく、SIPサーバのローカルポリシーに依存する、またはユーザエージェントサーバ（UAS） UAS内の特別なルーティングロジックは、この問題を解決するために依拠することはできません。より重要なことに、しかし、著者らは、このサービスタイプすることなく、UACまたはUASはに関連してどちら認識する非標準ベースのルーティングルールまたはアプリケーション・ロジック以外のない能力を有する、複数のSIP URIに提示されることを見出しましたボイスメッセージ、ビデオメッセージ、または統一された音声およびビデオメッセージングサービス。
The authors believe that it is more likely that these records will be distributed on a purely private basis, but they may also be distributed in public ENUM trees. Distribution of this NAPTR data could be either (a) on a private basis within a service provider's internal network, (b) on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access, or (c) openly available.
著者は、これらのレコードは、純粋に民間ベースで配布されますが、彼らはまた、公共のENUMツリーに分散することができる可能性が高くなると考えています。このNAPTRデータの分布は、（b）一般公衆のアクセス、または（c）を禁止するセキュリティ・メカニズムの様々なを使用して、1つのまたは複数の当事者間のプライベート基づいて、サービスプロバイダの内部ネットワーク内の（a）は、民間ベースでのいずれかであります公然と利用できます。
DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining voicemsg Enumservice data, this information would be visible to anyone anonymously. While this is not qualitatively different from publication in a Telephone Directory, it does open or ease access to such data without any indication that such data has been accessed or by whom it has been accessed.
DNSは、ENUMで使用されるように、グローバルな分散データベースです。この仕様の利用e164.arpaまたはEnumserviceデータをvoicemsg維持するためのツリーとして他の公に利用可能なドメインの実装者は、この情報は匿名で誰にでも見えるだろう必要があります。これは電話帳で出版質的に異なるものではないが、それは開いていたり、そのようなデータがアクセスされたか、誰によってそれがアクセスされたこと兆候なしに、そのようなデータへのアクセスを容易にします。
Such data harvesting by third parties is often used to generate lists of targets for unsolicited information. Thus, a third party could use this to generate a list that it can use to make unsolicited telemarketing phone calls, or so-called SPAM over Internet Telephony (SPIT). Many countries have do-not-call registries or other legal or regulatory mechanisms in place to deal with such abuses.
第三者によるこのようなデータの収穫は、多くの場合、迷惑情報のターゲットのリストを生成するために使用されます。したがって、第三者はそれが迷惑テレマーケティング電話、またはインターネットテレフォニー（SPIT）を超える、いわゆるSPAMを作るために使用できるリストを生成するためにこれを使用することができます。多くの国は、このような人権侵害に対処するための場所で行う-ないコールレジストリまたは他の法的または規制機構を有しています。
As noted earlier, carriers, service providers, and other users may simply choose not to publish such information in the public e164.arpa tree, but may instead simply publish this in their internal ENUM routing database that is only able to be queried by trusted elements of their network and/or partner networks, such as softswitches and SIP proxy servers. They may also choose to publish such information in a carrier-only branch of the e164.arpa tree, should one be created.
先に述べたように、キャリア、サービスプロバイダ、および他のユーザーは単に公共e164.arpaツリーで、このような情報を公開しないことも選択できますが、その代わりに、単純に、信頼できる要素によって照会することができるだけで、内部のENUMのルーティングデータベースでこれを公開すること彼らのネットワークおよび/または、そのようなソフトスイッチやSIPプロキシサーバなどのパートナーネットワークの。彼らはまた、1を作成する必要があり、e164.arpa木のキャリアのみの枝に、そのような情報を公開することもできます。
Although an E.164 telephone number does not appear to reveal as much identity information about a user as a name in the format sip:username@hostname or email:username@hostname, the information is still publicly available; thus, there is still the risk of unwanted communication.
ユーザ名@ホスト名または電子メール：：E.164電話番号の形式は、SIPに名前としてユーザーに関する限り多くのアイデンティティ情報を明らかにすることは表示されませんが、ユーザ名@ホスト名、情報はまだ公開されています。このように、不要な通信の危険性が依然としてあります。
An analysis of threats specific to the dependence of ENUM on the DNS and the applicability of DNSSEC [16] to this is provided in RFC 3761 [1]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [17].
DNSにENUMの依存とDNSSECこれに[16]の適用に特定の脅威の分析は、RFC 3761に設けられている[1]。 DNS自体への脅威の徹底的な分析は、RFC 3833 [17]で覆われています。
Enumservice Name: "voicemsg"
Enumservice名： "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceタイプ： "voicemsg"
Enumservice Subtypes: "sip"
Enumserviceサブタイプ： "SIP"
URI Schemes: 'sip:'
URIスキーム： 'SIP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、識別されたリモートリソースがボイスメッセージシステムへの音声通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "voicemsg"
Enumservice名： "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceタイプ： "voicemsg"
Enumservice Subtypes: "sips"
Enumserviceサブタイプ：「一口」
URI Schemes: 'sips:'
URIスキーム： '一口：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、識別されたリモートリソースがボイスメッセージシステムへの音声通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "voicemsg"
Enumservice名： "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceタイプ： "voicemsg"
Enumservice Subtype: "tel"
Enumserviceサブタイプ： "TEL"
URI Schemes: 'tel:'
URIスキーム： 'TEL'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system.
このEnumserviceは、識別されたリモートリソースがボイスメッセージシステムへの音声通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "voicemsg"
Enumservice名： "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceタイプ： "voicemsg"
Enumservice Subtype: "http"
Enumserviceサブタイプ： "HTTP"
URI Schemes: 'http:'
URIスキーム： 'HTTP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触させることを「のhttp：」[11] URIは、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいは音声メッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "voicemsg"
Enumservice名： "voicemsg"
Enumservice Type: "voicemsg"
Enumserviceタイプ： "voicemsg"
Enumservice Subtype: "https"
Enumserviceサブタイプ： "https" の
URI Schemes: 'https:'
URIスキーム： 'HTTPS：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、TLSまたはセキュアソケットレイヤプロトコルを使用して接触させることができる情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触「HTTPS」[12] URIは、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいは音声メッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "videomsg"
Enumservice名： "videomsg"
Enumservice Type: "videomsg"
Enumserviceの種類： "videomsg"
Enumservice Subtypes: "sip"
Enumserviceサブタイプ： "SIP"
URI Schemes: 'sip:'
URIスキーム： 'SIP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system.
このEnumserviceは、識別されたリモートリソースは、ビデオメッセージングシステムへのビデオ通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "videomsg"
Enumservice名： "videomsg"
Enumservice Type: "videomsg"
Enumserviceの種類： "videomsg"
Enumservice Subtypes: "sips"
Enumserviceサブタイプ：「一口」
URI Schemes: 'sips:'
URIスキーム： '一口：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system.
このEnumserviceは、識別されたリモートリソースは、ビデオメッセージングシステムへのビデオ通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "videomsg"
Enumservice名： "videomsg"
Enumservice Type: "videomsg"
Enumserviceの種類： "videomsg"
Enumservice Subtype: "http"
Enumserviceサブタイプ： "HTTP"
URI Schemes: 'http:'
URIスキーム： 'HTTP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触させることを「のhttp：」[11] URIは、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "videomsg"
Enumservice名： "videomsg"
Enumservice Type: "videomsg"
Enumserviceの種類： "videomsg"
Enumservice Subtype: "https"
Enumserviceサブタイプ： "https" の
URI Schemes: 'https:'
URIスキーム： 'HTTPS：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、TLSまたはセキュアソケットレイヤプロトコルを使用して接触させることができる情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触「HTTPS」[12] URIは、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "unifmsg"
Enumservice名： "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceタイプ： "unifmsg"
Enumservice Subtypes: "sip"
Enumserviceサブタイプ： "SIP"
URI Schemes: 'sip:'
URIスキーム： 'SIP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system.
このEnumserviceは、識別されたリモートリソースがユニファイドメッセージングシステムへの統一された通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "unifmsg"
Enumservice名： "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceタイプ： "unifmsg"
Enumservice Subtypes: "sips"
Enumserviceサブタイプ：「一口」
URI Schemes: 'sips:'
URIスキーム： '一口：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system.
このEnumserviceは、識別されたリモートリソースがユニファイドメッセージングシステムへの統一された通信セッションを開始するために関連したURIスキームによって対処することができることを示しています。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "unifmsg"
Enumservice名： "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceタイプ： "unifmsg"
Enumservice Subtype: "http"
Enumserviceサブタイプ： "HTTP"
URI Schemes: 'http:'
URIスキーム： 'HTTP：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触させることを「のhttp：」[11] URIは、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
Enumservice Name: "unifmsg"
Enumservice名： "unifmsg"
Enumservice Type: "unifmsg"
Enumserviceタイプ： "unifmsg"
Enumservice Subtype: "https"
Enumserviceサブタイプ： "https" の
URI Schemes: 'https:'
URIスキーム： 'HTTPS：'
Functional Specification:
機能仕様：
This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol.
このEnumserviceは、関連付けられたURIスキームによって識別されたリモートリソースは、TLSまたはセキュアソケットレイヤプロトコルを使用して接触させることができる情報のソースであることが可能であることを示しています。
Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource.
取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触「HTTPS」[12] URIは、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。
Security Considerations: See Section 3.
セキュリティに関する注意事項：第3節を参照してください。
Intended Usage: COMMON
意図した使用法：COMMON
Authors:
著者：
Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)
ジェイソンLivingood（jason_livingood@cable.comcast.com）ドンTroshynski（dtroshynski@acmepacket.com）
Any other information the author deems interesting:
著者は面白いと考えるその他の情報：
Implementers should review a non-exclusive list of examples below in Section 7.
実装者は、第7節では、以下の例の非排他的なリストを確認してください。
The following sub-sections document several examples that implementers may find informative. These examples shall in no way limit the various forms that this Enumservice may take.
以下のサブセクションでは、実装者が有益かもしれないいくつかの例を文書化します。これらの例は決してこのEnumserviceがかかる場合があり様々な形態を制限するものとします。
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:12155550123@gw.example.com!".
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party.
この例では、発呼者は、一定期間後に未回答しまったセッションを試みてきました。発呼者のセッションは、パーソナライズされた挨拶文は、それが呼ばれるパーティへの音声メッセージを録音した後、発呼者に再生され、適切な音声メッセージングサーバーに送信されます。
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:tel"
"!^.*$!tel:1-215-555-0123!".
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party.
この例では、発呼者は、一定期間後に未回答しまったセッションを試みてきました。発呼者のセッションは、パーソナライズされた挨拶文は、それが呼ばれるパーティへの音声メッセージを録音した後、発呼者に再生され、適切な音声メッセージングサーバーに送信されます。
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!(^.*)$!sip:\1@example.net!".
In this example, a backreference is used to reduce the size of the NAPTR record. The sip URI uses "\1", which would dynamically replace the expression with the TN, in this case +12155550123.
この例では、後方参照は、NAPTRレコードのサイズを減少させるために使用されます。 SIP URIは、動的にこの場合は12155550123には、TNとの表現に代わる「\ 1」を、使用しています。
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+voicemsg:sip"
"!^.*$!sip:johndoe@gw.example.com!".
In this example, a calling party has attempted a session that has gone unanswered after a certain period of time. The calling party's session is sent to the appropriate voice messaging server, a personalized greeting is played to the calling party, after which it records a voice message to the called party. The URI that this session is directed to does not include a telephone number, as this user has multiple service that are not particularly tied to telephone numbers whereby text, audio, video and other multimedia messages can be received and accessed.
この例では、発呼者は、一定期間後に未回答しまったセッションを試みてきました。発呼者のセッションは、パーソナライズされた挨拶文は、それが呼ばれるパーティへの音声メッセージを録音した後、発呼者に再生され、適切な音声メッセージングサーバーに送信されます。 URIこのセッションは、このユーザは、テキスト、オーディオ、ビデオ及び他のマルチメディアメッセージが受信され、アクセスすることができる、特に電話番号に関連付けられていない複数のサービスを有するように、電話番号が含まれていないように指示されていること。
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+videomsg:sip"
"!^.*$!sip:12155550123@gw1.example.com!".
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 200 "u" "E2U+videomsg:sip" "!^.*$!sip:12155550123@gw2.example.com!".
$ ORIGINの3.2.1.0.5.5.5.5.1.2.1.e164.arpa。 NAPTR 10 200 "U" "E2U + videomsg：一口" "！。！^ * $一口：12155550123@gw2.example.com！"。
In this example, the preference indicates that gw1.example.com is used first (100), and if this is unreachable, then the next higher preference (200) is used and gw2.example.com is contacted. While out of scope for this document, a service provider could thus mirror or cluster a message store and fail from the primary to secondary using the DNS in an active-standby mode.
この例では、選好はgw1.example.com最初（100）が使用されていることを示し、これは到達不能である場合には、次に高い優先（200）が使用され、gw2.example.comを接触させます。この文書の範囲外ながら、サービスプロバイダは、このようにミラーやメッセージストアをクラスタ化し、アクティブ・スタンバイ・モードでDNSを使用して二次側に一次から失敗する可能性があります。
It is likely that both E2U+sip and E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will be returned for a given query. In this case, this could result in what is essentially E2U+sip records for real-time communications with an end user, while, for example, the E2U+voicemsg records will be used for real-time communications with a voice messaging service, when the called party is not available or does not wish to be disturbed. Therefore, the network element that receives the results of this ENUM query will need to know enough information in order to select the voicemsg service type, rather than the sip service type.
E2U +一口とE2U + voicemsg、E2U + videomsg、および/またはE2U + unifmsg Enumserviceタイプのレコードの両方が与えられたクエリに対して返される可能性が高いです。例えば、E2U + voicemsgレコードが音声メッセージングサービスとのリアルタイム通信のために使用され、一方で、基本的にエンドユーザーとのリアルタイム通信のためのE2U +一口レコードです何この場合、これはにつながる可能性被呼者が利用できないか、邪魔されたくありません。したがって、このENUMクエリーの結果を受け、ネットワーク要素はvoicemsgサービスタイプではなく、SIPサービスの種類を選択するために十分な情報を知っておく必要があります。
In addition, it is likely that multiple E2U+voicemsg, E2U+videomsg, and/or E2U+unifmsg Enumservice type records will be returned for a given query. In this case, multiple records may include order and preference to allow recursion or load balancing. Order could be used to designate a primary and a backup voice, video, or unified voice and video messaging service. Preference could be used to load balance across multiple voice, video, and/or unified voice and video messaging servers by weight, for example.
また、特定のクエリに対して返される複数のE2U + voicemsg、E2U + videomsg、および/またはE2U + unifmsg Enumserviceタイプのレコード可能性があります。この場合、複数のレコードは、再帰またはロードバランシングを可能にするため、およびプリファレンスを含むことができます。ご注文は、プライマリおよびバックアップの音声、ビデオ、または統一された音声およびビデオメッセージングサービスを指定するために使用することができます。好ましくは、例えば、重量で複数の音声、ビデオ、および/または統一音声とビデオメッセージングサーバー間で負荷を分散するために使用することができます。
Finally, as with multiple records resulting from a typical ENUM query of the e164.arpa tree, it is up to the application using an ENUM resolver to determine which record(s) to use and which record(s) to ignore. Implementers should take this into consideration and build logic into their applications that can select appropriately from multiple records based on business, network, or other rules.
最後に、e164.arpa木の典型的なENUM照会から得られた複数のレコードと同様に、それがどのレコード（複数可）を無視するために使用して、レコード（複数可）にを決定するためにENUMリゾルバを使用して、アプリケーション次第です。実装者はこのことを考慮し、ビジネス、ネットワーク、または他のルールに基づいて、複数のレコードの中から適宜選択することができ、そのアプリケーションにロジックを構築する必要があります。
Implementers may wish to consider using regular expressions in order to reduce the size of individual NAPTRs. This will have a significant effect on the overall size of the database involved.
実装者は、個々のNAPTRsのサイズを小さくするために、正規表現を使用することを検討することを望むかもしれません。これは、関係するデータベースの全体的な大きさに大きな影響を持つことになります。
This document registers the 'voicemsg' Enumservice type and the subtype "tel", "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 4 of this document.
この登録のRFC 3761詳細にIANA問題で説明Enumserviceレジストリの下でこのドキュメント「voicemsg」Enumserviceタイプとサブタイプ「TEL」、「SIP」を登録、「すする」、「HTTP」、および「HTTPS」はありますこのドキュメントのセクション4に設けられました。
This document registers the 'videomsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 5 of this document.
この文書では、この登録の3761詳細は第5節で提供されているRFCでIANA問題で説明Enumserviceレジストリの下で、「HTTP」、および「https」の「videomsg」Enumserviceタイプとサブタイプ「一口」、「SIPS」を登録しますこのドキュメントの。
This document registers the 'unifmsg' Enumservice type and the subtype "sip", "sips", "http", and "https" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 6 of this document.
この文書では、この登録の3761詳細はセクション6で提供されているRFCでIANA問題で説明Enumserviceレジストリの下で、「HTTP」、および「https」の「unifmsg」Enumserviceタイプとサブタイプ「一口」、「SIPS」を登録しますこのドキュメントの。
The authors thank Rich Ferrise, Chris Harvey, Tong Zhou, and Hadriel Kaplan for their detailed assistance in developing the ideas behind this document in numerous brainstorming sessions, with information gleaned from their work to solve real application architecture issues. The authors also thank Lawrence Conroy and Jean-Francois Mule for their feedback in developing this document.
著者は、実際のアプリケーションアーキテクチャの問題を解決するために彼らの仕事から収集された情報で、数多くのブレーンストーミングセッションで、この文書の背後にあるアイデアを開発する上でその詳細な支援のためにリッチFerrise、クリス・ハーヴェイ、トング周、およびHadrielカプランに感謝します。著者らはまた、この文書の開発に彼らのフィードバックのためにローレンス・コンロイ、ジャン・フランソワ・ミュールに感謝します。
Tong Zhou Comcast Cable Communications Email: tong_zhou@cable.comcast.com
トング周ComcastのケーブルコミュニケーションズEメール：tong_zhou@cable.comcast.com
Richard Ferrise Comcast Cable Communications Email: rich_ferrise@cable.comcast.com
リチャードFerrise ComcastのケーブルコミュニケーションズEメール：rich_ferrise@cable.comcast.com
Chris Harvey Comcast Cable Communications Email: chris_harvey@cable.comcast.com
クリス・ハーヴェイComcastのケーブルコミュニケーションズEメール：chris_harvey@cable.comcast.com
Hadriel Kaplan Acme Packet Email: hkaplan@acmepacket.com
HadrielカプランアクメパケットEメール：hkaplan@acmepacket.com
[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.及びM. Mealling、 "ユニフォームリソース識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、RFC 3761、2004年4月。
[2] ITU-T, "The International Public Telecommunication Numbering Plan", Recommendation E.164, May 1997.
[2] ITU-T、 "国際公共電気通信番号計画"、勧告E.164を、1997年5月。
[3] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[3] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、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.、 "ダイナミックな委譲発見システム（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.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[6] Mealling、M.、 "ダイナミックな委譲発見システム（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）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
[8] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、BCP 65、RFC 3405、2002年10月。
[9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[9] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月に。
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[10]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[11]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[13] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[13]ピーターソン、J.、劉、H.、ユー、J.、およびB.キャンベル、RFC 3824、2004年6月 "セッション開始プロトコル（SIP）とE.164番号を使用します"。
[14] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
ヴォードルイユ、G.、 "ボイスメッセージルーティング・サービス"、RFC 4238、2005年10月[14]。
[15] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservices email, fax, mms, ems, and sms", RFC 4355, January 2006.
[15] Brandner、R.、コンロイ、L.、およびR. Stastny、 "Enumservices電子メール、ファックス、MMS、EMS、およびSMSのためのIANA登録"、RFC 4355、2006年1月。
[16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[16]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[17] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[17]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[18] Foster, M., McGarry, T., and J. Yu, "Number Portability in the Global Switched Telephone Network (GSTN): An Overview", RFC 3482, February 2003.
、RFC 3482、2003年2月[18]フォスター、M.、マクギャリー、T.、およびJ.優、 "概要番号ポータビリティは、グローバルに電話網（GSTN）をスイッチ"。
[19] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[19]ピーターソン、J.、 "セッション開始プロトコルのためenumservice登録（SIP）アドレス・オブ・レコード"、RFC 3764、2004年4月。
Authors' Addresses
著者のアドレス
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA EMail: jason_livingood@cable.comcast.com
ジェイソンLivingood Comcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103 USA電子メール：jason_livingood@cable.comcast.com
Donald Troshynski Acme Packet EMail: dtroshynski@acmepacket.com
ドナルドTroshynskiアクメパケットEメール：dtroshynski@acmepacket.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。