Network Working Group J. Rosenberg
Request for Comments: 3856 dynamicsoft
Category: Standards Track August 2004
A Presence Event Package for the Session Initiation Protocol (SIP)
セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）
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
抽象
This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework.
この文書では、サブスクリプションおよびプレゼンスの通知のためのセッション開始プロトコル（SIP）の使用方法について説明します。存在は、ネットワーク上の他のユーザと通信するユーザの意欲と能力として定義されます。歴史的には、プレゼンスは「オンライン」と「オフライン」の指標に限定されてきました。ここでのプレゼンスの概念は広いです。サブスクリプションとプレゼンスの通知は、一般的なSIPイベント通知フレームワーク内イベントパッケージを定義することによって支持されています。このプロトコルはまた、一般的なプレゼンスプロファイル（CPP）フレームワークに準拠しています。
Table of Contents
目次
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Definitions ................................................. 3
4. Overview of Operation ....................................... 4
5. Usage of Presence URIs ...................................... 6
6. Presence Event Package ...................................... 7
6.1. Package Name .......................................... 8
6.2. Event Package Parameters .............................. 8
6.3. SUBSCRIBE Bodies ...................................... 8
6.4. Subscription Duration ................................. 9
6.5. NOTIFY Bodies ......................................... 9
6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
6.6.1. Authentication ................................. 10
6.6.2. Authorization .................................. 10
6.7. Notifier Generation of NOTIFY Requests ................ 11
6.8. Subscriber Processing of NOTIFY Requests .............. 13
6.9. Handling of Forked Requests ........................... 13
6.10. Rate of Notifications ................................. 14
6.11. State Agents .......................................... 14
6.11.1. Aggregation, Authentication, and Authorization. 14
6.11.2. Migration ..................................... 15
7. Learning Presence State ..................................... 16
7.1. Co-location ........................................... 16
7.2. REGISTER .............................................. 16
7.3. Uploading Presence Documents .......................... 17
8. Example Message Flow ........................................ 17
9. Security Considerations ..................................... 20
9.1. Confidentiality ....................................... 20
9.2. Message Integrity and Authenticity .................... 21
9.3. Outbound Authentication ............................... 22
9.4. Replay Prevention ..................................... 22
9.5. Denial of Service Attacks Against Third Parties ....... 22
9.6. Denial Of Service Attacks Against Servers ............. 23
10. IANA Considerations ......................................... 23
11. Contributors ................................................ 24
12. Acknowledgements ............................................ 25
13. Normative References ........................................ 25
14. Informative References ...................................... 26
15. Author's Address ............................................ 26
16. Full Copyright Statement .................................... 27
Presence, also known as presence information, conveys the ability and willingness of a user to communicate across a set of devices. RFC 2778 [10] defines a model and terminology for describing systems that provide presence information. In that model, a presence service is a system that accepts, stores, and distributes presence information to interested parties, called watchers. A presence protocol is a protocol for providing a presence service over the Internet or any IP network.
また、プレゼンス情報として知られている存在は、デバイスのセットを介して通信するためのユーザの能力と意思を伝えます。 RFC 2778 [10]プレゼンス情報を提供するシステムを説明するためのモデルおよび用語を定義します。そのモデルでは、プレゼンスサービスは店舗、受け入れ、および利害関係者、と呼ばウォッチャーにプレゼンス情報を配信するシステムです。プレゼンスプロトコルは、インターネットまたは任意のIPネットワーク上でプレゼンスサービスを提供するためのプロトコルです。
This document proposes the usage of the Session Initiation Protocol (SIP) [1] as a presence protocol. This is accomplished through a concrete instantiation of the general event notification framework defined for SIP [2], and as such, makes use of the SUBSCRIBE and NOTIFY methods defined there. Specifically, this document defines an event package, as described in RFC 3265 [2]. SIP is particularly well suited as a presence protocol. SIP location services already contain presence information, in the form of registrations. Furthermore, SIP networks are capable of routing requests from any user on the network to the server that holds the registration state for a user. As this state is a key component of user presence, those
この文書は、プレゼンスプロトコルとしてセッション開始プロトコル（SIP）[1]の使用を提案しています。これは、[2]は、そのようなものとして、そこに定義されたSUBSCRIBE及びNOTIFYメソッドを利用するSIPために定義された一般的なイベント通知フレームワークの具体的なインスタンス化を介して達成されます。具体的には、この文書は、イベントパッケージを定義し、RFC 3265に記載されているように[2]。 SIPは、プレゼンスプロトコルとして特に適しています。 SIPのロケーションサービスは、すでに登録の形で、プレゼンス情報が含まれています。また、SIPネットワークは、ユーザの登録状態を保持しているサーバにネットワーク上の任意のユーザからの要求をルーティングすることが可能です。この状態は、それらのユーザの存在の重要な要素であるように
SIP networks can allow SUBSCRIBE requests to be routed to the same server. This means that SIP networks can be reused to establish global connectivity for presence subscriptions and notifications.
SIPネットワークは、同じサーバーにルーティングするSUBSCRIBE要求を許可することができます。これは、SIPネットワークがプレゼンス登録と通知のためのグローバルな接続を確立するために再利用できることを意味します。
This event package is based on the concept of a presence agent, which is a new logical entity that is capable of accepting subscriptions, storing subscription state, and generating notifications when there are changes in presence. The entity is defined as a logical one, since it is generally co-resident with another entity.
このイベントパッケージは、サブスクリプションを受け入れるサブスクリプションの状態を保存し、プレゼンスの変更があったときに通知を生成することができる新しい論理エンティティであるプレゼンスエージェントの概念に基づいています。それは一般的に別のエンティティとの共存であるのでエンティティは、論理1として定義されます。
This event package is also compliant with the Common Presence Profile (CPP) framework that has been defined in [3]. This allows SIP for presence to easily interwork with other presence systems compliant to CPP.
このイベントパッケージには、[3]で定義された一般的なプレゼンスプロフィール（CPP）フレームワークに準拠しています。これは、簡単にCPPに準拠他のプレゼンスシステムと相互作用するために存在するかSIPすることができます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[4]及び対応する実装の要求レベルを示します。
This document uses the terms as defined in RFC 2778 [10]. Additionally, the following terms are defined and/or additionally clarified:
RFC 2778 [10]で定義されるように、この文書は、用語を使用します。また、以下の用語が定義され、および/または付加的に明らかにされています。
Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. This manipulation can be the side effect of some other action (such as sending a SIP REGISTER request to add a new Contact) or can be done explicitly through the publication of presence documents. We explicitly allow multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and Personal Digital Assistant (PDA)), each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages or send NOTIFY messages.
プレゼンスユーザエージェント（PUA）：プレゼンスユーザーエージェントは、プレゼンティティのプレゼンス情報を操作します。この操作は（新しい連絡先を追加するためのSIP REGISTERリクエストを送信するなど）他のアクションの副作用であるか、または存在文書の公表を通じて明示的に行うことができます。私たちは、明示的にプレゼンごとに複数の不要と思われるアプリケーションを可能にします。これにより、ユーザは独立に、プレゼンティティのための全体的なプレゼンス情報の成分を生成してそれぞれが、（例えば、携帯電話及びパーソナルデジタルアシスタント（PDA）など）は、多くのデバイスを持つことができることを意味します。不要と思われるアプリケーションは、プレゼンスシステムにデータをプッシュするが、彼らはメッセージをSUBSCRIBEまたはNOTIFYメッセージ送信、受信していないという点で、それの外にあります。
Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. A presence agent must have knowledge of the presence state of a presentity. This means that it must have access to presence data manipulated by PUAs for the presentity. One way to do this is by co-locating the PA with the proxy/registrar.
プレゼンスエージェント（PA）：プレゼンスエージェントは、SUBSCRIBE要求受信それらに応答して、プレゼンス状態の変化の通知を生成することが可能であるSIPユーザエージェントです。プレゼンスエージェントは、プレゼンティティのプレゼンス状態の知識を持っている必要があります。これは、プレゼンのために不要と思われるアプリケーションによって操作プレゼンスデータにアクセスしなければならないことを意味します。これを行う1つの方法は、プロキシ/レジストラにPAを同じ場所に配置することです。
Another way is to co-locate it with the presence user agent of the presentity. However, these are not the only ways, and this specification makes no recommendations about where the PA function should be located. A PA is always addressable with a SIP URI that uniquely identifies the presentity (i.e., sip:joe@example.com). There can be multiple PAs for a particular presentity, each of which handles some subset of the total subscriptions currently active for the presentity. A PA is also a notifier (defined in RFC 3265 [2]) that supports the presence event package.
もう一つの方法は、プレゼンティティのプレゼンスユーザエージェントとそれを同じ場所に配置することです。しかし、これらは唯一の方法ではありませんが、この仕様はPA機能を配置する場所についての提言を行うものではありません。 PAは常に一意プレゼンティティを識別するSIP URI（：joe@example.comすなわち、SIP）を用いてアドレス指定されます。プレゼンティティのための現在アクティブな総サブスクリプションのサブセットを処理各々が特定のプレゼンティティのための複数のPA、存在し得ます。 PAはまた、プレゼンス・イベント・パッケージをサポート（RFC 3265で定義された[2]）通知です。
Presence Server: A presence server is a physical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests. When acting as a PA, it is aware of the presence information of the presentity through some protocol means. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA.
プレゼンスサーバ：プレゼンスサーバは、プレゼンスエージェントとしてまたはSUBSCRIBE要求のプロキシサーバとして機能することができます物理的なエンティティです。 PAとして動作する場合、それはいくつかのプロトコル手段を介してプレゼンティティのプレゼンス情報を認識しています。プロキシとして動作する場合、SUBSCRIBEリクエストはPAとして作用することができる別のエンティティにプロキシされています。
Edge Presence Server: An edge presence server is a presence agent that is co-located with a PUA. It is aware of the presence information of the presentity because it is co-located with the entity that manipulates this presence information.
エッジプレゼンスサーバー：エッジプレゼンスサーバPUAと同じ場所に配置されたプレゼンスエージェントです。それは、このプレゼンス情報を操作するエンティティと同じ場所に配置されるので、それはプレゼンティティのプレゼンス情報を認識しています。
In this section, we present an overview of the operation of this event package. The overview describes behavior that is documented in part here, in part within the SIP event framework [2], and in part in the SIP specification [1], in order to provide clarity on this package for readers only casually familiar with those specifications. However, the detailed semantics of this package require the reader to be familiar with SIP events and the SIP specification itself.
このセクションでは、我々はこのイベントパッケージの動作の概要を提示します。概要では、これらの仕様にのみ何気なく精通し読者のために、このパッケージに明確さを提供するために、[1] SIPイベント・フレームワーク内で部分的に、ここで部分的に文書化されて動作を説明し[2]、及び部分的にSIP仕様で。しかし、このパッケージの詳細な意味は、SIPイベントとSIPの仕様自体に精通している読者を必要とします。
When an entity, the subscriber, wishes to learn about presence information from some user, it creates a SUBSCRIBE request. This request identifies the desired presentity in the Request-URI, using a SIP URI, SIPS URI [1] or a presence (pres) URI [3]. The SUBSCRIBE request is carried along SIP proxies as any other SIP request would be. In most cases, it eventually arrives at a presence server, which can either generate a response to the request (in which case it acts as the presence agent for the presentity), or proxy it on to an edge presence server. If the edge presence server handles the subscription, it is acting as the presence agent for the presentity. The decision at a presence server about whether to proxy or terminate the SUBSCRIBE is a local matter; however, we describe one way to effect such a configuration, using REGISTER.
エンティティ、加入者は、一部のユーザーからのプレゼンス情報について学ぶことを希望する場合、それはSUBSCRIBEリクエストを作成します。この要求は、SIP URIを使用して、リクエストURI内の所望のプレゼンティティを識別するURIをSIPS [1]または存在下（PRES）URI [3]。他のSIP要求があろうように、SUBSCRIBEリクエストは、SIPプロキシに沿って搬送されます。ほとんどの場合、それは、最終的にエッジプレゼンスサーバにプレゼンス（それはプレゼンティティのプレゼンスエージェントとして機能する場合）要求に対する応答を生成することができるいずれかのサーバ、またはプロキシを上に到達します。エッジプレゼンス・サーバは、サブスクリプションを処理する場合、それはプレゼンティティのプレゼンスエージェントとして機能しています。 SUBSCRIBEプロキシまたは終了するかどうかについてのプレゼンス・サーバでの決定は、ローカルの問題です。しかし、我々はREGISTERを使用して、このような構成に影響する1つの方法を説明します。
The presence agent (whether in the presence server or edge presence server) first authenticates the subscription, then authorizes it. The means for authorization are outside the scope of this protocol, and we expect that many mechanisms will be used. If authorized, a 200 OK response is returned. If authorization could not be obtained at this time, the subscription is considered "pending", and a 202 response is returned. In both cases, the PA sends an immediate NOTIFY message containing the state of the presentity and of the subscription. The presentity state may be bogus in the case of a pending subscription, indicating offline no matter what the actual state of the presentity, for example. This is to protect the privacy of the presentity, who may not want to reveal that they have not provided authorization for the subscriber. As the state of the presentity changes, the PA generates NOTIFYs containing those state changes to all subscribers with authorized subscriptions. Changes in the state of the subscription itself can also trigger NOTIFY requests; that state is carried in the Subscription-State header field of the NOTIFY, and would typically indicate whether the subscription is active or pending.
プレゼンスエージェント（プレゼンスサーバまたはエッジプレゼンスサーバであろうと）最初のサブスクリプションを認証するには、それを許可します。承認のための手段は、このプロトコルの範囲外であり、我々は多くのメカニズムが使用されることを期待しています。許可した場合、200 OK応答が返されます。認証がこの時点では得ることができなかった場合は、サブスクリプションは「保留中」とみなされ、202応答が返されます。どちらの場合も、PAは、プレゼンのサブスクリプションの状態を含有する即時NOTIFYメッセージを送信します。プレゼンの状態はどんなプレゼンの実際の状態、例えばオフラインでないことを示す、保留中のサブスクリプションの場合、偽のかもしれません。これは、彼らが加入者の許可を提供していないことを明らかにしたくないかもしれないプレゼンティティのプライバシーを保護することです。プレゼンの状態が変化すると、PAは、許可されたサブスクリプションを持つすべての加入者に、それらの状態の変化を含むNOTIFYをを生成します。サブスクリプション自体の状態の変化も、NOTIFYリクエストをトリガすることができます。その状態は、NOTIFYのSubscription-Stateヘッダフィールドで運ばれ、そして典型的にはサブスクリプションがアクティブまたは保留中であるかどうかを示すであろう。
The SUBSCRIBE message establishes a "dialog" with the presence agent. A dialog is defined in RFC 3261 [1], and it represents the SIP state between a pair of entities to facilitate peer-to-peer message exchanges. This state includes the sequence numbers for messages in both directions (SUBSCRIBE from the subscriber, NOTIFY from the presence agent), in addition to a route set and remote target URI. The route set is a list of SIP (or SIPS) URIs which identify SIP proxy servers that are to be visited along the path of SUBSCRIBE refreshes or NOTIFY requests. The remote target URI is the SIP or SIPS URI that identifies the target of the message - the subscriber, in the case of NOTIFY, or the presence agent, in the case of a SUBSCRIBE refresh.
SUBSCRIBEメッセージは、プレゼンスエージェントとの「対話」を確立します。ダイアログは、RFC 3261 [1]で定義され、それは、ピア・ツー・ピアのメッセージ交換を容易にするために、エンティティの対の間のSIP状態を表しています。この状態は、ルートセットとリモートターゲットURIに加えて、（プレゼンスエージェントからNOTIFY、加入者からSUBSCRIBE）両方向のメッセージのシーケンス番号を含みます。ルートセットは、リフレッシュをSUBSCRIBEまたはNOTIFYリクエストの経路に沿って訪問されるSIPプロキシサーバを識別するSIP（またはSIPS）URIのリストです。リモートターゲットURIは、SIPであるか、またはメッセージのターゲットを識別するURI SIPS - SUBSCRIBEリフレッシュの場合には、NOTIFYの場合、又は、プレゼンスエージェントに、加入者。
SIP provides a procedure called record-routing that allows for proxy servers to request to be on the path of NOTIFY messages and SUBSCRIBE refreshes. This is accomplished by inserting a URI into the Record-Route header field in the initial SUBSCRIBE request.
SIPプロキシサーバは、NOTIFYメッセージのパス上にあるとリフレッシュを購読する要求することを可能にし、レコード・ルーティングと呼ばれる手順を提供します。これは最初のSUBSCRIBEリクエストにRecord-RouteヘッダフィールドにURIを挿入することによって達成されます。
The subscription persists for a duration that is negotiated as part of the initial SUBSCRIBE. The subscriber will need to refresh the subscription before its expiration, if they wish to retain the subscription. This is accomplished by sending a SUBSCRIBE refresh within the same dialog established by the initial SUBSCRIBE. This SUBSCRIBE is nearly identical to the initial one, but contains a tag in the To header field, a higher CSeq header field value, and possibly a set of Route header field values that identify the path of proxies the request is to take.
サブスクリプションは、初期の一部SUBSCRIBEとして交渉されている期間中持続します。彼らは、サブスクリプションを保持したい場合、加入者は、その満了前にサブスクリプションをリフレッシュする必要があります。これは、SUBSCRIBE初期によって確立された同じダイアログ内にリフレッシュSUBSCRIBE送信することによって達成されます。これは、SUBSCRIBE初期のものとほぼ同一であるが、フィールド、高いCSeqヘッダーフィールド値、及びおそらく要求が取ることにあるプロキシのパスを識別Routeヘッダーフィールド値のセットをヘッダにタグを含んでいます。
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state. In fact, behavior of the presence agent for handling a SUBSCRIBE request with Expires of zero is no different than for any other expiration value; pending or authorized SUBSCRIBE requests result in a triggered NOTIFY with the current presentity and subscription state.
ゼロの値（サブスクリプションの持続時間を示す）Expiresヘッダフィールドと、加入者は、ダイアログ内で、SUBSCRIBE送信することによって、サブスクリプションを終了することができます。これは、サブスクリプションの即時終了を引き起こします。 NOTIFY要求は、最新の状態で存在するエージェントによって生成されます。実際には、ゼロの有効期限とSUBSCRIBEリクエストを処理するためのプレゼンス・エージェントの挙動は、他の有効期限の値よりも違いはありません。現在のプレゼンおよびサブスクリプションの状態でNOTIFYトリガーに保留中またはSUBSCRIBE認可要求が発生します。
The presence agent can terminate the subscription at any time. To do so, it sends a NOTIFY request with a Subscription-State header field indicating that the subscription has been terminated. A reason parameter can be supplied which provides the reason.
プレゼンスエージェントは、いつでも購読を終了することができます。そのためには、サブスクリプションが終了したことを示すSubscription-StateヘッダフィールドとNOTIFYリクエストを送信します。理由パラメータは、理由を提供する供給することができます。
It is also possible to fetch the current presence state, resulting in a one-time notification containing the current state. This is accomplished by sending a SUBSCRIBE request with an immediate expiration.
現在の状態を含む一回の通知で、その結果、現在のプレゼンス状態を取得することも可能です。これはすぐに期限切れとSUBSCRIBEリクエストを送信することによって達成されます。
A presentity is identified in the most general way through a presence URI [3], which is of the form pres:user@domain. These URIs are resolved to protocol specific URIs, such as the SIP or SIPS URI, through domain-specific mapping policies maintained on a server.
ユーザ@ドメイン：プレゼンフォームPRESであるプレゼンスURI [3]を介して最も一般的な方法で識別されます。これらのURIは、SIPなどのプロトコル特定のURIに解決またはサーバ上に保持ドメイン固有のマッピングポリシーを介して、URIをSIPSれます。
It is very possible that a user will have both a SIP (and/or SIPS) URI and a pres URI to identify both themself and other users. This leads to questions about how these URI relate and which are to be used.
ユーザがその人自身と他のユーザーの両方を識別するために、SIP（および/またはSIPS）URIとPRES URIの両方を有することが非常に可能です。これは、これらのURIが関係している使用される方法についての質問につながります。
In some instances, a user starts with one URI format, such as the pres URI, and learns a URI in a different format through some protocol means. As an example, a SUBSCRIBE request sent to a pres URI will result in learning a SIP or SIPS URI for the presentity from the Contact header field of the 200 OK to the SUBSCRIBE request. As another example, a DNS mechanism might be defined that would allow lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one URI is learned from another through protocol means, those means will often provide some kind of scoping that limit the lifetime of the learned URI. DNS, for example, provides a TTL which would limit the scope of the URI. These scopes are very useful to avoid stale or conflicting URIs for identifying the same resource. To ensure that a user can always determine whether a learned URI is still valid, it is RECOMMENDED that systems which provide lookup services for presence URIs have some kind of scoping mechanism.
いくつかの例では、ユーザは、PRES URIとして、1つのURIの形式で始まり、いくつかのプロトコル手段を介して別の形式でURIを学習します。一例として、PRESに送信されたSUBSCRIBEリクエストURIは、SIPを学習することになるか、SUBSCRIBEリクエストに対する200 OKのContactヘッダフィールドからプレゼンティティのURIをSIPS。別の例として、DNSメカニズムは、SIPを得るために、PRES URIのルックアップを許可またはURIをSIPSなるように定義されるかもしれません。 1つのURIは、プロトコル手段を介して相互に学習さのケースでは、これらの手段は、多くの場合、学んだURIの寿命を制限するスコープのいくつかの種類を提供します。 DNSは、例えば、URIの範囲を制限するTTLを提供します。これらのスコープは、同じリソースを識別するための古いまたは競合URIを避けるために非常に便利です。ユーザーは常に学んURIがまだ有効であるかどうかを判断できるようにするために、存在するURIの検索サービスを提供するシステムは、スコープメカニズムのいくつかの種類を持っていることが推奨されます。
If a subscriber is only aware of the protocol-independent pres URI for a presentity, it follows the procedures defined in [5]. These procedures will result in the placement of the pres URI in the Request-URI of the SIP request, followed by the usage of the DNS procedures defined in [5] to determine the host to send the SIP request to. Of course, a local outbound proxy may alternatively be used, as specified in RFC 3261 [1]. If the subscriber is aware of both the protocol-independent pres URI and the SIP or SIPS URI for the same presentity, and both are valid (as discussed above) it SHOULD use the pres URI format. Of course, if the subscriber only knows the SIP URI for the presentity, that URI is used, and standard RFC 3261 processing will occur. When the pres URI is used, any proxies along the path of the SUBSCRIBE request which do not understand the URI scheme will reject the request. As such, it is expected that many systems will be initially deployed that only provide users with a SIP URI.
加入者は、プレゼンティティのためのプロトコル非依存PRES URIのみを認識している場合は、[5]で定義された手順に従います。これらの手順は、にSIP要求を送信するホストを決定するために、[5]で定義されたDNS手順の使用が続くSIP要求のリクエストURIにPRES URIの配置をもたらすであろう。もちろん、ローカルアウトバウンドプロキシが代わりに使用されてもよい、RFC 3261で指定されるように[1]。加入者は、プロトコルに依存しPRES URIとSIPの両方を認識しているか、同じプレゼンティティのURIをSIPS、および（上述のように）の両方が有効である場合には、PRES URI形式を使用するべきです。もちろん、加入者は、唯一のURIが使用され、標準のRFC 3261処理が発生することを、プレゼン用のSIP URIを知っている場合。ときにURIが使用されているPRES、要求を拒否しますURIスキームを理解していないSUBSCRIBEリクエストのパスに沿った任意のプロキシ。このように、多くのシステムが最初にのみSIP URIをユーザーに提供することに配備されることが期待されます。
SUBSCRIBE messages also contain logical identifiers that define the originator and recipient of the subscription (the To and From header fields). These headers can take either a pres or SIP URI. When the subscriber is aware of both a pres and SIP URI for its own identity, it SHOULD use the pres URI in the From header field. Similarly, when the subscriber is aware of both a pres and a SIP URI for the desired presentity, it SHOULD use the pres URI in the To header field.
SUBSCRIBEメッセージは、サブスクリプションの（およびヘッダフィールドから）発信者と受信者を定義する論理識別子を含みます。これらのヘッダはPRESまたはSIP URIのどちらかを取ることができます。加入者は、自身のアイデンティティのためのPRESとSIP URIの両方を知っている場合、それはヘッダフィールドからPRES URIを使用すべきです。同様に、加入者がPRESおよび所望プレゼン用のSIP URIの両方を知っている場合、それはフィールドをヘッダーにPRES URIを使用すべきです。
The usage of the pres URI instead of the SIP URI within the SIP message supports interoperability through gateways to other CPP-compliant systems. It provides a protocol-independent form of identification which can be passed between systems. Without such an identity, gateways would be forced to map SIP URIs into the addressing format of other protocols. Generally, this is done by converting the SIP URI to the form <foreign-protocol-scheme>:<encoded SIP URI>@<gateway>. This is commonly done in email systems, and has many known problems. The usage of the pres URI is a SHOULD, and not a MUST, to allow for cases where it is known that there are no gateways present, or where the usage of the pres URI will cause interoperability problems with SIP components that do not support the pres URI.
SIPメッセージ内のPRES URIの代わりに、SIP URIの使用は他のCPP準拠のシステムにゲートウェイを介して相互運用性をサポートしています。これは、システム間で渡すことができる特定のプロトコルに依存しない形を提供します。こうしたアイデンティティがなければ、ゲートウェイは、他のプロトコルのアドレッシングフォーマットにSIP URIをマッピングすることを余儀なくされるだろう。 <符号化されたSIP URI> @ <ゲートウェイ>：一般的に、このフォームに<外国プロトコルスキーム>をSIP URIに変換することによって行われます。これは、一般の電子メールシステムで行われ、多くの既知の問題が発生しています。 URIは、存在していないゲートウェイ存在している、またはすることが知られている例を可能にする必要があり、してはならない、あるPRESの利用PRESの利用はURIがサポートされていないSIPコンポーネントとの相互運用性の問題が発生します場所PRES URI。
The Contact, Record-Route and Route fields do not identify logical entities, but rather concrete ones used for SIP messaging. SIP [1] specifies rules for their construction.
連絡先、レコード・ルートおよびルートのフィールドは、論理的なエンティティを識別しませんが、SIPメッセージングのために使用さではなく、具体的なもの。 SIPは、[1]それらの構築のための規則を指定します。
The SIP event framework [2] defines a SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 [2].
SIPイベント・フレームワークは[2]に加入し、イベントの通知を受信するためのSIP拡張機能を定義します。これは、イベントパッケージとして知られている具体的な拡張、これらのイベントの多くの側面の定義を残します。この文書では、イベントパッケージとしての資格。このセクションでは、RFC 3265 [2]により、すべてのイベントパッケージのために必要な情報を記入します。
The name of this package is "presence". As specified in RFC 3265 [2], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests.
このパッケージの名前は「存在」です。 RFC 3265で指定された[2]、この値はSUBSCRIBE及びNOTIFYリクエスト中に存在するイベントヘッダフィールドに現れます。
Example:
例：
Event: presence
イベント：プレゼンス
The SIP event framework allows event packages to define additional parameters carried in the Event header field. This package, presence, does not define any additional parameters.
SIPイベント・フレームワークは、イベントパッケージはイベントヘッダフィールド内で運ば追加パラメータを定義することを可能にします。このパッケージには、存在は、追加のパラメータを定義していません。
A SUBSCRIBE request MAY contain a body. The purpose of the body depends on its type. Subscriptions will normally not contain bodies.
SUBSCRIBEリクエストは、本体を含むかもしれません。体の目的は、その種類によって異なります。サブスクリプションは、通常、体は含まれません。
The Request-URI, which identifies the presentity, combined with the event package name, is sufficient for presence.
イベントパッケージ名と組み合わせてプレゼンティティを識別するリクエストURIは、存在するのに十分です。
One type of body that can be included in a SUBSCRIBE request is a filter document. These filters request that only certain presence events generate notifications, or would ask for a restriction on the set of data returned in NOTIFY requests. For example, a presence filter might specify that the notifications should only be generated when the status of the user's instant inbox [10] changes. It might also say that the content of these notifications should only contain the status of the instant inbox. Filter documents are not specified in this document, and at the time of writing, are expected to be the subject of future standardization activity.
SUBSCRIBEリクエストに含まれることができる身体の一つのタイプは、フィルタドキュメントです。これらのフィルタは、特定のプレゼンスイベントが通知を生成することを要求、またはデータのセットに制限するために頼むでNOTIFYリクエストを返されました。例えば、プレゼンスフィルタは、通知がときにのみ、ユーザーのインスタント受信ボックスのステータスが[10]の変化を生成する必要があることを指定できます。また、これらの通知の内容だけで瞬時受信トレイの状態を含めるべきであると言うかもしれません。フィルタの文書は、この文書で指定されていない、と書いている時点で、将来の標準化活動の対象となることが期待されています。
Honoring of these filters is at the policy discretion of the PA.
これらのフィルタの礼拝は、PAの政策裁量です。
If the SUBSCRIBE request does not contain a filter, this tells the PA that no filter is to be applied. The PA SHOULD send NOTIFY requests at the discretion of its own policy.
SUBSCRIBEリクエストはフィルターが含まれていない場合、これはフィルタが適用されないことをPAに指示します。 PAは、独自の政策の裁量でNOTIFYリクエストを送るべきです。
User presence changes as a result of many events. Some examples are:
ユーザーの存在は、多くのイベントの結果として変更されます。いくつかの例は以下のとおりです。
o Turning on and off of a cell phone
携帯電話のオフとオンにするO
o Modifying the registration from a softphone
ソフトフォンからの登録を変更するO
o Changing the status on an instant messaging tool
インスタントメッセージングツールのステータスを変更するO
These events are usually triggered by human intervention, and occur with a frequency on the order of seconds to hours. As such, subscriptions should have an expiration in the middle of this range, which is roughly one hour. Therefore, the default expiration time for subscriptions within this package is 3600 seconds. As per RFC 3265 [2], the subscriber MAY specify an alternate expiration in the Expires header field.
これらのイベントは、通常、人間の介入によってトリガされ、時間秒程度の頻度で発生しています。このように、サブスクリプションは、約1時間であり、この範囲の真ん中に有効期限を有するべきです。そのため、このパッケージ内のサブスクリプションのデフォルトの有効期限は3600秒です。 ExpiresヘッダーフィールドにRFC 3265に従って、[2]、加入者は、別の有効期限を指定するかもしれません。
As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE.
RFC 3265に記載されているように、[2]、NOTIFYメッセージは、サブスクライブリソースの状態を記述する体を含むであろう。 AcceptヘッダーフィールドはSUBSCRIBEから省略された場合には、この本体は、SUBSCRIBEのAcceptヘッダーフィールドにリストされた形式、またはパッケージ固有のデフォルトです。
In this event package, the body of the notification contains a presence document. This document describes the presence of the presentity that was subscribed to. All subscribers and notifiers MUST support the "application/pidf+xml" presence data format described in [6]. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/pidf+xml". If the header field is present, it MUST include "application/pidf+xml", and MAY include any other types capable of representing user presence.
このイベントパッケージでは、通知の本文は、プレゼンスドキュメントが含まれています。この文書では、に加入したプレゼンティティのプレゼンスを示しています。すべてのサブスクライバとノーティファイア[6]に記載の「アプリケーション/ PIDF + XML」プレゼンス・データ・フォーマットをサポートしなければなりません。リクエストがAcceptヘッダーフィールドを含むかもしれ購読。このようなヘッダフィールドが存在しない場合、それは「アプリケーション/ PIDF + XML」のデフォルト値を有しています。ヘッダフィールドが存在する場合、それは「アプリケーション/ PIDF + XML」を含まなければなりません、そして、ユーザのプレゼンスを示すことができる任意の他のタイプを含むかもしれません。
Based on the proxy routing procedures defined in the SIP specification, the SUBSCRIBE request will arrive at a presence agent (PA). This subsection defines package-specific processing at the PA of a SUBSCRIBE request. General processing rules for requests are covered in Section 8.2 of RFC 3261 [1], in addition to general SUBSCRIBE processing in RFC 3265 [2].
SIP仕様で定義されたプロキシルーティング手順に基づいて、SUBSCRIBEリクエストは、プレゼンスエージェント（PA）に到着します。このサブセクションでは、SUBSCRIBEリクエストのPAでパッケージ固有の処理を定義します。リクエストのための一般的な処理規則は、[1]、一般的に加えて、RFC 3265で処理をSUBSCRIBE RFC 3261のセクション8.2でカバーされている[2]。
User presence is highly sensitive information. Because the implications of divulging presence information can be severe, strong requirements are imposed on the PA regarding subscription processing, especially related to authentication and authorization.
ユーザーのプレゼンスは非常に機密性の高い情報です。漏洩プレゼンス情報の意味合いが厳しいことがあるため、強力な要件は、特に、認証と承認に関連し、サブスクリプション処理に関するPAに課せられています。
A presence agent MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [1]. Note that digest is mandatory to implement, as specified in RFC 3261.
プレゼンスエージェントは、すべてのサブスクリプション要求を認証する必要があります。この認証は、RFC 3261で定義されたメカニズムのいずれかを用いて行うことができる[1]。 RFC 3261で指定されたダイジェストは、実装するために必須であることに注意してください。
In single-domain systems, where the subscribers all have shared secrets with the PA, the combination of digest authentication over Transport Layer Security (TLS) [7] provides a secure and workable solution for authentication. This use case is described in Section 26.3.2.1 of RFC 3261 [1].
加入者すべてがPAと秘密を共有している単一ドメインのシステムでは、トランスポート層セキュリティ（TLS）を超えるダイジェスト認証の組み合わせは、[7]認証のための安全かつ実行可能なソリューションを提供します。このユースケースは、RFC 3261のセクション26.3.2.1に記載されている[1]。
In inter-domain scenarios, establishing an authenticated identity of the subscriber is harder. It is anticipated that authentication will often be established through transitive trust. SIP mechanisms for network asserted identity can be applied to establish the identity of the subscriber [11].
ドメイン間のシナリオでは、加入者の認証されたアイデンティティを確立することは困難です。認証は、多くの場合、推移的な信頼を介して確立されることが予想されます。ネットワークのSIPメカニズムは、アイデンティティが加入者[11]のアイデンティティを確立するために適用することができるアサート。
A presentity MAY choose to represent itself with a SIPS URI. By "represent itself", it means that the user represented by the presentity hands out, on business cards, web pages, and so on, a SIPS URI for their presentity. The semantics associated with this URI, as described in RFC 3261 [1], require TLS usage on each hop between the subscriber and the server in the domain of the URI. This provides additional assurances (but no absolute guarantees) that identity has been verified at each hop.
プレゼンはSIPS URIで自身を表現するために選ぶかもしれません。 「自分自身を表現する」ことで、ユーザーは、その上で自分のプレゼンのためのSIPS URIを名刺、ウェブページ上で、アウトプレゼン手に代表される、とすることを意味します。このURIに関連付けられた意味は、RFC 3261に記載されているように[1]、URIのドメイン内の加入者とサーバとの間の各ホップにTLSの使用を必要とします。これは、アイデンティティが各ホップで確認されていることを、追加の保証（ただし、絶対的な保証）を提供します。
Another mechanism for authentication is S/MIME. Its usage with SIP is described fully in RFC 3261 [1]. It provides an end-to-end authentication mechanism that can be used for a PA to establish the identity of the subscriber.
認証のための別のメカニズムは、S / MIMEです。 SIPとの使用は、完全にRFC 3261に記載されている[1]。これは、加入者のアイデンティティを確立するためにPAのために使用することができ、エンドツーエンドの認証メカニズムを提供します。
Once authenticated, the PA makes an authorization decision. A PA MUST NOT accept a subscription unless authorization has been provided by the presentity. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. Back end authorization servers, such as a DIAMETER [12] server, can also be
認証されると、PAは、認可決定を行います。認可がプレゼンによって提供されていない限り、PAは、サブスクリプションを受け入れてはいけません。認可が提供される手段は、この文書の範囲外です。認可は、おそらく、Webページで指定したアクセスリストによって事前に提供されている可能性があります。認可は、標準化されたアクセス制御リスト、ドキュメントのいくつかの種類のアップロードによって提供されている可能性があります。直径などのバックエンド認証サーバ、[12]サーバーは、することもできます
used. It is also useful to be able to query the user for authorization following the receipt of a subscription request for which no authorization information has been provided. The "watcherinfo" event template package for SIP [8] defines a means by which a presentity can become aware that a user has attempted to subscribe to it, so that it can then provide an authorization decision.
中古。また、何の認証情報が提供されていないするサブスクリプション要求の受信、次の権限をユーザに問い合わせることができて便利です。 SIPのための「watcherinfo」イベントテンプレートパッケージは、[8]それは、その後の認可決定を提供できるようにプレゼンは、ユーザーがそれに加入しようとしたことを自覚することができる手段を定義します。
Authorization decisions can be very complex. Ultimately, all authorization decisions can be mapped into one of three states: rejected, successful, and pending. Any subscription for which the client is authorized to receive information about some subset of presence state at some points in time is a successful subscription. Any subscription for which the client will never receive any information about any subset of the presence state is a rejected subscription. Any subscription for which it is not yet known whether it is successful or rejected is pending. Generally, a pending subscription occurs when the server cannot obtain authorization at the time of the subscription, but may be able to do so at a later time, perhaps when the presentity becomes available.
認可の決定は非常に複雑になることがあります。最終的に、すべての許可決定の3つの状態のいずれかにマップすることができます。拒否され、成功した、と保留します。クライアントが時間内にいくつかの点でのプレゼンス状態のサブセットに関する情報を受信することが許可されている任意のサブスクリプションが成功したサブスクリプションです。クライアントは、プレゼンス状態の任意のサブセットに関する情報を受け取ることはありませんそのため、任意のサブスクリプションは拒否され、サブスクリプションです。まだそれが成功したかどうか知られているか、または拒否されていない任意のサブスクリプションが保留されています。一般的に、保留中のサブスクリプションでは、サーバは、サブスクリプションの時点で許可を取得できない場合に発生しますが、プレゼンが利用可能になるかもしれないと、後の時点でそうすることができるかもしれません。
The appropriate response codes for conveying a successful, rejected, or pending subscription (200, 403 or 603, and 202, respectively) are described in RFC 3265 [2].
成功を搬送するための適切な応答コード、（それぞれ200、403、または603、および202）加入を拒否し、または保留中のRFC 3265に記載されている[2]。
If the resource is not in a meaningful state, RFC 3265 [2] allows the body of the initial NOTIFY to be empty. In the case of presence, that NOTIFY MAY contain a presence document. This document would indicate whatever presence state the subscriber has been authorized to see; it is interpreted by the subscriber as the current presence state of the presentity. For pending subscriptions, the state of the presentity SHOULD include some kind of textual note that indicates a pending status.
リソースは、意味のある状態にない場合は、RFC 3265 [2]初期の本体は空であるNOTIFYができます。存在する場合は、通知することをプレゼンス文書を含むかもしれません。この文書では、加入者が見ることを許可されたものは何でもプレゼンス状態を示します。これは、プレゼンティティの現在のプレゼンス状態として加入者によって解釈されます。保留中のサブスクリプションの場合、プレゼンティティの状態が保留状態を示してテキストノートのいくつかの種類を含むべきです。
Polite blocking, as described in [13], is possible by generating a 200 OK to the subscription even though it has been rejected (or marked pending). Of course, an immediate NOTIFY will still be sent. The contents of the presence document in such a NOTIFY are at the discretion of the implementor, but SHOULD be constructed in such a way as to not reveal to the subscriber that their request has actually been blocked. Typically, this is done by indicating "offline" or equivalent status for a single contact address.
丁寧ブロッキングは、[13]に記載されているように、それは拒否され（または保留中のマーク）されているにもかかわらず、サブスクリプションに200 OKを生成することによって可能です。もちろん、すぐにはNOTIFY、まだ送信されます。そのようなNOTIFYにおけるプレゼンス文書の内容は、実装者の裁量であるが、それらの要求が実際に遮断されたことを加入者に明らかにしないような方法で構成されるべきです。典型的には、これは、単一の連絡先のための「オフライン」または同等の状態を示すことによって行われます。
RFC 3265 details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the presence event package.
RFC 3265は、NOTIFYメッセージのフォーマットと構造を詳しく説明します。ただし、パッケージは中性または偽の状態情報を生成する方法を、リソースの状態を計算する方法を、NOTIFY、および状態情報が完全または部分的であるかどうかを送信する際の詳細な情報を提供するために義務付けられています。このセクションでは、プレゼンスイベントパッケージのためにそれらの詳細を説明します。
A PA MAY send a NOTIFY at any time. Typically, it will send one when the state of the presentity changes. The NOTIFY request MAY contain a body indicating the state of the presentity. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. This protocol in no way limits the scope of such policies. As a baseline, a reasonable policy is to generate notifications when the state of any of the presence tuples changes. These notifications would contain the complete and current presence state of the presentity as known to the presence agent. Future extensions can be defined that allow a subscriber to request that the notifications contain changes in presence information only, rather than complete state.
PAは、いつでもNOTIFYを送信することができます。一般的に、それは1を送信する際にプレゼンの状態が変化しました。 NOTIFYリクエストは、プレゼンティティの状態を示す体を含むかもしれません。 NOTIFYれる時間は、特定の加入者のために送られ、その通知内ボディの内容は、サブスクリプションを管理する許可ポリシーによって指定されたルールの対象となっています。決してこのプロトコルは、そのような政策の範囲を制限します。ベースラインとして、合理的なポリシーが存在する任意の状態が変化しタプルときに通知を生成することです。プレゼンスエージェントに知られているように、これらの通知は、プレゼンの完全かつ現在のプレゼンス状態が含まれます。将来の拡張機能は、加入者が通知がプレゼンス情報の変更だけではなく、完全な状態が含まれていることを要求することを可能にするように定義することができます。
In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a presence document with the current state of the presentity. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [2], the Subscription-State header field indicates the state of the subscription.
最終的な許可が判定された場合、保留中のサブスクリプションの場合には、NOTIFY送信することができます。認可判定の結果が成功した場合は、NOTIFYが送信されるべきであり、プレゼンティティの現在の状態で存在する文書を含むべきです。サブスクリプションが拒否された場合、NOTIFYが送られるかもしれません。 RFC 3265に記載されているように、[2]、Subscription-Stateヘッダフィールドは、サブスクリプションの状態を示しています。
The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/pidf+xml" if no Accept header field was present.
いかなるヘッダフィールドを受け入れるとNOTIFYのボディは、最新のSUBSCRIBEリクエストにAcceptヘッダーフィールドにリストされたタイプのいずれかを使用して、またはタイプ「アプリケーション/ PIDF + XML」を使用して送信されてはならない存在でした。
The means by which the PA learns the state of the presentity are also outside the scope of this recommendation. Registrations can provide a component of the presentity state. However, the means by which a PA uses registrations to construct a presence document are an implementation choice. If a PUA wishes to explicitly inform the presence agent of its presence state, it should explicitly publish the presence document (or its piece of it) rather than attempting to manipulate their registrations to achieve the desired result.
PAは、プレゼンティティの状態を学習する手段は、この標準の範囲外でもあります。登録は、プレゼンティティの状態の成分を提供することができます。しかし、PAは、プレゼンス文書を構築するために登録を使用する手段は、実装の選択です。 PUAが明示的にそのプレゼンス状態のプレゼンスエージェントに通知することを希望する場合は、明示的ではなく、所望の結果を達成するために彼らの登録を操作しようとするよりも、プレゼンス文書（またはそれのその部分）を公開する必要があります。
For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME. Since the NOTIFY is generated by the presence server, which may not have access to the key of the user represented by the presentity, it will frequently be the case that the NOTIFY is signed by a third party. It is RECOMMENDED that the signature be by an authority over the domain of the presentity. In other words, for a user pres:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com.
プライバシーの理由から、頻繁に通知の内容を暗号化する必要があります。これは、S / MIMEを使用して達成することができます。 SUBSCRIBEリクエストのFromフィールドで識別される暗号化は、加入者の鍵を使用して行うことができます。同様に、通知の整合性は、加入者にとって重要です。このようにして、通知の内容は、S / MIMEを使用して認証とメッセージ整合性を提供することができます。 NOTIFYは、プレゼンティティによって表されるユーザのキーへのアクセス権を持っていない可能性がある、プレゼンスサーバによって生成されるので、それはしばしばザがNOTIFY場合が第三者によって署名されるであろう。署名がプレゼンのドメインに対する権限によってすることをお勧めします。つまり、ユーザーPRESのために：user@example.com、NOTIFYのある署名は、example.comの権威であるべきです。
RFC 3265 [2] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state.
RFC 3265 [2]コヒーレントリソース状態を形成するのに必要なロジックを含むNOTIFYリクエストを受信すると、加入者続く工程を説明するために、イベント・パッケージにそれを残します。
In this specification, each NOTIFY contains either no presence document, or a document representing the complete and coherent state of the presentity. Within a dialog, the presence document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the presence document present in the NOTIFY with the next highest CSeq value is used. Extensions which specify the use of partial state for presentities will need to dictate how coherent state is achieved.
本明細書では、各NOTIFYにはプレゼンス文書、またはプレゼンティティの完全かつコヒーレント状態を表す文書のいずれかが含まれていません。ダイアログ内で、最高CSeqヘッダーフィールド値を持つNOTIFYリクエストでプレゼンス文書は、現在のものです。それはNOTIFYでない文書が存在しない場合、次の最高のCSeq値とNOTIFYにおけるプレゼンス文書存在が使用されます。プレゼンのための部分的な状態の使用を指定する拡張機能が達成される方法をコヒーレント状態を指示する必要があります。
RFC 3265 [2] requires each package to describe handling of forked SUBSCRIBE requests.
RFC 3265 [2] SUBSCRIBEフォーク要求の処理を記述するために各パッケージが必要です。
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single PA is generating notifications for a particular subscription to a particular presentity. The result of this is that a presentity can have multiple PAs active, but these should be homogeneous, so that each can generate the same set of notifications for the presentity. Supporting heterogeneous PAs, each of which generates notifications for a subset of the presence data, is complex and difficult to manage. Doing so would require the subscriber to act as the aggregator for presence data. This aggregation function can only reasonably be performed by agents representing the presentity. Therefore, if aggregation is needed, it MUST be done in a PA representing the presentity.
この仕様は、最初のSUBSCRIBEリクエストを発する結果として構築される単一の対話を可能にします。これは、単一のPAは、特定のプレゼンに特定のサブスクリプションの通知を生成していることを保証します。この結果は、プレゼンティティがアクティブ複数のPAを有することができることであるが、各々がプレゼンティティの通知の同じセットを生成することができるように、これらは、均質であるべきです。プレゼンスデータのサブセットに対して通知を生成各々が異種のPAを、支持、管理が複雑かつ困難です。そうすることでプレゼンスデータのためのアグリゲータとして機能するように、加入者が必要となります。この集約関数は、合理的にプレゼンティティを表すエージェントによって行うことができます。集約が必要な場合はそのため、それがプレゼンを表すPAで行わなければなりません。
Section 4.4.9 of RFC 3265 [2] describes the processing that is required to guarantee the creation of a single dialog in response to a SUBSCRIBE request.
RFC 3265のセクション4.4.9には、[2] SUBSCRIBEリクエストに応じて、単一のダイアログの作成を保証するために必要とされる処理を説明します。
RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent.
RFC 3265 [2]通知が送信できる最大レートを指定するためにそれぞれのパッケージを必要とします。
A PA SHOULD NOT generate notifications for a single presentity at a rate of more than once every five seconds.
PAは、5秒ごとに1回以上の割合で、単一のプレゼンのための通知を生成するべきではありません。
RFC 3265 [2] requires each package to consider the role of state agents in the package, and if they are used, to specify how authentication and authorization are done.
RFC 3265 [2]は、パッケージの状態エージェントの役割を検討するために、それらが使用されている場合は、認証と承認が行われる方法を指定するには、各パッケージが必要です。
State agents are core to this package. Whenever the PA is not co-located with the PUA for the presentity, the PA is acting as a state agent. It collects presence state from the PUA, and aggregates it into a presence document. Because there can be multiple PUA, a centralized state agent is needed to perform this aggregation. That is why state agents are fundamental to presence. Indeed, they have a specific term that describes them - a presence server.
州のエージェントは、このパッケージのコアです。 PAは、プレゼン用のPUAと同じ場所に配置されていないときはいつでも、PAは状態剤として作用しています。これは、PUAからのプレゼンス状態を収集し、プレゼンス文書に集約します。複数のPUAが存在する可能性があるため、中央集権国家のエージェントは、この集計を実行するために必要とされます。状態のエージェントが存在の基本である理由です。プレゼンスサーバ - 実際に、彼らはそれらを説明し、特定の用語を持っています。
The means by which aggregation is done in the state agent is purely a matter of policy. The policy will typically combine the desires of the presentity along with the desires of the provider. This document in no way restricts the set of policies which may be applied.
凝集は状態のエージェントで実行する手段は、純粋に政策の問題です。ポリシーは、通常、プロバイダの欲望と一緒にプレゼンの欲望を結合します。決してこの文書を適用することができる一連のポリシーを制限します。
However, there is clearly a need for the state agent to have access to the state of the presentity. This state is manipulated by the PUA. One way in which the state agent can obtain this state is to subscribe to it. As a result, if there were 5 PUA manipulating presence state for a single presentity, the state agent would generate 5 subscriptions, one to each PUA. For this mechanism to be effective, all PUA SHOULD be capable of acting as a PA for the state that they manipulate, and that they authorize subscriptions that can be authenticated as coming from the domain of the presentity.
しかし、プレゼンティティの状態へのアクセス権を持っている状態エージェントの必要性が明らかに存在します。この状態は、PUAによって操作されます。状態エージェントは、この状態を得ることが可能な一つの方法は、それを購読することです。単一のプレゼンティティのプレゼンス状態を操作する5 PUAがあった場合、結果として、状態剤は5つのサブスクリプション、各PUAに1を生成します。このメカニズムを有効にするには、すべてのPUAは、彼らが操作している状態のためのPAとして機能することが可能であるべきであり、彼らはプレゼンのドメインから来たものとして認証することができるサブスクリプションを許可していること。
The usage of state agents does not significantly alter the way in which authentication is done by the PA. Any of the SIP authentication mechanisms can be used by a state agent. However, digest authentication will require the state agent to be aware of the shared secret between the presentity and the subscriber. This will require some means to securely transfer the shared secrets from the presentity to the state agent.
状態の物質の使用量が大幅に認証がPAで行われている方法を変更しません。 SIP認証メカニズムのいずれかが状態エージェントによって使用することができます。ただし、認証がプレゼンと加入者との間の共有秘密を意識する状態のエージェントが必要になりますダイジェスト。これは、安全な状態エージェントにプレゼンから共有秘密を転送するために、いくつかの手段が必要になります。
The usage of state agents does, however, have a significant impact on authorization. As stated in Section 6.6, a PA is required to authorize all subscriptions. If no explicit authorization policy has been defined, the PA will need to query the user for authorization. In a presence edge server (where the PUA is co-located with the PUA), this is trivially accomplished. However, when state agents are used (i.e., a presence server), a means is needed to alert the user that an authorization decision is required. This is the reason for the watcherinfo event template-package [8]. All state agents SHOULD support the watcherinfo template-package.
状態の物質の使用量は、しかし、承認に大きな影響を持っていません。 6.6節で述べたように、PAは、すべてのサブスクリプションを許可するために必要とされます。明示的な認可ポリシーが定義されていない場合、PAは、認可のために、ユーザに照会する必要があります。 （PUAがPUAと同じ場所に配置される）の存在エッジサーバーでは、これは自明に達成されます。状態剤（すなわち、プレゼンス・サーバ）が使用される場合しかし、手段は、許可決定が必要であることをユーザに警告するために必要とされます。これはwatcherinfoイベントテンプレートパッケージ[8]の理由です。すべての状態エージェントはwatcherinfoテンプレート・パッケージをサポートする必要があります。
On occasion, it makes sense for the PA function to migrate from one server to another. For example, for reasons of scale, the PA function may reside in the presence server when the PUA is not running, but when the PUA connects to the network, the PA migrates subscriptions to it in order to reduce state in the network. The mechanism for accomplishing the migration is described in Section 3.3.5 of RFC 3265 [2]. However, packages need to define under what conditions such a migration would take place.
機会に、それは、あるサーバーから別のサーバーへ移行するためにPAの機能のために理にかなっています。 PUAが実行されていない場合、例えば、スケールの理由のために、PAの機能は、プレゼンスサーバ内に存在してもよいが、PUAがネットワークに接続したとき、PAは、ネットワークの状態を低減するために、それにサブスクリプションを移動します。マイグレーションを達成するためのメカニズムは、RFC 3265のセクション3.3.5に記載されている[2]。ただし、パッケージは、そのような移行が行われますどのような条件の下で定義する必要があります。
A PA MAY choose to migrate subscriptions at any time, through configuration, or through dynamic means. The REGISTER request provides one dynamic means for a presence server to discover that the function can migrate to a PUA. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD use the callee capabilities specification [9] to indicate that it supports the SUBSCRIBE request method and the presence event package. The combination of these two define a PA. Of course, a presence server can always attempt a migration without these explicit hints. If it fails with either a 405 or 489 response code, the server knows that the PUA does not support the PA function. In this case, the server itself will need to act as a PA for that subscription request. Once such a failure has occurred, the server SHOULD NOT attempt further migrations to that PUA for the duration of its registration. However, to avoid the extra traffic generated by these failed requests, a presence server SHOULD support the callee capabilities extension.
PAは、コンフィギュレーションによって、または動的な手段を通じて、いつでもサブスクリプションを移行することを選ぶかもしれません。 REGISTERリクエストは、関数がPUAに移行することができることを発見するプレゼンスサーバに対して1つの動的な手段を提供します。 PUAがPA機能のサポートを示すことを望むならば具体的には、[9]がSUBSCRIBEリクエストメソッドとプレゼンス・イベント・パッケージをサポートしていることを示すために、被呼機能仕様を使用すべきです。これら二つの組み合わせは、PAを定義します。もちろん、プレゼンスサーバは、常にこれらの明示的なヒントなしで移行を試みることができます。それは405または489応答コードのいずれかで失敗した場合、サーバーは、PUAは、PAの機能をサポートしていないことを知っています。この場合、サーバ自身がそのサブスクリプション要求のためのPAとして機能する必要があります。このような障害が発生すると、サーバーは、その登録の期間中、そのPUAにさらに移行を試みるべきではありません。しかし、これらの失敗した要求によって生成された余分なトラフィックを避けるために、プレゼンスサーバは、呼び出し先の機能拡張をサポートする必要があります。
Furthermore, indication of support for the SUBSCRIBE request and the presence event package is not sufficient for migration of subscriptions. A PA SHOULD NOT migrate the subscription if it is composing aggregated presence documents received from multiple PUA.
また、SUBSCRIBEリクエスト及びプレゼンスイベントパッケージのためのサポートの指示は、サブスクリプションの移行のために十分ではありません。それは、複数のPUAから受信した集約されたプレゼンス文書を構成した場合PAは、サブスクリプションを移行すべきではありません。
Presence information can be obtained by the PA in many ways. No specific mechanism is mandated by this specification. This section overviews some of the options, for informational purposes only.
プレゼンス情報は多くの方法でPAによって得ることができます。具体的なメカニズムはこの仕様で義務付けられていません。このセクションでは、情報提供のみを目的とし、いくつかのオプションを概観します。
When the PA function is co-located with the PUA, presence is known directly by the PA.
PA機能がPUAと同じ場所に配置されている場合、存在がPAによって直接知られています。
A UA uses the SIP REGISTER method to inform the SIP network of its current communications addresses (i.e., Contact addresses). Multiple UA can independently register Contact addresses for the same address-of-record. This registration state represents an important piece of the overall presence information for a presentity. It is an indication of basic reachability for communications.
UAは、その現在の通信アドレス（すなわち、連絡先アドレス）のSIPネットワークに通知するためにSIP REGISTERメソッドを使用します。複数のUAは、独立して、同じアドレス・オブ・レコードの連絡先アドレスを登録することができます。この登録状態はプレゼンのための全体的なプレゼンス情報の重要な部分を表しています。これは、通信のための基本的な到達可能性の指標です。
Usage of REGISTER information to construct presence is only possible if the PA has access to the registration database, and can be informed of changes to that database. One way to accomplish that is to co-locate the PA with the registrar.
PAが登録データベースへのアクセス権を持っており、そのデータベースへの変更を知ることができるならば存在を構築するためのREGISTER情報の利用のみ可能です。それを達成するための一つの方法は、レジストラにPAを同じ場所に配置することです。
The means by which registration state is converted into presence state is a matter of local policy, and beyond the scope of this specification. However, some general guidelines can be provided. The address-of-record in the registration (the To header field) identifies the presentity. Each registered Contact header field identifies a point of communications for that presentity, which can be modeled using a tuple. Note that the contact address in the tuple need not be the same as the registered contact address. Using an address-of-record instead allows subsequent communications from a watcher to pass through proxies. This is useful for policy processing on behalf of the presentity and the provider.
登録状態が存在状態に変換する手段は、ローカルポリシーの問題であり、この仕様の範囲を超え。しかし、いくつかの一般的なガイドラインを提供することができます。アドレス・オブ・レコード登録（Toヘッダーフィールド）には、プレゼンティティを識別する。各登録Contactヘッダーフィールドタプルを使用してモデル化することができ、そのプレゼンティティのための通信の点を識別する。タプルの連絡先が登録されている連絡先と同じである必要はないことに注意してください。アドレス・オブ・レコードを使用する代わりに、ウォッチャからの後続の通信がプロキシを通過することを可能にします。これは、プレゼンやプロバイダに代わってポリシー処理するのに便利です。
A PUA that uses registrations to manipulate presence state SHOULD make use of the SIP callee capabilities extension [9]. This allows the PUA to provide the PA with richer information about itself. For example, the presence of the methods parameter listing the method "MESSAGE" indicates support for instant messaging.
プレゼンス状態を操作するために登録を使用してPUAは、SIP着信機能拡張を利用するべきである[9]。これは、PUAは、それ自体についてのより豊富な情報とPAを提供することができます。たとえば、メソッド「MESSAGE」を一覧表示する方法パラメータの存在は、インスタントメッセージングのサポートを示します。
The q values from the Contact header field [1] can be used to establish relative priorities amongst the various communications addresses in the Contact header fields.
ContactヘッダフィールドからQ値[1] Contactヘッダーフィールドにおける様々な通信アドレスの間で相対的な優先順位を確立するために使用することができます。
The usage of registrations to obtain presence information increases the requirements for authenticity and integrity of registrations. Therefore, REGISTER requests used by presence user agents MUST be authenticated.
プレゼンス情報を取得する登録の使用は、登録の真正性および完全性のための要件を増加させます。したがって、プレゼンスユーザエージェントによって使用されるREGISTER要求が認証されなければなりません。
If a means exists to upload presence documents from PUA to the PA, the PA can act as an aggregator and redistributor of those documents. The PA, in this case, would take the presence documents received from each PUA for the same presentity, and merge the tuples across all of those PUA into a single presence document. Typically, this aggregation would be accomplished through administrator or user defined policies about how the aggregation should be done.
手段はPAにPUAからプレゼンスドキュメントをアップロードするために存在している場合、PAは、それらの文書のアグリゲータと再分配としての役割を果たすことができます。 PAは、この場合には、同じプレゼンのために、各PUAから受信したプレゼンス文書を取るだろうし、単一のプレゼンス文書にこれらのPUAのすべての間でタプルをマージします。通常、この集約は、集約が行われるべきかについて、管理者またはユーザー定義のポリシーを通じて達成されるだろう。
The specific means by which a presence document is uploaded to a presence agent are outside the scope of this specification. When a PUA wishes to have direct manipulation of the presence that is distributed to subscribers, direct uploading of presence documents is RECOMMENDED.
プレゼンスドキュメントが、プレゼンスエージェントにアップロードされる特定の手段は、本明細書の範囲外です。 PUAは、加入者に配布される存在の直接操作を持っているしたい場合は、プレゼンス文書を直接アップロードすることをお勧めします。
This message flow illustrates how the presence server can be responsible for sending notifications for a presentity. This flow assumes that the watcher has previously been authorized to subscribe to this resource at the server.
このメッセージ・フローは、プレゼンスサーバがプレゼンのための通知を送信するための責任を負うことができる方法を示します。この流れは、ウォッチャーが以前のサーバーでこのリソースに加入することが許可されていることを前提としています。
In this flow, the PUA informs the server about the updated presence information through some non-SIP means.
このフローでは、PUAは、いくつかの非SIP手段を介して更新されたプレゼンス情報についてサーバーに通知します。
When the value of the Content-Length header field is "..." this means that the value should be whatever the computed length of the body is.
Content-Lengthヘッダフィールドの値が「...」この値は、本体の計算された長さがあるものは何でもあるべきであることを意味します。
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
Message Details
メッセージの詳細
F1 SUBSCRIBE watcher->example.com server
F1 SUBSCRIBE watcher-> example.comサーバー
SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 To: <sip:resource@example.com> From: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: <sip:user@watcherhost.example.com> Expires: 600 Content-Length: 0
SIP SUBSCRIBE：resource@example.comをSIP / 2.0経由：SIP / 2.0 / TCP watcherhost.example.com;ブランチ= z9hG4bKnashds7へ：<SIP：resource@example.com>から<SIP：user@example.com>。タグ= xfg9コールID：2010@watcherhost.example.comのCSeq：17766 SUBSCRIBEマックス・フォワード：70イベント：存在が受け入れ：アプリケーション/ PIDF + xmlの接触：<SIP：user@watcherhost.example.com>は有効期限：600コンテンツを-length：0
F2 200 OK example.com server->watcher
F2 200 OK example.comサーバ - >ウォッチャー
SIP/2.0 200 OK Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 To: <sip:resource@example.com>;tag=ffd2 From: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Expires: 600 Contact: sip:server.example.com Content-Length: 0
SIP / 2.0 200 OK経由：タグ= FFD2から;：<resource@example.com SIP：>：<一口例：@ユーザーSIP / 2.0 / TCP watcherhost.example.com;ブランチ= z9hG4bKnashds7は= 192.0.2.1への受信しました.COM>;タグ= xfg9コールID：2010@watcherhost.example.comのCSeq：17766は、SUBSCRIBE有効期限：600お問い合わせ：一口：server.example.comのContent-Length：0
F3 NOTIFY example.com server-> watcher
F3 NOTIFY example.comサーバ - >ウォッチャー
NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ...
<一口：resource@example.com>;タグ= FFD2へ：<SIP：ユーザー;：user@watcherhost.example.com SIP / 2.0経由：ブランチ= z9hG4bKna998skからSIP / 2.0 / TCP server.example.com一口をNOTIFY @ example.com>;タグ=コールIDをxfg9：2010@watcherhost.example.comイベント：プレゼンスサブスクリプションステート：アクティブは; = 599マックス-前方に期限が切れる：70のCSeq：SIP：8775連絡先をNOTIFY server.example.comコンテンツタイプ：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[PIDF Document]
[PIDF文献]
F4 200 OK watcher-> example.com server
F4 200 OK watcher-> example.comサーバー
SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk ;received=192.0.2.2 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8775 NOTIFY Content-Length: 0
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP server.example.com;ブランチ= z9hG4bKna998skは;から= 192.0.2.2を受けた。<SIP：resource@example.com>;タグ= FFD2へ：<一口例：@ユーザー.COM>;タグ= xfg9コールID：2010@watcherhost.example.comのCSeq：8775は、コンテンツの長さをNOTIFY：0
F5 NOTIFY example.com server -> watcher
F5がexample.comサーバーをNOTIFY - >ウォッチャー
NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=543 Max-Forwards: 70 Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ...
<一口：resource@example.com>;タグ= FFD2へ：<SIP：ユーザー;：user@watcherhost.example.com SIP / 2.0経由：ブランチ= z9hG4bKna998slからSIP / 2.0 / TCP server.example.com一口をNOTIFY @ example.com>;タグ= xfg9コールID：2010@watcherhost.example.comのCSeq：8776イベントをNOTIFY：プレゼンスサブスクリプション・状態：アクティブ、有効期限が切れる= 543マックス・フォワード：70お問い合わせ：一口：server.example.comコンテンツタイプ：アプリケーション/ PIDF + XMLコンテンツ-長さ：...
[New PIDF Document]
[新しいPIDFドキュメント]
F6 200 OK
F6 200 OK
SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl ;received=192.0.2.2 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Content-Length: 0
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP server.example.com;ブランチ= z9hG4bKna998slは;から= 192.0.2.2を受けた。<SIP：resource@example.com>;タグ= FFD2へ：<一口例：@ユーザー.COM>;タグ= xfg9コールID：2010@watcherhost.example.comのCSeq：8776は、コンテンツの長さをNOTIFY：0
There are numerous security considerations for presence. RFC 2779 [13] outlines many of them, and they are discussed above. This section considers them issue by issue.
プレゼンスのための多数のセキュリティの考慮事項があります。 RFC 2779 [13]、それらの多くの概要を示し、それらは上記で議論されています。このセクションでは、問題によってそれらの問題と考えています。
Confidentiality encompasses many aspects of a presence system:
機密性は、プレゼンスシステムの多くの側面を包含する。
o Subscribers may not want to reveal the fact that they have subscribed to certain users
O加入者は、彼らが特定のユーザーに加入しているという事実を明らかにしたくないかもしれません
o Users may not want to reveal that they have accepted subscriptions from certain users
Oユーザーは、特定のユーザーからのサブスクリプションを受け入れたことを明らかにしたくないかもしれません
o Notifications (and fetch results) may contain sensitive data which should not be revealed to anyone but the subscriber
O通知（及び結果をフェッチ）誰もが、加入者に明らかにされるべきではない機密データを含んでいてもよいです
Confidentiality is provided through a combination of hop-by-hop encryption and end-to-end encryption. The hop-by-hop mechanisms provide scalable confidentiality services, disable attacks involving traffic analysis, and hide all aspects of presence messages. However, they operate based on transitivity of trust, and they cause message content to be revealed to proxies. The end-to-end mechanisms do not require transitivity of trust, and reveal information only to the desired recipient. However, end-to-end encryption cannot hide all information, and is susceptible to traffic analysis. Strong end-to-end authentication and encryption can be done using public keys, and end-to-end encryption can be done using private keys [14]. Both hop-by-hop and end-to-end mechanisms will likely be needed for complete privacy services.
機密性は、ホップ・バイ・ホップの暗号化とエンドツーエンド暗号化の組み合わせを介して提供されます。ホップバイホップのメカニズムは、トラフィック分析を含むスケーラブルな機密性サービス、無効な攻撃を提供し、プレゼンスメッセージのすべての側面を非表示にします。しかし、彼らは信頼の推移に基づいて動作し、彼らはメッセージの内容は、プロキシに明らかにすることが原因。エンドツーエンドのメカニズムは、信頼の推移性を必要とし、唯一の希望の受信者に情報を明らかにしません。しかし、エンドツーエンドの暗号化は、すべての情報を隠し、およびトラフィック分析の影響を受けやすいことはできません。強力なエンドツーエンドの認証と暗号化は、公開鍵を使用して行うことができ、およびエンドツーエンドの暗号化は、秘密鍵[14]を使用して行うことができます。どちらのホップバイホップとエンドツーエンドのメカニズムはおそらく完全なプライバシーのサービスのために必要とされるであろう。
SIP allows any hop by hop encryption scheme, but TLS is mandatory to implement for servers. Therefore, it is RECOMMENDED that TLS [7] be used between elements to provide this function. The details for usage of TLS for server-to-server and client-to-server security are detailed in Section 26.3.2 of RFC 3261 [1].
SIPは、ホップの暗号化方式により任意のホップを許可しますが、TLSは、サーバー用の実装が必須です。したがって、TLS [7]この機能を提供する要素間使用することを推奨されています。サーバー間およびクライアントからサーバーへのセキュリティのためのTLSの使用方法の詳細は、RFC 3261のセクション26.3.2で詳述されている[1]。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
SIP暗号化は、S / MIMEを使用して、両方のSUBSCRIBE及びNOTIFYリクエストを送信するためのエンドツーエンドの使用され得ます。
It is important for the message recipient to ensure that the message contents are actually what was sent by the originator, and that the recipient of the message be able to determine who the originator really is. This applies to both requests and responses of SUBSCRIBE and NOTIFY. NOTIFY requests are particularly important. Without authentication and integrity, presence documents could be forged or modified, fooling the watcher into believing incorrect presence information.
メッセージの受信者がメッセージの内容は、発信者によって送信されたものを実際にしていることを確認するために、メッセージの受信者は発信者が本当に誰であるかを判断することができるということが重要です。これは、要求とSUBSCRIBEとNOTIFYの応答の両方に適用されます。 NOTIFYリクエストは、特に重要です。認証と整合性がなければ、プレゼンス文書は間違ったプレゼンス情報を信じるようにウォッチャをだまし、偽造または変更することができます。
RFC 3261 provides many mechanisms to provide these features. In order for the PA to authenticate the watcher, it MAY use HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP Digest. This is a redundant requirement, however, since all SIP user agents are mandated to support it by RFC 3261. To provide authenticity and integrity services, a watcher MAY use the SIPS scheme when subscribing to the presentity. To support this, all PA MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261).
RFC 3261は、これらの機能を提供するために、多くのメカニズムを提供します。 PAは、ウォッチャーを認証するためには、それは、HTTPダイジェスト（RFC 3261のセクション22）を使用することができます。その結果、すべてのウォッチャーは、HTTPダイジェストをサポートしなければなりません。これは、すべてのSIPユーザエージェントは、信頼性と整合性サービスを提供するためにRFC 3261でそれをサポートするために義務付けられているので、プレゼンに加入したときに、ウォッチャーはSIPSスキームを使用することができるが、しかし、冗長な要件です。これをサポートするために、すべてのPAは、TLSをサポートしなければならないと、彼らはプロキシであるかのように（RFC 3261のセクション26.3.1を参照してください）SIPS。
Furthermore, SMIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261.
さらに、SMIMEはSUBSCRIBEとNOTIFYリクエストの整合性と信頼のために使用されるかもしれません。これは、RFC 3261のセクション23に記載されています。
When local proxies are used for transmission of outbound messages, proxy authentication is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network.
ローカルプロキシが送信メッセージの伝送に使用されている場合は、プロキシ認証が推奨されます。これは、発信者の身元を確認し、発信ネットワークでなりすましやスパムを防止するのに有用です。
Replay attacks can be used by an attacker to fool a watcher into believing an outdated presence state for a presentity. For example, a document describing a presentity as being "offline" can be replayed, fooling watchers into thinking that the user is never online. This may effectively block communications with the presentity.
リプレイ攻撃はプレゼン用の時代遅れの存在状態を信じるようにウォッチャーをだますために攻撃者によって使用することができます。たとえば、「オフライン」であるとしてプレゼンを記述した文書は、ユーザーがオンラインになることはありませんという考えにウォッチャーをだまし、再生することができます。これは、効果的にプレゼンティティとの通信を遮断することができます。
SIP S/MIME can provide message integrity and authentication over SIP request bodies. Watchers and PAs MAY implement S/MIME signatures to prevent these replay attacks. When it is used for that purpose, the presence document carried in the NOTIFY request MUST contain a timestamp. In the case of PIDF, this is accomplished using the timestamp element, as described in Section 6 of [6]. Tuples whose timestamp is older than the timestamp of the most recently received presence document SHOULD be considered stale, and discarded.
SIP S / MIMEは、SIPリクエストボディの上にメッセージの整合性と認証を提供することができます。ウォッチャーとPAはこれらのリプレイ攻撃を防ぐために、S / MIME署名を実施することができます。それはその目的のために使用されている場合は、NOTIFYリクエストで運ばプレゼンス文書は、タイムスタンプを含まなければなりません。 [6]の第6章に記載されているようにPIDFの場合、これは、タイムスタンプ要素を使用して達成されます。そのタイムスタンプが最近受信したプレゼンス文書のタイムスタンプよりも古いタプルは無効と見なされ、破棄されるべき。
Finally, HTTP digest authentication (which MUST be implemented by watchers and PAs) MAY be used to prevent replay attacks, when there is a shared secret between the PA and the watcher. In such a case, the watcher can challenge the NOTIFY requests with the auth-int quality of protection.
PAとウォッチャーとの間の共有秘密キーがある場合、最終的に、（ウォッチャーとのPAによって実現されなければならない）HTTPダイジェスト認証は、リプレイ攻撃を防止するために使用され得ます。そのような場合には、ウォッチャーは、保護ののauth-int型の品質とNOTIFYリクエストに挑戦することができます。
Denial of Service (DOS) attacks are a critical problem for an open, inter-domain, presence protocol. Unfortunately, presence is a good candidate for Distributed DoS (DDOS) attacks because of its amplification properties. A single SUBSCRIBE message could generate a nearly unending stream of notifications, so long as a suitably dynamic source of presence data can be found. Thus, a simple way to launch an attack against a target is to send subscriptions to a large number of users, and in the Contact header field (which is where notifications are sent), place the address of the target. RFC 3265 provides some mechanisms to mitigate these attacks [2]. If a NOTIFY is not acknowledged or was not wanted, the subscription that generated it is removed. This eliminates the amplification properties of providing false Contact addresses.
サービス拒否（DOS）攻撃はオープン、ドメイン間、プレゼンスプロトコルにとって重要な問題です。残念ながら、存在は、その増幅特性を分散DoS攻撃（DDOS）攻撃のための良い候補です。単一SUBSCRIBEメッセージがあれば、プレゼンスデータの適切動的ソースを見つけることができるように、通知のほとんど終わりのないストリームを生成することができます。したがって、標的に対する攻撃を開始するための簡単な方法は、多数のユーザーにサブスクリプションを送信することで、（通知が送信されているところである）Contactヘッダーフィールドに、ターゲットのアドレスを配置します。 RFC 3265は、これらの攻撃を軽減するためにいくつかのメカニズムを提供する[2]。認知されていない通知したりたかっていなかった場合は、それを生成したサブスクリプションが削除されます。これは、偽の連絡先アドレスを提供するの増幅特性がなくなります。
Authentication and authorization at the PA can also prevent these attacks. Typically, authorization policy will not allow subscriptions from unknown watchers. If the attacks are launched from watchers unknown to the presentity (a common case), the attacks are mitigated.
PAでの認証と承認は、これらの攻撃を防ぐことができます。一般的に、認可ポリシーは、未知のウォッチャーからサブスクリプションを許可しません。攻撃がプレゼン（一般的なケース）に、未知のウォッチャーから起動している場合は、攻撃が軽減されます。
Denial of service attacks can also be launched against a presence agent itself, in order to disrupt service to a community of users. SIP itself, along with RFC 3265 [2], describes several mechanisms to mitigate these attacks.
サービス妨害攻撃は、ユーザーのコミュニティへのサービスを破壊するために、プレゼンスエージェント自身に対して起動することができます。 RFC 3265 [2]と共に、自身をSIP、これらの攻撃を軽減するためにいくつかのメカニズムが記載されています。
A server can prevent SYN-attack style attacks through a four-way handshake using digest authentication [1]. Even if the server does not have a shared secret with the client, it can verify the source IP address of the request using the "anonymous" user mechanism described in Section 22.1 of RFC 3261 [1]. SIP also allows a server to instruct a client to back-off from sending it requests, using the 503 response code (Section 21.5.4 of RFC 3261 [1]). This can be used to fend off floods of SUBSCRIBE requests launched as a result of a distributed denial of service attack.
サーバーは、[1]ダイジェスト認証を使用した4ウェイハンドシェイクを通じてSYN攻撃スタイルの攻撃を防ぐことができます。サーバーがクライアントと共有シークレットを持っていない場合でも、それは、[1] RFC 3261のセクション22.1に記載された「匿名」のユーザー・メカニズムを使用して、要求の送信元IPアドレスを確認することができます。 SIPはまた、サーバは、それが（[1] RFC 3261のセクション21.5.4）を503応答コードを使用して、要求送信からオフをバックアップするクライアントに指示することを可能にします。これは、サービス攻撃の分散拒否の結果として発足SUBSCRIBEリクエストの洪水をかわすために使用することができます。
This specification registers an event package, based on the registration procedures defined in RFC 3265 [2]. The following is the information required for such a registration:
この仕様は、RFC 3265で定義された登録手順に基づいて、イベントパッケージを登録する[2]。以下は、そのような登録に必要な情報です。
Package Name: presence
パッケージ名：プレゼンス
Package or Template-Package: This is a package.
パッケージまたはテンプレート・パッケージ：これはパッケージです。
Published Document: RFC 3856
公開されたドキュメント：RFC 3856
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
人への問い合わせ先：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.netを。
The following individuals were part of the initial team that worked through the technical design of this specification:
以下の個人はこの仕様の技術的な設計を通して働いた最初のチームの一部でした：
Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ジョナサンレノックスコロンビア大学M / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: lennox@cs.columbia.edu
メールアドレス：lennox@cs.columbia.edu
Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
ロバートはdynamicsoft 5100テニソンパークウェイスイート1200プラノ、テキサス75024スパークス
EMail: rsparks@dynamicsoft.com
メールアドレス：rsparks@dynamicsoft.com
Ben Campbell
ベン・キャンベル
EMail: ben@nostrum.com
メールアドレス：ben@nostrum.com
Dean Willis dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
ディーンウィリスdynamicsoft 5100テニソンパークウェイスイート1200プラノ、テキサス75024
EMail: dwillis@dynamicsoft.com
メールアドレス：dwillis@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
バーナードAbobaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com
David Gurle Reuters Corporation
デビッド・グルロイター・コーポレーション
EMail: David.Gurle@reuters.com
メールアドレス：David.Gurle@reuters.com
David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134
デビッド・オランシスコシステムズ170西タスマン博士サンノゼ、CA 95134
EMail: oran@cisco.com
メールアドレス：oran@cisco.com
We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan, Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their comments and support of this specification.
私たちはリック・ワークマン、アダムローチ、ショーン・オルソン、ビリー・ビッグス、スチュアートバークリー、マウリシオ・アランゴ、リチャードショッキー、ヨルゲンBjorkner、ヘンリーSinnreich、ロナルド・エイカーズ、ポールKyzivat、雅 - チンタン、パトリックFaltstrom、アリソンマンキンとヒシャムに感謝したいと思います彼らのコメントやこの仕様をサポートするためのKhartabil。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、H.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[3]ピーターソン、J.、RFC 3859、2004年8月、 "共通プロファイルプレゼンス（CPP）のために"。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[7]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[8] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[8]ローゼンバーグ、J.、RFC 3857、2004年8月 "セッション開始プロトコル（SIP）のためのウォッチャー情報イベントテンプレート・パッケージ"。
[9] Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[9] Schulzrinneと、H.ローゼンバーグ、J.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[10]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[11] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, May 2004.
[11]ピーターソン、J.、進歩、2004年5月における作業「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化」。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
【13日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211, December 2001.
[14] Gutmann氏、P.、 "CMSのためのパスワードベースの暗号化"、RFC 3211、2001年12月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、NJ 07054
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
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機能のための基金は現在、インターネット協会によって提供されます。