RFC3953 日本語訳
3953 Telephone Number Mapping (ENUM) Service Registration for PresenceServices. J. Peterson. January 2005. (Format: TXT=13875 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson Request for Comments: 3953 NeuStar Category: Standards Track January 2005
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3953年のNeuStarカテゴリ: 標準化過程2005年1月
Telephone Number Mapping (ENUM) Service
Registration for Presence Services
存在サービスのための電話番号マッピング(ENUM)サービス登録
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM.
このドキュメントは存在のためにTelephone Number Mapping(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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ENUMは登録. . . . . . . . . . . . . . . . . . . 2 3を修理します。 E.164No.. . . . . . . . . . . . . . . . . . . 2 4のための存在。 'E2U+pres'Enumservice. . . . . . . . . . . . . . . . . . . 3 5。 E2U+pres Enumservice. . . . . . . . . . . . . . . . 4 6に関する例。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 5作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . . 7
Peterson Standards Track [Page 1] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[1ページ]。
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.
電話番号を翻訳してください、+12025332600などのように、URIに。ENUM、(E.164 Number Mapping、RFC3761[1])がDNSを使用するシステムである、(ドメインName Service、RFC1034[8])、(Uniform Resource Identifier、RFC2396[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.
存在は情報提供サービスのユーザが交信に関する決定をするようにお互いの有用性と気質をモニターできるRFC2778[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:"
URI計画: 「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で広告を出しました。
Peterson Standards Track [Page 2] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[2ページ]。
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.
存在構造に参加する終点が知られています。(ウォッチャーとpresentitiesとしてRFC2778[2])で枠組みに従います。 ウォッチャーは、presentitiesの存在に加入して、presentityの存在が変化するとき、通知されます。 一般に、ウォッチャーは彼らが進行中の協会を持っているpresentitiesのグループの存在をモニターします。 例として、これがどのように電話サービスに適用されるかもしれないか考えてください。 ほとんどの携帯電話には、今日、アドレス帳のような特徴、名前と電話番号の小さいデータベースがあります。 そのような電話はウォッチャーとして務めるかもしれません、アドレス帳での電話番号のいくつかかすべての存在に加入して。 次に、電話の表示はユーザを見せているかもしれません、存在によって可能にされた電話番号が選択されるとき、目的地の有用性。 この情報で、ユーザは、より一層その人の仲間の有用性に相当するように彼らの呼ぶ習慣を変えるかもしれません。
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はPresence情報Data Formatを定義しました。(または、presentityに関連している存在データについて説明するためのPIDF[6])。 基線PIDF仕様は2つの存在州だけを宣言します: オープンとCLOSED、(これらの用語はRFC2778[2])で定義されます。 それは後者ですが、前者は、目的地リソースがコミュニケーション要求を受け入れることができると示唆します。 これらの2つの州がpresentityのコミュニケーション状態に関する役に立ちますが、初歩的な洞察を提供します。 その理由で、PIDFは広げることができる形式です、そして、特定の情報提供サービスのために新しい種類の状態は定義できます。 例えば、電話ベースの存在サービスは'忙しくする'ために対応する状態を定義するかもしれません。 しかしながら、このドキュメントの範囲の外に電話サービスのためにPIDFを広げるのがあります。
4. The 'E2U+pres' Enumservice
4. 'E2U+pres'Enumservice
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].
NAPTR記録のregexp分野に'pres'がURI計画であったなら'E2U+pres'enumservice SHOULDを使用することで現れるURIの計画。 存在サービスに適切な他のURI計画は使用されるかもしれません。 しかしながら、'pres'URI計画の使用は特定の存在プロトコルに特定のどんなURIの使用もそうするだろうより大きいレベルの互換性を確実にします。 pres URIの目的は存在サービスの場所を見つける一般的な方法を提供することです。 [5]で存在サービスの場所を見つけるようにpres URIに「反-参照をつけ」るためのテクニックを与えます。
Peterson Standards Track [Page 3] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[3ページ]。
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]のメカニズムはまた、ウォッチャーによってサポートされた存在プロトコルが/であるかどうかがpresentityが支持されると発見する方法を詳しく述べます。 SIP[7]は存在情報を伝えて、購読/通知を管理するのに使用できる1つのプロトコルです。
5. Example of E2U+pres enumservice
5. E2U+pres enumserviceに関する例
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!"
$起源3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。 「$!pres: NAPTR100 10「u」「E2U+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の使用はこの危険を緩和します。 より重大なプライバシーの問題は存在情報の権限のない分配に関連しています。 存在プロトコルには、この理由で、多くのセキュリティ要件があります。(ウォッチャー、保全、秘密性の特性、および存在情報の乱用を防ぐ同様の測定の認証を求めるRFC2779[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は実際に求められていない訪問者からの既存のPSTNをするよりはるかに大きい保護を提供できます、ENUM記録の公共の有用性にもかかわらず。
Peterson Standards Track [Page 4] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[4ページ]。
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.
このドキュメントはRFC3761の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.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーションへのE.164」、RFC3761、2004年4月。
[2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[2] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[3] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February
2000.
[3] 日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[4] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[4] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
[5] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[5] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、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] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[8] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[8]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[10] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[10] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
Peterson Standards Track [Page 5] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[5ページ]。
Author's Address
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar Inc.1800サター聖Suite570コンコード、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Peterson Standards Track [Page 6] RFC 3953 ENUM Registration for Presence Services January 2005
ピーターソンStandardsはサービス2005年1月に存在のためにRFC3953ENUM登録を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Peterson Standards Track [Page 7]
ピーターソン標準化過程[7ページ]
一覧
スポンサーリンク
