Network Working Group J. Peterson
Request for Comments: 3859 NeuStar
Category: Standards Track August 2004
Common Profile for Presence (CPP)
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services.
この文書が書かれた時点では、数多く存在するプロトコルは、（大部分は、市販のインスタントメッセージングサービスの構成要素として）使用されていた、そしてこれらのプロトコルに基づいたサービスの間にはほとんど相互運用性が実現されています。この仕様は、プレゼンスサービス間のゲートウェイの作成を容易にするために存在するための共通のセマンティクスとデータ形式を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Presence Service . . . . . . . . . . . . . . . . . . 4
3.1. Overview of the Presence Service . . . . . . . . . . . . 4
3.2. Identification of PRESENTITIES and WATCHERS . . . . . . 6
3.2.1. Address Resolution . . . . . . . . . . . . . . . 6
3.3. Format of Presence Information . . . . . . . . . . . . . 6
3.4. The Presence Service . . . . . . . . . . . . . . . . . . 7
3.4.1. The Subscribe Operation . . . . . . . . . . . . 7
3.4.2. The Notify Operation . . . . . . . . . . . . . . 8
3.4.3. Subscribe Operation (with Zero Duration) . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. The PRES URI Scheme . . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
A. PRES URI IANA Registration Template . . . . . . . . . . . . . 12
A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 12
A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 12
A.3. Character Encoding Considerations . . . . . . . . . . . 12
A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 12
A.5. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.6. Interoperability Considerations . . . . . . . . . . . . 13
A.7. Security Considerations . . . . . . . . . . . . . . . . 13
A.8. Relevant Publications . . . . . . . . . . . . . . . . . 13
A.9. Person & Email Address to Contact for Further
Information. . . . . . . . . . . . . . . . . . . . . . . 13
A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13
A.11. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13
B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 13
B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 13
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
Presence is defined in RFC2778 [5]. At the time this document was written, numerous presence protocols are in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines semantics and data formats for common services of presence to facilitate the creation of gateways between presence services: a common profile for presence (CPP).
存在は、RFC2778で定義されている[5]。この文書が書かれた時点では、数多く存在するプロトコルは、（大部分は、市販のインスタントメッセージングサービスの構成要素として）使用されている、これらのプロトコルに基づいたサービスの間にはほとんど相互運用性が実現されています。プレゼンスのための共通プロファイル（CPP）：この仕様は、プレゼンスサービスとの間のゲートウェイの作成を容易にするために存在する一般的なサービスのための意味論及びデータフォーマットを定義します。
Service behavior is described abstractly in terms of operations invoked between the consumer and provider of a service. Accordingly, each presence service must specify how this behavior is mapped onto its own protocol interactions. The choice of strategy is a local matter, providing that there is a clear relation between the abstract behaviors of the service (as specified in this memo) and how it is faithfully realized by a particular presence service. For example, one strategy might transmit presence information as key/value pairs, another might use a compact binary representation, and a third might use nested containers.
サービス動作は、サービスのコンシューマとプロバイダの間で呼び出されたオペレーションの観点で抽象的に記述されています。従って、各プレゼンス・サービスは、この動作は、それ自身のプロトコル相互作用にマッピングされる方法を指定しなければなりません。戦略の選択は、（このメモで指定されている）と、それがどのように忠実に、特定のプレゼンスサービスによって実現されるサービスの抽象的行動との間に明確な関係があることを提供し、ローカルの問題です。例えば、一つの戦略は、キー/値のペアとしてプレゼンス情報を送信することが、別のコンパクトバイナリ表現を使用する場合があり、第三は、ネストされたコンテナを使用するかもしれません。
The parameters for each operation are defined using an abstract syntax. Although the syntax specifies the range of possible data values, each presence service must specify how well-formed instances of the abstract representation are encoded as a concrete series of bits.
各操作のパラメータは、抽象構文を使用して定義されています。構文が可能なデータ値の範囲を指定しているが、各プレゼンス・サービスは、抽象表現の整形式のインスタンスがビットの具体的な系列として符号化される方法を指定しなければなりません。
In order to provide a means for the preservation of end-to-end features (especially security) to pass through presence interoperability gateways, this specification also provides recommendations for presence document formats that could be employed by presence protocols.
プレゼンス相互運用ゲートウェイを通過するエンドツーエンド機能の保存（特にセキュリティ）するための手段を提供するために、本明細書はまた、プレゼンスプロトコルによって使用することができるプレゼンス文書フォーマットのための推奨事項を提供します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
This memos makes use of the vocabulary defined in RFC 2778 [5]. Terms such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in the same meaning as defined therein.
このメモは、RFC 2778で定義された語彙を使用しています[5]。その中で定義されているようなCLOSED、INSTANT INBOX、PRESENCE、およびOPENなどの用語は同じ意味で使用されています。
The term 'gateway' used in this document denotes a network element responsible for interworking between diverse presence protocols. Although the presence protocols themselves are diverse, under the model in this document these protocols can carry a common payload that is relayed by the gateway. Whether these interworking intermediaries should be called 'gateways' or 'relays' is therefore somewhat debatable; for the purposes of this document, they are called 'CPP gateways'.
本書で使用される用語「ゲートウェイ」は、多様なプレゼンスプロトコル間のインターワーキングを担当するネットワーク要素です。存在自体が多様化されているプロトコルが、この文書に記載されているモデルでこれらのプロトコルは、ゲートウェイによって中継された共通のペイロードを運ぶことができます。これらのインターワーキングの仲介は「ゲートウェイ」または「リレー」と呼ばれるべきかどうかは、それゆえ、多少議論の余地があります。このドキュメントの目的のために、彼らは「CPPゲートウェイ」と呼ばれています。
The term 'presence service' also derives from RFC 2778, but its meaning changes slightly due to the existence of gateways in the CPP model. When a client sends an operation to a presence service, that service might either be an endpoint or an intermediary such as a CPP gateway - in fact, the client should not have to be aware which it is addressing, as responses from either will appear the same.
用語「プレゼンスサービス」は、RFC 2778に由来しますが、その意味が原因CPPモデルのゲートウェイが存在するために、わずかに変化します。クライアントは、プレゼンスサービスに操作を送信すると、そのサービスは、いずれかのエンドポイントまたはCPPゲートウェイなどの仲介者であるかもしれない - 実際には、クライアントはどちらかからの応答が表示されますよう、それが取り組んでいる意識する必要はありません同じ。
This document defines operations and attributes of an abstract presence protocol. In order for a compliant protocol to interface with a presence gateway, it must support all of the operations described in this document (i.e., the presence protocol must have some message or capability that provides the function described by all given operations). Similarly, the attributes defined for these operations must correspond to information available in the presence protocol in order for the protocol to interface with gateways defined by this specification. Note that these attributes provide only the minimum possible information that needs to be specified for interoperability - the functions in a presence protocol that correspond to the operations described in this document can contain additional information that will not be mapped by CPP.
この文書では、操作や抽象的な存在プロトコルの属性を定義します。プレゼンスゲートウェイとインターフェースに準拠したプロトコルのためには、本書で説明した動作のすべてをサポートしなければならない（即ち、プレゼンス・プロトコルは、すべての指定された操作で説明した機能を提供するいくつかのメッセージ又は能力を有していなければなりません）。同様に、これらの操作のために定義された属性は、この仕様で定義されたゲートウェイとインターフェースするプロトコルのためにプレゼンス・プロトコルで利用可能な情報に対応しなければなりません。 CPPによってマッピングされない追加情報を含むことができ、この文書で説明した動作に対応するプレゼンス・プロトコルで機能する - これらの属性は、相互運用性のために指定される必要がある唯一の可能な最小の情報を提供することに留意されたいです。
When an application wants to subscriber to the presence information associated with a PRESENTITY (in order to receive periodic notifications of presence information), it invokes the subscribe operation, e.g.,
アプリケーションは、（プレゼンス情報の定期的な通知を受信するために）プレゼンティティに関連するプレゼンス情報に加入したい場合、それは、例えば、加入操作を呼び出し
+-------+ +-------+
| | | |
| appl. | -- subscribe ----> | pres. |
| | | svc. |
+-------+ +-------+
The subscribe operation has the following attributes: watcher, target, duration, SubscriptID and TransID. The 'watcher' and 'target' identify the WATCHER and PRESENTITY, respectively, using the identifiers described in Section 3.2. The duration specifies the maximum number of seconds that the SUBSCRIPTION should be active (which may be zero, in which case this is a one-time request for presence information). The SubscriptID creates a reference to the SUBSCRIPTION that is used when unsubscribing. The TransID is a unique identifier used to correlate the subscribe operation with a response operation. Gateways should be capable of handling TransIDs and SubscriptIDs up to 40 bytes in length.
ウォッチャー、対象、期間、SubscriptIDとTRANSID：サブスクライブ操作は、以下の属性があります。 「ウォッチャー」と「ターゲット」は、セクション3.2に記載された識別子を使用して、それぞれ、WATCHERプレゼンティティを識別する。持続時間（これは、プレゼンス情報のためのワンタイム要求である場合にはゼロであってもよい）サブスクリプションがアクティブでなければならない最大秒数を指定します。 SubscriptIDは、アンサブスクライブするときに使用されるサブスクリプションに参照を作成します。 TRANSID応答操作と加入操作を相関させるために使用される一意の識別子です。ゲートウェイは、長さは40のバイトまでTransIDsとSubscriptIDsを扱うことができるべきです。
Upon receiving a subscribe operation, the service immediately responds by invoking the response operation containing the same TransID, e.g.,
加入操作を受信すると、サービスは直ちに、例えば、同じTRANSIDを含む応答操作を呼び出すことによって応答します
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
The response operation has the following attributes: status, TransID, and duration. 'status' indicates whether the subscribe operation has succeeded or failed. The TransID of the response operation corresponds to the TransID of the subscription operation to which it is responding. The 'duration' attribute specifies the number of seconds for which the subscription will be active (which may differ from the value requested in the subscribe operation).
ステータス、TRANSID、および期間：応答操作は、以下の属性があります。 「ステータスは」サブスクライブ操作が成功したか失敗したかどうかを示します。応答動作のTRANSIDは、それが応答されたサブスクリプション操作のTRANSIDに相当します。 「期間」属性は、（サブスクライブ操作に要求された値と異なる場合があります）サブスクリプションがアクティブになるの秒数を指定します。
If the response operation indicates success, the service immediately invokes the notify operation to communicate the presence information to the WATCHER, e.g.,
応答動作が成功を示す場合、サービスは直ちに、例えば、ウォッチャにプレゼンス情報を通信するための通知オペレーションを呼び出し
+-------+ +-------+
| | | |
| appl. | <------- notify -- | pres. |
| | | svc. |
+-------+ +-------+
The notify operation has the following attributes: watcher, target, and TransID. The values of 'watcher' and 'target' are identical to those given in the subscribe operation that triggered this notify operation. The TransID is a unique identifier for this notification.
ウォッチャー、ターゲット、およびTRANSID：通知操作は、以下の属性があります。 「ウォッチャー」と「ターゲット」の値は、この操作を通知するトリガー加入操作で指定されたものと同一です。 TRANSIDは、この通知の一意の識別子です。
The notify operation also has content, namely PRESENCE INFORMATION. Content details are specified in Section 3.3.
通知操作は、コンテンツ、すなわちプレゼンス情報を有しています。内容の詳細は、セクション3.3で指定されています。
If the duration parameter is non-zero, then for up to the specified duration, the service invokes the notify operation whenever there are any changes to the PRESENTITY's presence information. Otherwise, exactly one notify operation is invoked, achieving a one-time poll of the presence information. Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs) defined in CPP.
持続時間パラメータは非ゼロである場合、指定された期間まで、サービスは、プレゼンティティのプレゼンス情報に変更があるたびに操作を通知する呼び出しのために。それ以外の場合は、正確に一つの通知操作は、プレゼンス情報の一回のポーリングを達成し、呼び出されます。かかわらず、通知動作へのアプリケーションの応答がないCPPで定義された（通知する操作が発生した場合、すなわち、アプリケーションが応答操作を起動しません）。
The application may prematurely cancel a subscription by re-invoking the subscribe operation (as described above) with a duration of 0 and the same SubscriptID as the original subscribe operation , e.g.,
アプリケーションが途中、例えば0の期間と元の加入操作と同じSubscriptIDによる再起動加入操作（前述のように）によってサブスクリプションを取り消すことができます
+-------+ +-------+
| | | |
| appl. | -- subscribe 0 --> | pres. |
| | | svc. |
+-------+ +-------+
Note that a notify operation will be invoked when a subscription is prematurely canceled in this fashion; this notification may be discarded by the watcher.
サブスクリプションが早まっこのやり方でキャンセルされたときに通知操作が呼び出されることに注意してください。この通知は、ウォッチャによって破棄されてもよいです。
The service immediately responds by invoking the response operation containing the same TransID; e.g.,
サービスはすぐに同じTRANSIDを含む応答操作を呼び出すことによって応答します。例えば。、
+-------+ +-------+
| | | |
| appl. | <----- response -- | pres. |
| | | svc. |
+-------+ +-------+
Note that this specification assumes that CPP-compliant presence protocols provide reliable message delivery; there are no application-layer message delivery assurance provisions in this specification.
この仕様は、CPP準拠のプレゼンス・プロトコルは、信頼性の高いメッセージ配信を提供することを前提としています。本明細書には、アプリケーション層メッセージ配信保証規定は存在しません。
A PRESENTITY is specified using the PRES URI scheme, which is further described in Appendix A. An example would be: "pres:fred@example.com"
プレゼンティティが例のようになり、さらに、付録Aに記載されてPRES URIスキームを使用して指定されている：「PRESを：fred@example.com」
WATCHERs identify themselves in the same manner as PRESENTITIES; that is, with a pres URI.
ウォッチャは、プレゼンティティと同じ方法で自分自身を識別する。それはPRES URIで、です。
A presence service client determines the next hop to forward an operation to by resolving the domain name portion of the service destination. Compliant implementations SHOULD follow the guidelines for dereferencing URIs given in [2].
プレゼンスサービスクライアントは、サービス先のドメイン名部分を解決することによっての操作を転送するために次のホップを決定します。対応する実装は、[2]で与えられたURIを逆参照するためのガイドラインに従うべきです。
This specification defines an abstract interoperability mechanism for presence protocols; the message content definition given here pertains to semantics rather than syntax. However, some important properties for interoperability can only be provided if a common end-to-end format for presence is employed by the interoperating presence protocols, especially with respect to security. In order to maintain end-to-end security properties, applications that send notification operations through a CPP gateway MUST support the format defined in PIDF [4]. Applications MAY support other content formats.
この仕様は、プレゼンスプロトコルの抽象相互運用メカニズムを定義します。ここで与えられたメッセージの内容の定義は、セマンティクスではなく、構文に関係します。プレゼンスのための共通のエンドツーエンドの形式は特にセキュリティに関して、相互運用プレゼンスプロトコルによって使用される場合は、相互運用性のためのいくつかの重要な特性のみを提供することができます。エンドツーエンドのセキュリティ性を維持するために、CPPゲートウェイを介して通知オペレーションを送信するアプリケーションは、PIDF [4]で定義されたフォーマットをサポートしなければなりません。アプリケーションは、他のコンテンツフォーマットをサポートすることができます。
CPP gateways MUST be capable of relaying the body of a notification operation between supported presence protocols without needing to modify or inspect the content.
CPPゲートウェイは、コンテンツを変更または検査する必要なくサポートプレゼンスプロトコルとの間の通知動作の本体を中継することができなければなりません。
An implementation of the service must maintain information about both presence information and continual operations (like periodic notification) in persistent storage.
サービスの実装は、プレゼンス情報と永続ストレージに（定期的な通知のような）連続的な操作の両方についての情報を維持しなければなりません。
Note that the subscription-identifier attribute used by the subscribe operation is potentially long-lived. Accordingly, the values generated for this parameter should be unique across a significant duration of time. The SubscriptID parameter should be intrinsically globally unique over time, not merely unique among operations sent to or from a particular WATCHER and PRESENTITY.
サブスクライブ操作で使用されるサブスクリプション識別子属性が潜在的に長寿命であることに注意してください。したがって、このパラメータに生成される値は、時間のかなりの期間にわたって一意である必要があります。 SubscriptIDパラメータは、または特定のWATCHERとPRESENTITYから送信された動作のうち、単にユニークではありません、時間をかけて、本質的にグローバルにユニークでなければなりません。
When an application wants to subscribe to the presence information associated with a PRESENTITY, it invokes the subscribe operation.
アプリケーションは、プレゼンティティに関連するプレゼンス情報をサブスクライブしたい場合は、サブスクライブオペレーションを呼び出します。
When the service is informed of the subscribe operation, it performs these steps:
サービスは、サブスクライブ操作が通知されると、それは次の手順を実行します。
1. If the watcher or target parameter does not refer to a valid PRESENTITY, a response operation having status "failure" is invoked.
ウォッチャーまたはターゲットパラメータが有効なPRESENTITYを参照していない場合は1、ステータスが「失敗」を有する応答操作が呼び出されます。
2. If access control does not permit the application to request this operation, a response operation having status "failure" is invoked.
アクセス制御は、この操作を要求するアプリケーションを許可しない場合は2、ステータスが「失敗」を有する応答操作が呼び出されます。
3. If the duration parameter is non-zero, and if the watcher and target parameters refer to an in-progress subscribe operation for the application, a response operation having status "failure" is invoked.
3.持続時間パラメータは非ゼロであり、ウォッチャとターゲットパラメータは、アプリケーションのための進行中の加入操作を参照している場合、応答動作有する状態「故障」が呼び出された場合。
4. Otherwise, if the service is able to successfully deliver the message:
4.それ以外の場合は、サービスが正常にメッセージを配信することができる場合：
A response operation having status "success" is immediately
invoked. (If the service chooses a different duration for the
subscription then it conveys this information in the response
operation.)
A notify operation, corresponding to the target's presence information, is immediately invoked for the watcher.
通知操作は、対象者のプレゼンス情報に対応し、直ちにウォッチャーのために呼び出されます。
For up to the amount of time indicated by the duration parameter of the notify operation (measured from the time that the subscribe operation was received), if the target's presence information changes, and if access control allows, a notify operation is invoked for the watcher.
（加入操作を受け付けた時間から測定された）通知操作の期間パラメータによって示される時間の量までため、ターゲットのプレゼンス情報が変化した場合、アクセス制御が許可されている場合、通知動作がウォッチャーのために呼び出されます。
Note that if the duration parameter is zero-valued, then the subscribe operation is making a one-time poll of the presence information. Accordingly, the final step above (continued notifications for the duration of the subscription) does not occur.
継続時間パラメータがゼロ値である場合、加入操作は、プレゼンス情報の一回投票を行っていることに留意されたいです。従って、（サブスクリプションの期間中継続通知）上記の最終工程は発生しません。
When the service invokes a response operation as a result of this processing, the transID parameter is identical to the value found in the subscribe operation invoked by the application.
サービスは、この処理の結果としての応答動作を呼び出すと、TRANSIDパラメータは、アプリケーションによって呼び出されたサブスクライブ操作で求めた値と同じです。
The service invokes the notify operation whenever the presence information associated with a PRESENTITY changes and there are subscribers requesting notifications for that PRESENTITY.
プレゼンス情報は、プレゼンティティの変化と関連付けられ、そのPRESENTITYの通知を要求する加入者が存在するときはいつでもサービスが通知オペレーションを呼び出します。
There is no application response to the notify operation.
通知操作へのアプリケーションの応答がありません。
When an application wants to terminate a subscription, it issues a SUBSCRIBE 0 with the SubscriptID of an existing subscription. Note that a notify operation will be invoked by the presentity when a subscription is canceled in this fashion; this notification can be discarded by the watcher. There is no independent UNSUBSCRIBE operation.
アプリケーションは、サブスクリプションを終了したい場合は、既存のサブスクリプションのSubscriptIDに0をSUBSCRIBE発行します。通知動作は、サブスクリプションは、このように解除されるプレゼンティティによって呼び出されることに注意してください。この通知は、ウォッチャによって破棄することができます。独立したUNSUBSCRIBE操作はありません。
When an application wants to directly request presence information to be supplied immediately without initiating any persistent subscription, it issues a SUBSCRIBE 0 with a new SubscriptID. There is no independent FETCH operation.
アプリケーションは任意の永続的なサブスクリプションを開始せずに、すぐに供給されるように、直接プレゼンス情報を要求したい場合は、新しいSubscriptIDに0をSUBSCRIBE発行します。独立したFETCH操作はありません。
Detailed security considerations for presence protocols given in RFC 2779 [6] (in particular, requirements are given in sections 5.1 through 5.3 with some motivating discussion in 8.2).
RFC 2779で指定されたプレゼンスプロトコルの詳細なセキュリティ問題は、[6]（具体的には、要件は8.2でいくつかの動機議論で5.3を介してセクション5.1に記載されています）。
CPP defines an interoperability function that is employed by gateways between presence protocols. CPP gateways MUST be compliant with the minimum security requirements of the presence protocols with which they interface.
CPPは、プレゼンスプロトコル間のゲートウェイによって使用される相互運用性の機能を定義します。 CPPゲートウェイは、彼らがどのインタフェースでプレゼンス・プロトコルの最低限のセキュリティ要件に準拠している必要があります。
The introduction of gateways to the security model of presence in RFC 2779 also introduces some new risks. End-to-end security properties (especially confidentiality and integrity) between presentities and watchers that interface through a CPP gateway can only be provided if a common presence format (such as the format described in [4]) is supported by the protocols interfacing with the CPP gateway.
RFC 2779でのプレゼンスのセキュリティモデルへのゲートウェイの導入はまた、いくつかの新たなリスクを紹介します。 CPPゲートウェイを介してインターフェイスが唯一の共通のプレゼンス形式場合に提供することができることをプレゼンティティとウォッチャーとの間のエンドツーエンドのセキュリティ特性（特に機密性と完全性）（[4]に記載のフォーマットなど）とのインターフェースプロトコルによってサポートされていますCPPゲートウェイ。
When end-to-end security is required, the notify operation MUST use PIDF, and MUST secure the PIDF MIME body with S/MIME [8], with encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS SignedData).
エンドツーエンドのセキュリティが必要とされる場合、通知の動作は、暗号化（CMS EnvelopeData）および/またはS / MIME署名（CMSのSignedData）と、[8] PIDFを使用しなければならない、およびS / MIMEでPIDF MIME本体を固定しなければなりません。
The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms. Implementations MAY use AES as an encryption algorithm, but are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS.
S / MIMEアルゴリズムは、CMSによって設定されている[9]。 AESは最高の多くのプラットフォームの能力に合っていることが予想されるとして、AES [11]アルゴリズムは、優先されなければなりません。実装は、暗号化アルゴリズムとしてAESを使用することができるが、S / MIMEやCMSで義務付けのみベースラインアルゴリズムをサポートしている必要があります。
When PRES URIs are used in presence protocols, they convey the identity of watchers and/or presentities. Certificates that are used for S/MIME presence operations SHOULD, for the purposes of reference integrity, contain a subjectAltName field containing the PRES URI of their subject. Note that such certificates may also contain other identifiers, including those specific to particular presence protocols. In order to further facilitate interoperability of secure presence services through CPP gateways, users and service providers are encouraged to employ trust anchors for certificates that are widely accepted rather than trust anchors specific to any particular presence service or provider.
PRESのURIは存在プロトコルで使用されているとき、彼らはウォッチャーおよび/またはプレゼンのアイデンティティを伝えます。 S / MIMEプレゼンスオペレーションのために使用される証明書は、参照整合性の目的のために、その被写体のPRES URIを含むのsubjectAltNameフィールドを含むべきです。そのような証明書は、特定のプレゼンスプロトコルに固有のものを含む他の識別子を含んでもよいことに留意されたいです。さらにCPPのゲートウェイを介してセキュアなプレゼンスサービスの相互運用性を促進するためには、ユーザとサービスプロバイダは、広く受け入れられているというよりも信頼が特定のプレゼンスサービスやプロバイダに固有のアンカーされている証明書のトラストアンカーを採用することをお勧めします。
In some cases, anonymous presence services may be desired. Such a capability is beyond the scope of this specification.
いくつかのケースでは、匿名のプレゼンスサービスが望まれ得ます。このような機能は、この仕様の範囲を超えています。
The IANA has assigned the "pres" URI scheme.
IANAは「PRES」URIスキームを割り当てています。
The Presence (PRES) URI scheme designates an Internet resource, namely a PRESENTITY or WATCHER.
プレゼンス（PRES）URIスキームは、インターネットリソース、すなわちPRESENTITY又はWATCHERを指定します。
The syntax of a PRES URI is given in Appendix A.
PRES URIの構文は、付録Aに記載されています
Dave Crocker edited earlier versions of this document.
デイブ・クロッカーはこのドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
以下の個人は、この文書にかなりのテキストの貢献をしました。
Athanassios Diacakis (thanos.diacakis@openwave.com)
Athanassios Diacakis（thanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
がflorencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
クリスチャン・ハイテマ（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
グラハムKlyne（gk@ninebynine.org）
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
ジョナサン・ローゼンバーグ（jdrosen@dynamicsoft.com）
Robert Sparks (rsparks@dynamicsoft.com)
ロバート・スパークス（rsparks@dynamicsoft.com）
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
ひろやす すがの （すが＠ｆぁｂ。ふじつ。こ。ｊｐ）
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[2] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[2]ピーターソン、J.、 "インスタントメッセージングとプレゼンスのためのアドレス解決を"、RFC 3861、2004年8月。
[3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April 2001.
[3]レズニック、P.、 "インターネットメッセージ形式"、STD 11、RFC 2822、2001年4月。
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[4]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[5]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6日目、M.、アガルワル、S.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[7] Allocchio, C., "GSTN Address Element Extensions in Email Services", RFC 2846, June 2000.
[7] Allocchio、C.、 "電子メールサービスでGSTNアドレス要素の拡張"、RFC 2846、2000年6月。
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[8] Ramsdell、B.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[11] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm and in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
、RFC 3565、2003年7月[11] Schaad、J.、 "AES（Advanced Encryption Standard）暗号化アルゴリズムと暗号メッセージ構文（CMS）での使用"。
Appendix A. PRES URI IANA Registration Template
付録A. PRES URI IANA登録テンプレート
This section provides the information to register the pres: presence URI .
プレゼンスURI：このセクションでは、PRESを登録するための情報を提供します。
A.1. URI Scheme Name
A.1。 URIスキーム名
pres
PRES
A.2. URI Scheme Syntax
A.2。 URIスキームの構文
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
構文は、既存のmailtoを次の：ABNF RFC 2368.に指定されたURIの構文は次のとおりです。
PRES-URI = "pres:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric
PRES-URI = "PRES：" "？" [へ] [ヘッダー]ボックスヘッダ=へ=ヘッダ*（ "および" ヘッダ）ヘッダ=名 "=" 値名= *尿hvalue = *尿
Here the symbol "mailbox" represents an encoded mailbox name as defined in RFC 2822 [3], and the symbol "uric" denotes any character that is valid in a URL (defined in RFC 2396 [10]).
ここで、RFC 2822で定義されている記号「メールボックス」[3]符号化されたメールボックス名を表し、記号「尿」がURLに有効な任意の文字（RFC 2396で定義されている[10]）です。
A.3. Character Encoding Considerations
A.3。文字エンコーディングの考慮事項
Representation of non-ASCII character sets in local-part strings is limited to the standard methods provided as extensions to RFC 2822 [3].
ローカル部分文字列に非ASCII文字セットの表現は、RFC 2822の拡張機能として提供し、標準的な方法に制限されている[3]。
A.4. Intended Usage
A.4。使用目的
Use of the pres: URI follows closely usage of the mailto: URI. That is, invocation of an PRES URI will cause the user's instant messaging application to start, with destination address and message headers fill-in according to the information supplied in the URI.
PRESの使用：URI：URIは密接のmailtoの使用方法に従っています。これは、宛先アドレスとメッセージヘッダと、PRES URIの呼び出しは、ユーザーのインスタントメッセージングアプリケーションが起動するようになります、ですフィルインURIに提供された情報によると。
A.5. Applications and/or Protocols which use this URI Scheme Name
A.5。このURIスキーム名を使用するアプリケーションおよび/またはプロトコル
It is anticipated that protocols compliant with RFC 2779, and meeting the interoperability requirements specified here, will make use of this URI scheme name.
RFC 2779、およびここで指定された相互運用性の要件を満たすに準拠したプロトコルは、このURIのスキーム名を利用することが予想されます。
A.6. Interoperability Considerations
A.6。相互運用性に関する注意事項
The underlying exchange protocol used to send an instant message may vary from service to service. Therefore complete, Internet-scale interoperability cannot be guaranteed. However, a service conforming to this specification permits gateways to achieve interoperability sufficient to the requirements of RFC 2779.
インスタントメッセージを送信するために使用される基礎となる交換プロトコルは、サービスからサービスに変化してもよいです。そのため、完全な、インターネット規模の相互運用性を保証することはできません。しかし、この仕様に準拠したサービスは、RFC 2779の要件に十分な相互運用性を達成するためのゲートウェイを許可します。
A.7. Security Considerations
A.7。セキュリティの考慮事項
See Section 4.
第4節を参照してください。
A.8. Relevant Publications
A.8。関連出版物
RFC 2779, RFC 2778
RFC 2779、RFC 2778
A.9. Person & Email Address to Contact for Further Information
A.9。詳細のために連絡する人とEメールアドレス
Jon Peterson [mailto:jon.peterson@neustar.biz]
ジョン・ピーターソン[mailtoの：jon.peterson@neustar.biz]
A.10. Author/Change Controller
A.10。著者/変更コントローラ
This scheme is registered under the IETF tree. As such, IETF maintains change control.
この方式は、IETFツリーの下に登録されています。そのため、IETFは、コントロールを変更維持しています。
A.11. Applications and/or Protocols which use this URI Scheme Name
A.11。このURIスキーム名を使用するアプリケーションおよび/またはプロトコル
Instant messaging service; presence service
インスタントメッセージングサービス。プレゼンスサービス
Appendix B. Issues of Interest
関心の付録B.問題
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録では、簡単に相互運用ゲートウェイを設計する際に関心のある問題について説明します。
B.1. Address Mapping
B.1。アドレスマッピング
When mapping the service described in this memo, mappings that place special information into the im: address local-part MUST use the meta-syntax defined in RFC2846 [7].
このメモで説明したサービスをマッピングする場合、IMに特別な情報を配置マッピング：アドレスのローカル部分は、RFC2846 [7]で定義されたメタ構文を使用する必要があります。
B.2. Source-Route Mapping
B.2。ソースルートマッピング
The easiest mapping technique is a form of source-routing and usually is the least friendly to humans having to type the string. Source-routing also has a history of operational problems.
最も簡単なマッピング技術は、ソースルーティングの形態であり、通常の文字列を入力する必要が人間に優しい以上です。ソース・ルーティングはまた、操作上の問題の歴史を持っています。
Use of source-routing for exchanges between different services is by a transformation that places the entire, original address string into the im: address local part and names the gateway in the domain part.
ドメイン部分にゲートウェイアドレスローカル部分と名前：ソースルーティング異なるサービス間で交換のための使用は、IMに全体の元のアドレス文字列を配置転換することによるものです。
For example, if the destination INSTANT INBOX is "pepp://example.com/ fred", then, after performing the necessary character conversions, the resulting mapping is:
先INSTANT INBOX「はPEPP：//example.com/フレッド」である場合、例えば、その後、必要に応じて文字変換を行った後、得られたマッピングがあります。
im:pepp=example.com/fred@relay-domain
イム：pepp=example.com/fred@relay-domain
where "relay-domain" is derived from local configuration information.
「リレー・ドメインは、」ローカルの設定情報から導出されています。
Experience shows that it is vastly preferable to hide this mapping from end-users - if possible, the underlying software should perform the mapping automatically.
経験は、エンドユーザーからこのマッピングを非表示にする非常に望ましいことを示している - 可能な場合は、基盤となるソフトウェアが自動的にマッピングを行う必要があります。
Appendix C. Acknowledgments
付録C.謝辞
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes.
著者は彼のコメント、提案や熱意のためにジョンRamsdellを確認したいと思います。社説の修正のためのデレク・アトキンスに感謝します。
Author's Address
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。