[要約] RFC 3859は、Presence (CPP)のための共通プロファイルであり、プレゼンス情報の共有と管理を容易にするために設計されています。このRFCの目的は、異なるプレゼンスシステム間での相互運用性を向上させることです。
Network Working Group J. Peterson
Request for Comments: 3859 NeuStar
Category: Standards Track August 2004
Common Profile for Presence (CPP)
プレゼンスの共通プロファイル（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）The Internet Society（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]で定義されています。このドキュメントが書かれた時点で、多数の存在プロトコルが使用されています（主に商用インスタントメッセージングサービスのコンポーネントとして）。これらのプロトコルに基づくサービス間の相互運用性はほとんど達成されていません。この仕様では、存在感の一般的なサービスのセマンティクスとデータ形式を定義して、プレゼンスサービス間のゲートウェイの作成を促進します。
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.
サービスの動作は、サービスの消費者とプロバイダーの間で呼び出される運用の観点から抽象的に説明されています。したがって、各プレゼンスサービスは、この動作が独自のプロトコルの相互作用にマッピングされる方法を指定する必要があります。戦略の選択はローカルな問題であり、サービスの抽象的な動作（このメモで指定されているように）と特定のプレゼンスサービスによって忠実に実現される方法との間に明確な関係があることを規定しています。たとえば、ある戦略は、存在情報をキー/値のペアとして送信する可能性があり、別の戦略はコンパクトなバイナリ表現を使用する場合があり、3分の1はネストされた容器を使用する場合があります。
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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈され、準拠の実装の要件レベルを示します。
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]。閉じた、インスタント受信トレイ、存在感、オープンなどの用語は、そこに定義されているのと同じ意味で使用されます。
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.
購読操作には、ウォッチャー、ターゲット、持続時間、サブスクリプショット、およびTransIDの次の属性があります。「ウォッチャー」と「ターゲット」は、セクション3.2で説明されている識別子を使用して、それぞれウォッチャーとプレゼンティを識別します。期間は、サブスクリプションがアクティブである必要がある最大秒数を指定します（これはゼロである可能性があります。この場合、これは存在情報の1回限りのリクエストです）。subscriptidは、登録解除時に使用されるサブスクリプションへの参照を作成します。TransIDは、購読操作を応答操作と相関させるために使用される一意の識別子です。ゲートウェイは、長さが最大40バイトまでのトランスイドとサブスクリプショットを処理できる必要があります。
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).
応答操作には、次の属性があります：ステータス、トランスID、および期間。「ステータス」は、購読操作が成功したか失敗したかを示します。応答操作の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.,
応答操作が成功を示した場合、サービスはすぐにNotify操作を呼び出して存在情報をウォッチャーに伝えます。
+-------+ +-------+
| | | |
| 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.
Notify操作には、ウォッチャー、ターゲット、およびTransIDの次の属性があります。「ウォッチャー」と「ターゲット」の値は、この通知操作をトリガーした購読操作で与えられた値と同じです。TransIDは、この通知のユニークな識別子です。
The notify operation also has content, namely PRESENCE INFORMATION. Content details are specified in Section 3.3.
Notify操作には、コンテンツ、つまりプレゼンス情報もあります。コンテンツの詳細は、セクション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.
持続時間パラメーターがゼロ以外の場合、指定された期間まで、サービスはプレゼンティの存在情報に変更がある場合に通知操作を呼び出します。それ以外の場合、正確に1つのNotify操作が呼び出され、存在情報の1回限りの世論調査が達成されます。とにかく、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の期間と元のサブスクライブ操作と同じサブスクリプトでサブスクライブ操作（上記のように）を再拒否することにより、サブスクリプションを早期にキャンセルする場合があります。
+-------+ +-------+
| | | |
| 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"
Pres URIスキームを使用して提示が指定されます。これについては、付録Aでさらに説明します。例は、「pres：fred@example.com」です。
WATCHERs identify themselves in the same manner as PRESENTITIES; that is, with a pres URI.
ウォッチャーは、プレゼンテーションと同じ方法で自分自身を識別します。つまり、プレス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.
購読操作で使用されるサブスクリプション識別子属性は、潜在的に長寿命であることに注意してください。したがって、このパラメーターに対して生成された値は、かなりの期間にわたって一意でなければなりません。サブスクリプトパラメーターは、特定のウォッチャーとプレゼンテーションに送信される操作の間で単独ではなく、時間の経過とともに本質的にグローバルにユニークである必要があります。
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.
1. ウォッチャーまたはターゲットパラメーターが有効なプレゼンテーションを参照していない場合、ステータス「失敗」を持つ応答操作が呼び出されます。
2. If access control does not permit the application to request this operation, a response operation having status "failure" is invoked.
2. Access Controlがアプリケーションにこの操作を要求できない場合、ステータス「失敗」を持つ応答操作が呼び出されます。
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. 持続時間パラメーターがゼロではない場合、およびWatcherパラメーターとターゲットパラメーターがアプリケーションの進行中の購読操作を参照する場合、ステータス「障害」を持つ応答操作が呼び出されます。
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.
Notify操作の持続時間パラメーター（購読操作が受信された時刻から測定）、ターゲットの存在情報が変更された場合、およびアクセス制御が許可されている場合、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.
持続時間パラメーターがゼロ値の場合、サブスクライブ操作は存在情報の1回限りの投票を行っていることに注意してください。したがって、上記の最後のステップ（サブスクリプションの期間の継続的な通知）は発生しません。
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.
このサービスは、プレゼンテーションに関連する存在情報が変更され、そのプレゼンテーションの通知を要求するサブスクライバーがあります。
There is no application response to the notify operation.
Notify操作へのアプリケーション応答はありません。
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.
アプリケーションがサブスクリプションを終了したい場合、既存のサブスクリプションのサブスクリプトでサブスクライブ0を発行します。この方法でサブスクリプションがキャンセルされた場合、通知操作はプレゼントによって呼び出されることに注意してください。この通知は、ウォッチャーによって破棄できます。独立した登録操作はありません。
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.
アプリケーションが、永続的なサブスクリプションを開始せずに存在情報を直接要求するように直接リクエストすることを望んでいる場合、新しいサブスクリプションでサブスクライブ0を発行します。独立したフェッチ操作はありません。
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]に記載されている存在プロトコルの詳細なセキュリティ上の考慮事項（特に、要件はセクション5.1から5.3に示されており、8.2でのやる気のある議論があります）。
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).
エンドツーエンドのセキュリティが必要な場合、Notify操作はPIDFを使用する必要があり、S/MIME [8]を使用して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 [11]アルゴリズムは、AESが多くのプラットフォームの機能に最適な機能に最適であると予想されるため、推奨される必要があります。実装では、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の存在操作に使用される証明書は、参照整合性の目的で、被験者のプレスを含む対象のフィールドを含める必要があります。そのような証明書には、特定の存在プロトコルに固有の証明書を含む他の識別子も含まれる場合があることに注意してください。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スキームは、インターネットリソース、つまりプレゼンテーションまたはウォッチャーを指定します。
The syntax of a PRES URI is given in Appendix A.
Pres URIの構文は、付録Aに記載されています。
Dave Crocker edited earlier versions of this document.
Dave Crockerは、このドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
次の個人は、この文書に実質的なテキスト貢献をしました。
Athanassios Diacakis (thanos.diacakis@openwave.com)
athanassios diacakis（sanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
Florencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
ChristianHuitema（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
Graham Klyne（gk@ninebynine.org）
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
Jonathan Rosenberg（jdrosen@dynamicsoft.com）
Robert Sparks (rsparks@dynamicsoft.com)
ロバートスパークス（rsparks@dynamicsoft.com）
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Resnick、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] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（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] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6] Day、M.、Aggarwal、S。、およびJ. Vincent、「インスタントメッセージング /プレゼンスプロトコル要件」、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。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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.
[11] Schaad、J。、「高度な暗号化標準（AES）暗号化アルゴリズムの使用および暗号化メッセージ構文（CMS）」、RFC 3565、2003年7月。
This section provides the information to register the pres: presence URI .
このセクションでは、Pres：Presence URIを登録するための情報を提供します。
pres
プレス
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
構文は、RFC 2368で指定された既存のMailto：URI構文に従います。ABNFは次のとおりです。
PRES-URI = "pres:" [ to ] [ headers ]
to = mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *uric
hvalue = *uric
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]で定義されているエンコードされたメールボックス名を表し、シンボル「uRIC」はURLで有効な文字（RFC 2396 [10]で定義）を示します。
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]。
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は、Mailto：URIの密接に使用されます。つまり、Pres URIの呼び出しにより、ユーザーのインスタントメッセージングアプリケーションが開始され、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スキーム名を利用することが予想されます。
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の要件に十分な相互運用性を実現できます。
See Section 4.
セクション4を参照してください。
RFC 2779, RFC 2778
RFC 2779、RFC 2778
Jon Peterson [mailto:jon.peterson@neustar.biz]
Jon Peterson [Mailto：jon.peterson@neustar.biz]
This scheme is registered under the IETF tree. As such, IETF maintains change control.
このスキームは、IETFツリーの下に登録されています。そのため、IETFは変更制御を維持します。
Instant messaging service; presence service
インスタントメッセージングサービス。プレゼンスサービス
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録では、相互操作ゲートウェイを設計する際に興味深い問題について簡単に説明します。
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]。
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:
たとえば、宛先インスタント受信トレイが「PEPP：//example.com/ Fred」の場合、必要な文字変換を実行した後、結果のマッピングは次のとおりです。
im: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.
エクスペリエンスでは、このマッピングをエンドユーザーから非表示にすることが非常に好ましいことが示されています。可能であれば、基礎となるソフトウェアはマッピングを自動的に実行する必要があります。
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes.
著者は、彼のコメント、提案、熱意についてジョン・ラムズデルに感謝したいと思います。編集の修正については、Derek Atkinsに感謝します。
Author's Address
著者の連絡先
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
Phone: +1 925/363-8720
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。