RFC 3953 - Telephone Number Mapping (ENUM) Service Registration for Presence Services 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3953
タイトル : RFC 3953 - プレゼンスサービスの電話番号マッピング (ENUM) サービス登録
翻訳編集 : 自動生成

[要約] RFC 3953は、PresenceサービスのためのENUM（電話番号マッピング）サービスの登録に関する規格です。その目的は、電話番号とプレゼンスサービスの関連付けを可能にし、通信ネットワーク上でのプレゼンス情報の共有を促進することです。

Network Working Group                                        J. Peterson
Request for Comments: 3953                                       NeuStar
Category: Standards Track                                   January 2005

Telephone Number Mapping (ENUM) Service Registration for Presence Services

プレゼンスサービスの電話番号マッピング (ENUM) サービス登録

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) を参照してください。このメモの配布は無制限です。

著作権表示

著作権 (C) インターネット協会 (2005)。

Abstract

概要

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM.

このドキュメントでは、プレゼンス用の電話番号マッピング (ENUM) サービスを登録します。特に、このドキュメントは ENUM での pres URI のプロビジョニングに焦点を当てています。

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. ENUM Service Registration  . . . . . . . . . . . . . . . . . . . 2
   3. Presence for E.164 Numbers . . . . . . . . . . . . . . . . . . . 2
   4. The 'E2U+pres' Enumservice . . . . . . . . . . . . . . . . . . . 3
   5. Example of E2U+pres Enumservice  . . . . . . . . . . . . . . . . 4
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 5
      8.2.  Informative References . . . . . . . . . . . . . . . . . . 5
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [8]) to translate telephone numbers, such as +12025332600, into URIs (Uniform Resource Identifiers, RFC 2396 [9]), such as pres:user@host.com. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources.

ENUM (E.164 Number Mapping、RFC 3761 [1]) は、DNS (Domain Name Service、RFC 1034 [8]) を使用して、12025332600 などの電話番号を URI (Uniform Resource Identifiers、RFC 2396 [9])、pres:user@host.com など。ENUM は主に、電話番号に依存するシステムと、URI を使用してリソースを識別するシステムの相互接続を容易にするために存在します。

Presence is a service defined in RFC 2778 [2] that allows users of a communications service to monitor one another's availability and disposition in order to make decisions about communicating. Presence information is highly dynamic and generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like.

プレゼンスは、RFC 2778 [2] で定義されているサービスで、通信サービスのユーザーが通信に関する決定を下すために、お互いの可用性と性質を監視できるようにします。プレゼンス情報は非常に動的であり、一般に、ユーザーがオンラインかオフラインか、忙しいかアイドル状態か、通信デバイスから離れているか近くにいるかなどを特徴付けます。

The IETF has defined a generic URI used to identify a presence service for a particular resource: the 'pres' URI scheme (defined in CPP [4]). This document describes an enumservice for advertising presence information associated with an E.164 number.

IETF は、特定のリソースのプレゼンスサービスを識別するために使用される汎用 URI、つまり「pres」URI スキーム (CPP [4] で定義) を定義しました。このドキュメントでは、E.164 番号に関連付けられたプレゼンス情報を広告するための enumservice について説明します。

2. ENUM Service Registration

2. ENUMサービス登録

As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document:

[1] で定義されているように、以下はこの文書で指定されている enumservice の登録に必要な情報を網羅したテンプレートです。

Service name: "E2U+pres"

サービス名：「E2U pres」

      URI scheme(s): "pres:"

Functional Specification: See section 4.

機能仕様: セクション 4 を参照してください。

Security considerations: See section 6.

セキュリティに関する考慮事項: セクション 6 を参照してください。

Intended usage: COMMON

使用目的: 共通

Author: Jon Peterson (jon.peterson@neustar.biz)

著者: ジョン・ピーターソン (jon.peterson@neustar.biz)

Any other information that the author deems interesting: See section 3.

著者が興味深いと考えるその他の情報: セクション 3 を参照してください。

3. Presence for E.164 Numbers

3. E.164 番号の存在

This document specifies an enumservice field that allows presence information to be provided for an E.164 number. This may include presence states associated with telephones, or presence of non-telephony communications services advertised by ENUM.

この文書では、E.164 番号にプレゼンス情報を提供できるようにする enumservice フィールドを指定します。これには、電話に関連するプレゼンス状態、または ENUM によってアドバタイズされる非電話通信サービスのプレゼンスが含まれる場合があります。

Endpoints that participate in a presence architecture are known (following the framework in RFC 2778 [2]) as watchers and presentities. Watchers subscribe to the presence of presentities and are notified when the presence of a presentity changes. Watchers generally monitor the presence of a group of presentities with whom they have an ongoing association. As an example, consider how this might apply to a telephony service. Most cellular telephones today have an address book-like feature, a small database of names and telephone numbers. Such a telephone might act as a watcher, subscribing to the presence of some or all of the telephone numbers in its address book. The display of the telephone might then show its user, when a presence-enabled telephone number is selected, the availability of the destination. With this information, the user might change their calling habits to correspond better to the availability of his or her associates.

プレゼンスアーキテクチャに参加するエンドポイントは、(RFC 2778 [2] のフレームワークに従って) ウォッチャーおよびプレゼンティティとして知られています。ウォッチャーはプレゼンティティのプレゼンスをサブスクライブし、プレゼンティティのプレゼンスが変化すると通知を受け取ります。ウォッチャーは通常、継続的な関係を持つプレゼンティティのグループの存在を監視します。例として、これが電話サービスにどのように適用されるかを考えてみましょう。現在のほとんどの携帯電話には、名前と電話番号の小さなデータベースであるアドレス帳のような機能が備わっています。このような電話は、アドレス帳内の電話番号の一部またはすべての存在をサブスクライブするウォッチャーとして機能する可能性があります。プレゼンス対応の電話番号が選択されると、電話機のディスプレイに、宛先が利用可能かどうかがユーザーに表示される場合があります。この情報を使用すると、ユーザーは自分の同僚の対応状況に応じて電話をかける習慣を変更できる可能性があります。

The presence information that is shared varies by communications service. The IETF has defined a Presence Information Data Format (or PIDF [6]) for describing the presence data associated with a presentity. The baseline PIDF specification declares only two presence states: OPEN and CLOSED (these terms are defined in RFC 2778 [2]); the former suggests that the destination resource is able to accept communication requests, the latter that it is not. These two states provide useful but rudimentary insight into the communications status of a presentity. For that reason, PIDF is an extensible format, and new sorts of statuses can be defined for specific communications services. For example, a telephony-based presence service might define a status corresponding to 'busy'. Extending PIDF for telephony services is, however, outside the scope of this document.

共有されるプレゼンス情報は通信サービスによって異なります。IETF は、プレゼンティティに関連付けられたプレゼンスデータを記述するためのプレゼンス情報データフォーマット (PIDF [6]) を定義しました。ベースライン PIDF 仕様では、OPEN と CLOSED の 2 つのプレゼンス状態のみが宣言されています (これらの用語は RFC 2778 [2] で定義されています)。前者は宛先リソースが通信要求を受け入れることができることを示し、後者はそうではないことを示します。これら 2 つの状態は、プレゼンティティの通信ステータスについての有用ではありますが、初歩的な洞察を提供します。そのため、PIDF は拡張可能な形式であり、特定の通信サービスに対して新しい種類のステータスを定義できます。たとえば、テレフォニーベースのプレゼンスサービスでは、「話中」に対応するステータスを定義できます。ただし、テレフォニーサービス用の PIDF の拡張については、このドキュメントの範囲外です。

4. The 'E2U+pres' Enumservice

4. 「E2U pres」列挙サービス

Traditionally, the services field of an NAPTR record (as defined in [10]) contains a string composed of two subfields: a 'protocol' subfield and a 'resolution service' subfield. ENUM in particular defines an 'E2U' (E.164 to URI) resolution service. This document defines an 'E2U+pres' enumservice for presence.

伝統的に、NAPTR レコードのサービスフィールド ([10] で定義) には、「プロトコル」サブフィールドと「解決サービス」サブフィールドの 2 つのサブフィールドで構成される文字列が含まれています。ENUM は特に、「E2U」(E.164 から URI) 解決サービスを定義します。このドキュメントでは、プレゼンス用の「E2U pres」列挙サービスを定義します。

The scheme of the URI that will appear in the regexp field of an NAPTR record using the 'E2U+pres' enumservice SHOULD be the 'pres' URI scheme. Other URI schemes appropriate to presence services MAY be used; however, the use of the 'pres' URI scheme ensures a greater level of compatibility than would the use of any URI specific to a particular presence protocol. The purpose of a pres URI is to provide a generic way to locate a presence service. Techniques for dereferencing the pres URI to locate a presence service are given in [5].

「E2U pres」列挙サービスを使用して NAPTR レコードの正規表現フィールドに表示される URI のスキームは、「pres」URI スキームである必要があります (SHOULD)。プレゼンスサービスに適した他の URI スキームを使用してもよい(MAY)。ただし、「pres」URI スキームを使用すると、特定のプレゼンスプロトコルに固有の URI を使用するよりも高いレベルの互換性が保証されます。pres URI の目的は、プレゼンスサービスを見つけるための一般的な方法を提供することです。pres URI を逆参照してプレゼンスサービスを見つけるための手法は、[5] に記載されています。

The 'pres' URI scheme does not identify any particular protocol that will be used to handle presence operations (such as subscriptions and notifications). Rather, the mechanism in [5] details a way to discover whether the presence protocol(s) supported by the watcher is/are also supported by the presentity. SIP [7] is one protocol that can be used to convey presence information and manage subscriptions/notifications.

「pres」URI スキームは、プレゼンス操作 (サブスクリプションや通知など) を処理するために使用される特定のプロトコルを識別しません。むしろ、[5] のメカニズムは、ウォッチャによってサポートされているプレゼンスプロトコルがプレゼンティティによってもサポートされているかどうかを発見する方法を詳しく説明しています。SIP [7] は、プレゼンス情報を伝達し、サブスクリプション/通知を管理するために使用できるプロトコルの 1 つです。

5. Example of E2U+pres enumservice

5. E2U プレス列挙サービスの例

The following is an example of the use of the enumservice registered by this document in an NAPTR resource record.

以下は、このドキュメントによって NAPTR リソースレコードに登録された enumservice の使用例です。

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
   IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson@example.net!"

6. Security Considerations

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

DNS does not make policy decisions about the records it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered open to the public -- which is a cause for some privacy considerations.

DNS は、問い合わせ者と共有するレコードについてポリシーを決定しません。すべての DNS レコードは、すべての問い合わせ者がいつでも利用できると想定する必要があります。したがって、ENUM レコードセット内で提供される情報は一般に公開されていると見なされなければなりません。これにより、プライバシーが考慮されることになります。

Revealing a pres URI in and of itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk. More serious privacy concerns are associated with the unauthorized distribution of presence information. For this reason, presence protocols have a number of security requirements (detailed in RFC 2779 [3]) that call for authentication of watchers, integrity and confidentiality properties, and similar measures to prevent abuse of presence information. Any presence protocol used in conjunction with the 'pres' URI scheme is required to meet these requirements.

pres URI を公開すること自体は、プライバシーに関する多くの懸念を引き起こす可能性は低いですが、URI の構造によっては、ターゲットのフルネームや雇用主が公開される可能性があります。匿名 URI を使用すると、このリスクが軽減されます。より深刻なプライバシーの問題は、プレゼンス情報の不正配布に関連しています。このため、プレゼンスプロトコルには、ウォッチャーの認証、完全性と機密性のプロパティ、およびプレゼンス情報の悪用を防止する同様の手段を要求する多くのセキュリティ要件 (RFC 2779 [3] で詳細が説明されています) があります。「pres」URI スキームと組み合わせて使用されるプレゼンスプロトコルは、これらの要件を満たす必要があります。

Unlike a traditional telephone number, the resource identified by a pres URI may require that callers provide cryptographic credentials for authentication and authorization before presence information is returned. In concert with presence protocols, ENUM can actually provide far greater protection from unwanted callers than does the existing PSTN, despite the public availability of ENUM records.

従来の電話番号とは異なり、pres URI によって識別されるリソースでは、プレゼンス情報が返される前に、発信者が認証と認可のために暗号化資格情報を提供することが必要になる場合があります。ENUM レコードは公開されているにもかかわらず、プレゼンスプロトコルと連携して、ENUM は実際に、既存の PSTN よりも望ましくない発信者からはるかに強力な保護を提供できます。

7. IANA Considerations

7. IANAの考慮事項

This document registers the 'E2U+pres' enumservice under the enumservice registry described in the IANA considerations in RFC 3761. Details of the registration are given in section 2.

この文書は、RFC 3761 の IANA の考慮事項に記載されている enumservice レジストリの下に「E2U pres」enumservice を登録します。登録の詳細はセクション 2 に記載されています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application", RFC 3761, April 2004.

[1] Faltstrom、P. および M. Mealing、「E.164 からユニフォームリソース識別子 (URI) 動的委任発見システム (DDDS) アプリケーション」、RFC 3761、2004 年 4 月。

[2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[2] Day, M.、Rosenberg, J.、および H. Sugano、「プレゼンスとインスタントメッセージングのモデル」、RFC 2778、2000 年 2 月。

[3] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.

[3] Day, M.、Aggarwal, S.、Mohr, G.、および J. Vincent、「インスタントメッセージング / プレゼンスプロトコルの要件」、RFC 2779、2000 年 2 月。

[4] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

[4] Peterson, J.、「Common Profile for Presence (CPP)」、RFC 3859、2004 年 8 月。

[5] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.

[5] Peterson, J.、「インスタントメッセージングとプレゼンスのアドレス解決」、RFC 3861、2004 年 8 月。

8.2. Informative References

8.2. 参考引用

[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[6] Sugano, H.、Fujimoto, S.、Klyne, G.、Bateman, A.、Carr, W.、および J. Peterson、「プレゼンス情報データ形式 (PIDF)」、RFC 3863、2004 年 8 月。

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

[7] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「SIP: セッション開始プロトコル」、RFC 3261、2002年6月。

[8] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[8] Mockapetris, P.、「ドメイン名 - 概念と機能」、STD 13、RFC 1034、1987 年 11 月。

[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[9] Berners-Lee, T.、Fielding, R.、および L. Masinter、「Uniform Resource Identifiers (URI): Generic Syntax」、RFC 2396、1998 年 8 月。

[10] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[10] Mealing, M.、「Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database」、RFC 3403、2002 年 10 月。

Author's Address

著者の連絡先

Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 USA

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

Full Copyright Statement

完全な著作権に関する声明

著作権 (C) インターネット協会 (2005)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネットエンジニアリングタスクフォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、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 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC エディター機能の資金は現在、インターネット協会によって提供されています。