Network Working Group J. Peterson
Request for Comments: 3953 NeuStar
Category: Standards Track January 2005
Telephone Number Mapping (ENUM) Service
Registration for Presence Services
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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
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番号マッピング、RFC 3761 [1]）（[8]ドメインネームサービス、RFC 1034）のURI（ユニフォームリソース識別子、RFC 2396に、そのような12025332600として、電話番号を変換するためにDNSを使用するシステムであります[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.
プレゼンスは、[2]通信サービスの利用者が通信に関する意思決定を行うために、互いの可用性および処分を監視することを可能にRFC 2778で定義されたサービスです。プレゼンス情報は非常に動的であり、一般ユーザーが離れて通信機器や近く、などから、忙しいか、アイドル、オンラインまたはオフラインであるかどうかを特徴付けます。
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.
（CPP [4]で定義された）「PRES」URIスキーム：IETFは、一般的なURIが特定のリソースのプレゼンスサービスを識別するために使用される定義されています。この文書では、E.164番号に関連付けられている広告プレゼンス情報についてenumserviceを説明しています。
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:"
URIスキーム（S）： "PRES："
Functional Specification: See section 4.
機能仕様：セクション4を参照してください。
Security considerations: See section 6.
セキュリティの考慮事項：セクション6を参照してください。
Intended usage: COMMON
意図している用法：COMMON
Author: Jon Peterson (jon.peterson@neustar.biz)
著者：ジョン・ピーターソン（jon.peterson@neustar.biz）
Any other information that the author deems interesting: See section 3.
著者は面白いと考えるその他の情報は：セクション3を参照してください。
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は、プレゼンティティに関連するプレゼンスデータを記述するため（[6]又はPIDF）プレゼンス情報データフォーマットを定義しています。ベースラインPIDF仕様は2つだけのプレゼンス状態を宣言：開閉（これらの用語は、RFC 2778で定義されている[2]）。前者は、宛先リソースは、それがないことを、通信要求を受け入れることができ、後者であることを示唆しています。これらの2つの状態がプレゼンの通信状況に役立ちますが、初歩的な洞察を提供します。そのため、PIDFは、拡張可能なフォーマットであり、ステータスの新しい種類は、特定の通信サービスのために定義することができます。例えば、電話ベースのプレゼンスサービスは、「忙しい」に対応するステータスを定義できます。電話サービスのためのPIDFの拡張は、この文書の範囲外で、しかし、です。
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」（URIにE.164）を定義します。この文書では、「E2U + PRESのプレゼンスのためのenumserviceを定義します。
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」enumserviceを使用してNAPTRレコードの正規表現のフィールドに表示されますURIのスキームは「PRES」URIスキームであるべきです。プレゼンスサービスに適切な他のURIスキームが使用されるかもしれません。しかし、「PRES」URIスキームの使用は、特定のプレゼンス・プロトコルへの任意のURIの特定の使用するより互換性の高いレベルを保証します。 PRES URIの目的は、プレゼンスサービスを見つけるための汎用的な方法を提供することです。プレゼンスサービスを検索するURI PRESを逆参照するための技術は、[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つのプロトコルです。
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!"
$ ORIGINの3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。 NAPTR 100 10 "U" "E2U + PRES" IN "！。^ * $ PRES：！jon.peterson@example.net！"
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の場合よりも、不要な発信者からはるかに大きい保護を提供することができます。
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.
このドキュメントは、登録の3761詳細はセクション2に記載されているRFCでIANA問題で説明enumserviceレジストリの下にある「E2U + PRES」enumserviceを登録します。
[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. Mealling、 "ユニフォームリソース識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーションへのE.164"、RFC 3761、2004年4月。
[2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[2]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[3] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[3日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[4] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[4]ピーターソン、J.、RFC 3859、2004年8月 "共通プロファイルプレゼンス（CPP）のために"。
[5] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[5]ピーターソン、J.、 "インスタントメッセージングとプレゼンスのためのアドレス解決を"、RFC 3861、2004年8月。
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[6]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、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] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
Author's Address
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。