[要約] RFC 5278は、音声およびビデオメッセージングのためのEnumサービスのIANA登録に関するものです。このRFCの目的は、Enumサービスの一貫性と管理を確保することです。

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

音声およびビデオメッセージングのためのEnumservicesの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)の現在のエディションを参照してください。このメモの配布は無制限です。

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.

このドキュメントでは、「VMSG」という名前のEnumserviceを登録します。これは、音声、ビデオ、統一された通信のリアルタイムルーティングをメッセージングシステムに促進するために使用されます。このVMSG Enumserviceは、 "Voicemsg"、 "VideoMsg"、および「unifmsg」の3つのEnumserviceタイプを登録します。また、各タイプは、「voicemsg」タイプのサブタイプ「sip」、「sips」、「http」、および「https」、および「https」、および「https」を登録します。

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
        
1. Introduction
1. はじめに

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 Number Mapping、RFC 3761 [1])は、E.164番号(国際的な電気通信番号計画、ITU-T推奨e.164 [2])をドメイン名に変換し、DNSを使用するテクノロジーです(DNS(ドメイン名システム、RFC 1034 [3])NSレコードおよび命名権限ポインター(NAPTR)レコード(Dynamic Deligation Discovery System(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]リソースレコードのサービスフィールドでのプロビジョニングに使用されるRFC 3761 [1]に記載されているガイドラインに従って、エンクスサービスを登録して、エンドポイントおよび/または電話番号に関連する機能の種類を示します。登録は、DDDS(動的委任ディスカバリーシステム[4] [5] [6] [7] [8])階層内で定義され、RFC 3761で定義された「E2U」DDDSアプリケーションで使用します。

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.

Visual Voiceメッセージングシステムと呼ばれることもあるビデオメッセージングシステムは、リアルタイム通信サービスで使用され始めています。ビデオメッセージングサービスタイプの必要性は、さまざまなビデオメッセージングサービスに直接アクセスできる特定のアプリケーションを提供するために明らかになりました。これは、通常は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.

最後に、いくつかのサービスプロバイダーとソフトウェア開発者は、音声メッセージとビデオメッセージングのシステムが単一のシステムに統合されたか、間もなく統一されることを示しています。そのため、彼らは、サブスクライバーのメールボックスをいわゆる統一メッセージリポジトリとして表すencrumserviceタイプを使用するオプションを持っていることを望んでいました。したがって、たとえば、このセクションにリストされているユースケースの一部を有効にするこの統一された音声およびビデオメッセージングサービスタイプのニーズが特定されています。

1.1. Selected Use Cases for Illustrative Purposes
1.1. 例示的な目的のために選択されたユースケース

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.

* メッセージデポジットであろうと検索の場合でも、ユーザーとのリアルタイムで自動化されたインタラクティブセッションを呼び出してサポートするプロセスでは、httpまたはhttpsを介してvoicexmlファイルが参照および利用されます。たとえば、ロードバランシングの目的で、複数のVoiceXMLサーバーをユーザーに関連付けて、列挙クエリを介して返品することができます。

1.2. Consideration of Other Existing Enumservices
1.2. 他の既存のenyservicesの検討

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サーバーまたはユーザーエージェントサーバー(UAS)のローカルポリシーに依存するのではなく、要求のSIPクライアント、またはユーザーエージェントクライアント(UAC)に拡張できます。この問題を解決するために、UAS内の特別なルーティングロジックを依存することはできません。しかし、さらに重要なことに、著者は、このサービスタイプがなければ、UACまたはUASに複数のSIP URIが提示されることを発見しました。音声メッセージング、ビデオメッセージング、または統一された音声およびビデオメッセージングサービス。

2. Distribution of Data
2. データの分布

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.

著者は、これらの記録が純粋にプライベートに分配される可能性が高いと考えていますが、公共の列挙木に分配される可能性もあります。このNAPTRデータの分布は、(a)サービスプロバイダーの内部ネットワーク内のプライベートベースで、(b)さまざまなセキュリティメカニズムを使用して一般的なパブリックアクセスを禁止する1つまたは複数の当事者間のプライベートベースで、または(c)のいずれかです。公然と利用可能。

3. Security Considerations
3. セキュリティに関する考慮事項

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.

enumで使用されるDNSは、グローバルな分散データベースです。この仕様の実装者がe164.ARPAまたはその他の公開ドメインを使用して、VoiceMSG Enumserviceデータを維持するためのツリーとして使用する場合、この情報は匿名で誰にでも表示されます。これは電話ディレクトリに公開されることと定性的に違いはありませんが、そのようなデータがアクセスされたり、誰がアクセスしたかを示すことなく、そのようなデータへのアクセスを開いたり容易にしたりします。

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.

サードパーティによるこのようなデータ収穫は、しばしば未承諾情報のターゲットのリストを生成するために使用されます。したがって、サードパーティはこれを使用して、未承諾のテレマーケティングの電話をかけるために使用できるリストを生成することができます。多くの国では、そのような虐待に対処するために、継続的なレジストリまたはその他の法的または規制のメカニズムがあります。

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プロキシサーバーなどのネットワークおよび/またはパートナーネットワークの。また、そのような情報を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:username@hostnameまたはemail:username@hostnameの名前としてユーザーに関する多くの身元情報を明らかにしていないようですが、情報はまだ公開されています。したがって、不要なコミュニケーションのリスクがまだあります。

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への酵素の依存性とDNSSECの適用可能性[16]に固有の脅威の分析は、RFC 3761 [1]で提供されています。DNS自体に対する脅威の徹底的な分析は、RFC 3833でカバーされています[17]。

4. ENUM Service Registration for voicemsg
4. voicemsgの列挙サービス登録
4.1. Registration for "voicemsg" with Subtype "sip"
4.1. サブタイプ「SIP」を備えた「voicemsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Any other information the author deems interesting:

Jason Livingood(jason_livingood@cable.comcast.com)don troshynski(dtroshynski@acmepacket.com)著者が興味深いと思うその他の情報:

Implementers should review a non-exclusive list of examples below in Section 7.

実装者は、セクション7で以下の例の非独占的なリストを確認する必要があります。

4.2. Registration for "voicemsg" with Subtype "sips"
4.2. サブタイプの「SIPS」を備えた「voicemsg」の登録

Enumservice Name: "voicemsg"

Enumservice名:「Voicemsg」

Enumservice Type: "voicemsg"

Enumserviceタイプ:「Voicemsg」

Enumservice Subtypes: "sips"

Enumserviceサブタイプ:「SIPS」

URI Schemes: 'sips:'

URIスキーム:「SIPS: '

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

4.3. Registration for "voicemsg" with Subtype "tel"
4.3. サブタイプ「Tel」を使用した「Voicemsg」の登録

Enumservice Name: "voicemsg"

Enumservice名:「Voicemsg」

Enumservice Type: "voicemsg"

Enumserviceタイプ:「Voicemsg」

Enumservice Subtype: "tel"

Enumserviceサブタイプ: "Tel"

URI Schemes: 'tel:' Functional Specification:

URIスキーム: 'Tel:'機能仕様:

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

4.4. Registration for "voicemsg" with Subtype "http"
4.4. サブタイプの「http」を備えた「voicemsg」の登録

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 Authors:

意図された使用法:一般的な著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

4.5. Registration for "voicemsg" with Subtype "https"
4.5. サブタイプの「https」を備えた「voicemsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

5. ENUM Service Registration for videomsg
5. Videomgの列挙サービス登録
5.1. Registration for "videomsg" with Subtype "sip"
5.1. サブタイプ「SIP」を備えた「Videomsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

5.2. Registration for "videomsg" with Subtype "sips"
5.2. サブタイプの「SIPS」を備えた「Videomsg」の登録

Enumservice Name: "videomsg"

Enumservice名:「Videomsg」

Enumservice Type: "videomsg"

Enumserviceタイプ:「Videomsg」

Enumservice Subtypes: "sips"

Enumserviceサブタイプ:「SIPS」

URI Schemes: 'sips:'

URIスキーム:「SIPS: '

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

5.3. Registration for "videomsg" with Subtype "http"
5.3. サブタイプの「http」を備えた「videomsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Any other information the author deems interesting:

Jason Livingood(jason_livingood@cable.comcast.com)don troshynski(dtroshynski@acmepacket.com)著者が興味深いと思うその他の情報:

Implementers should review a non-exclusive list of examples below in Section 7.

実装者は、セクション7で以下の例の非独占的なリストを確認する必要があります。

5.4. Registration for "videomsg" with Subtype "https"
5.4. サブタイプ「HTTPS」を備えた「VideoMsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

6. ENUM Service Registration for unifmsg
6. UNIFMSGの列挙サービス登録
6.1. Registration for "unifmsg" with Subtype "sip"
6.1. サブタイプの「SIP」を使用した「UNIFMSG」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

6.2. Registration for "unifmsg" with Subtype "sips"
6.2. サブタイプの「SIPS」を使用した「UNIFMSG」の登録

Enumservice Name: "unifmsg"

Enumservice名:「unifmsg」

Enumservice Type: "unifmsg"

Enumserviceタイプ:「unifmsg」

Enumservice Subtypes: "sips"

Enumserviceサブタイプ:「SIPS」

URI Schemes: 'sips:'

URIスキーム:「SIPS: '

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

6.3. Registration for "unifmsg" with Subtype "http"
6.3. サブタイプ「HTTP」を使用した「UNIFMSG」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Any other information the author deems interesting:

Jason Livingood(jason_livingood@cable.comcast.com)don troshynski(dtroshynski@acmepacket.com)著者が興味深いと思うその他の情報:

Implementers should review a non-exclusive list of examples below in Section 7.

実装者は、セクション7で以下の例の非独占的なリストを確認する必要があります。

6.4. Registration for "unifmsg" with Subtype "https"
6.4. サブタイプの「https」を備えた「unifmsg」の登録

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

意図された使用法:共通

Authors:

著者:

Jason Livingood (jason_livingood@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com)

Jason Livingood(jason_livingood@cable.comcast.com)don 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で以下の例の非独占的なリストを確認する必要があります。

7. Selected Examples for Illustrative Purposes
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が取る可能性のあるさまざまな形式を決して制限しません。

7.1. Example Using a 'sip' URI
7.1. 「sip」uriを使用した例

$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!".

$ origin 3.2.1.0.5.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.

この例では、呼び出し当事者は、一定の期間後に答えられなかったセッションを試みました。呼び出し政党のセッションは、適切な音声メッセージングサーバーに送信されます。パーソナライズされた挨拶が呼び出しパーティーに再生され、その後、呼び出されたパーティーに音声メッセージを記録します。

7.2. Example Using a 'tel' URI
7.2. 「Tel」URIを使用した例

$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!".

$ origin 3.2.1.0.5.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.

この例では、呼び出し当事者は、一定の期間後に答えられなかったセッションを試みました。呼び出し政党のセッションは、適切な音声メッセージングサーバーに送信されます。パーソナライズされた挨拶が呼び出しパーティーに再生され、その後、呼び出されたパーティーに音声メッセージを記録します。

7.3. Example Using a Backreference
7.3. 例を使用した例

$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!".

$ origin 3.2.1.0.5.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は「\ 1」を使用します。これは、式をTN(この場合は12155550123)に動的に置き換えます。

7.4. Example Using a 'sip' URI without a Telephone Number
7.4. 電話番号なしで「sip」uriを使用した例

$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!".

$ origin 3.2.1.0.5.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には、電話番号が含まれていません。このユーザーには、テキスト、オーディオ、ビデオ、その他のマルチメディアメッセージにアクセスできる電話番号に特に結び付けられていない複数のサービスがあるためです。

7.5. Example of Failover Using E2U+videomsg:sip
7.5. E2Uビデオを使用したフェールオーバーの例:SIP

$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.5.1.2.1.e164.arpa。naptr 10 100 "u" "e2u videomg: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.5.1.2.1.e164.arpa。Naptr 10 200 "u" "e2u videomg:sip" "!^。*$!sip: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を使用してプライマリからセカンダリに失敗する可能性があります。

8. Implementation Recommendations
8. 実装の推奨事項
8.1. Call Processing When Multiple Records Are Returned
8.1. 複数のレコードが返されたときのコール処理

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 SIPおよびE2U Voicemsg、E2U Videomg、および/またはE2U UnifmsG Enumserviceタイプレコードの両方が、特定のクエリに対して返される可能性があります。この場合、これにより、エンドユーザーとのリアルタイム通信のための本質的にE2U SIPレコードが生じる可能性がありますが、たとえば、E2U VoiceMSGレコードは、呼び出されたときに音声メッセージングサービスとのリアルタイム通信に使用されます。パーティーは利用できないか、邪魔されることを望んでいません。したがって、この列挙クエリの結果を受信するネットワーク要素は、SIPサービスタイプではなく、Voicemsgサービスタイプを選択するために十分な情報を知る必要があります。

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 Videomg、および/または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ツリーの典型的な列挙クエリに起因する複数のレコードと同様に、使用するレコードと無視するレコードを決定するために、列挙リゾルバーを使用してアプリケーション次第です。実装者は、これを考慮に入れて、ビジネス、ネットワーク、またはその他のルールに基づいて複数のレコードから適切に選択できるアプリケーションにロジックを構築する必要があります。

8.2. NAPTR Configuration Issues
8.2. NAPTR構成の問題

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.

実装者は、個々のNAPTRのサイズを縮小するために、正規表現の使用を検討することをお勧めします。これは、関係するデータベースの全体的なサイズに大きな影響を与えます。

9. IANA Considerations
9. IANAの考慮事項

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.

このドキュメントは、「Voicemsg」enumserviceタイプとサブタイプ「Tel」、「SIP」、「SIP」、「HTTP」、および「HTTPS」をRFC 3761のIANAに関する考慮事項で説明したencerviceレジストリの下で登録します。この登録の詳細は、このドキュメントのセクション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.

このドキュメントは、RFC 3761のIANAに関する考慮事項で説明されているEnumserviceレジストリの下で、「VideoMsg」Enumserviceタイプとサブタイプの「SIP」、「SIP」、「HTTP」、および「HTTPS」を登録します。この登録の詳細は、セクション5に記載されています。このドキュメントの。

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.

このドキュメントは、RFC 3761のIANAに関する考慮事項で説明されているEnumserviceレジストリの下で、「Unifmsg」enumserviceタイプとサブタイプ「SIP」、「SIPS」、「HTTP」、および「HTTPS」を登録します。この登録の詳細は、セクション6に記載されています。このドキュメントの。

10. Acknowledgements
10. 謝辞

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.

著者は、リッチ・フェリス、クリス・ハーベイ、トン・Zhou、およびハドリエル・カプランに感謝し、この文書の背後にあるアイデアを多くのブレーンストーミングセッションで開発し、実際のアプリケーションアーキテクチャの問題を解決するために作業から収集されました。著者はまた、ローレンス・コンロイとジャン・フランソワ・ラバに、この文書を開発する際のフィードバックに感謝します。

11. Contributors
11. 貢献者

Tong Zhou Comcast Cable Communications Email: tong_zhou@cable.comcast.com

Tong Zhou Comcast Cable Communications Email:tong_zhou@cable.comcast.com

Richard Ferrise Comcast Cable Communications Email: rich_ferrise@cable.comcast.com

Richard Ferrise Comcast Cable Communicationsメール:rich_ferrise@cable.comcast.com

Chris Harvey Comcast Cable Communications Email: chris_harvey@cable.comcast.com

Chris Harvey Comcast Cable Communications Email:chris_harvey@cable.comcast.com

Hadriel Kaplan Acme Packet Email: hkaplan@acmepacket.com

Hadriel Kaplan ACMEパケットメール:hkaplan@acmepacket.com

12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

[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 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。、「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", BCP 65, RFC 3405, October 2002.

[8] Mealling、M。、「動的委任発見システム(DDDS)パート5: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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP:SESSION INTIATION Protocol"、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。

[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[12] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。

12.2. Informative References
12.2. 参考引用

[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] Peterson、J.、Liu、H.、Yu、J。、およびB. Campbell、「セッション開始プロトコル(SIP)でE.164番号を使用」、RFC 3824、2004年6月。

[14] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.

[14] Vaudreuil、G。、「音声メッセージルーティングサービス」、RFC 4238、2005年10月。

[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.、Conroy、L。、およびR. Stastny、「Enumservices Email、Fax、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。

[17] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[17] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析(DNS)」、RFC 3833、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.

[18] Foster、M.、McGarry、T。、およびJ. Yu、「グローバルスイッチド電話ネットワーク(GSTN)における数の移植性:概要」、RFC 3482、2003年2月。

[19] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.

[19] Peterson、J。、「セッション開始プロトコル(SIP)アドレスの録音のためのEnumservice登録」、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

Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 USAメール:jason_livingood@cable.comcast.com

Donald Troshynski Acme Packet EMail: dtroshynski@acmepacket.com

Donald Troshynski ACMEパケットメール:dtroshynski@acmepacket.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(c)The IETF Trust(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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織(もしあれば)、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

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への情報をお問い合わせください。