[要約] RFC 3856は、SIPのためのプレゼンスイベントパッケージに関する規格です。このRFCの目的は、SIPセッションに関連するプレゼンス情報を通知するための仕組みを提供することです。
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）The Internet Society（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]は、存在情報を提供するシステムを記述するためのモデルと用語を定義します。そのモデルでは、プレゼンスサービスとは、Watchersと呼ばれる利害関係者にプレゼンス情報を受け入れ、保存し、配布するシステムです。プレゼンスプロトコルは、インターネットまたは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 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）[1]の使用法を提案しています。これは、SIPのために定義された一般的なイベント通知フレームワークの具体的なインスタンス化[2]を通じて実現されるため、サブスクライブおよび通知メソッドを使用して定義されています。具体的には、このドキュメントは、RFC 3265 [2]で説明されているように、イベントパッケージを定義しています。SIPは、存在プロトコルとして特に適しています。SIPロケーションサービスには、登録の形で既に存在情報が含まれています。さらに、SIPネットワークは、ネットワーク上のユーザーからユーザーの登録状態を保持しているサーバーへのリクエストをルーティングできます。この状態はユーザーの存在の重要なコンポーネントであるため、これらのSIPネットワークは、サブスクライブリクエストを同じサーバーにルーティングできるようにすることができます。これは、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.
このイベントパッケージは、サブスクリプションを受け入れ、サブスクリプション状態を保存し、存在感が変更されたときに通知を生成できる新しい論理エンティティであるプレゼンスエージェントの概念に基づいています。エンティティは、一般に別のエンティティとの共同居住者であるため、論理的なものとして定義されます。
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]で定義されているCommon Presenceプロファイル（CPP）フレームワークにも準拠しています。これにより、SIPは、CPPに準拠した他の存在システムと簡単にインターワークできます。
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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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レジスタリクエストを送信して新しい連絡先を追加するなど）、またはプレゼンスドキュメントの公開を通じて明示的に実行できます。プレゼンテーションごとに複数のPUAを明示的に許可します。これは、ユーザーが多くのデバイス（携帯電話やパーソナルデジタルアシスタント（PDA）など）を持つことができることを意味します。それぞれが、プレゼンテーションのために全体的な存在情報のコンポーネントを独立して生成しています。PUAはデータをプレゼンスシステムに押し込みますが、サブスクライブメッセージを受信したり、通知メッセージを送信したりしないという点で、その外側にあります。
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）：プレゼンスエージェントは、サブスクライブリクエストを受信し、それらに応答し、プレゼンス状態で変更の通知を生成できるSIPユーザーエージェントです。存在エージェントは、プレゼンテーションの存在状態に関する知識を持っている必要があります。これは、プレゼンテーションのためにPUAによって操作される存在データにアクセスできる必要があることを意味します。これを行う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.
もう1つの方法は、プレゼンテーションの存在ユーザーエージェントと共同開くことです。ただし、これらは唯一の方法ではなく、この仕様はPA機能の配置場所について推奨しません。PAは常に、プレゼンテーションを独自に識別するSIP URIでアドレス指定可能です（つまり、sip：joe@example.com）。特定のプレゼンテーションには複数の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.
プレゼンスサーバー：プレゼンスサーバーは、存在エージェントとして、またはサブスクライブリクエストのプロキシサーバーとして機能する物理エンティティです。PAとして機能する場合、いくつかのプロトコル平均を通じてプレゼンテーションの存在情報を認識しています。プロキシとして機能する場合、サブスクライブリクエストは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.
このセクションでは、このイベントパッケージの操作の概要を示します。概要では、ここで文書化されている動作について、一部はSIPイベントフレームワーク[2]内で、および一部はSIP仕様[1]に記載されています。ただし、このパッケージの詳細なセマンティクスでは、読者が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.
サブスクライバーであるエンティティが、一部のユーザーからの存在情報について学びたい場合、サブスクライブリクエストを作成します。このリクエストは、SIP URI、SIPS URI [1]、または存在（PRES）URI [3]を使用して、リクエスト-URIの望ましいプレゼンティを識別します。購読要求は、他のSIPリクエストがそうであるように、SIPプロキシに沿って実行されます。ほとんどの場合、最終的にはプレゼンスサーバーに到着し、リクエストへの応答を生成することができます（その場合、プレゼンテーションの存在エージェントとして機能します）、またはエッジプレゼンスサーバーにプロキシにします。Edge Expentition Serverがサブスクリプションを処理する場合、プレゼンテーションの存在エージェントとして機能します。Presenceサーバーでの決定は、サブスクライブをプロキシまたは終了するかどうかについての決定はローカルな問題です。ただし、レジスタを使用して、このような構成を実施する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は、プレゼンテーションとサブスクリプションの状態を含む即時の通知メッセージを送信します。保留中のサブスクリプションの場合、プレゼント状態は偽物である可能性があり、たとえば、実際のプレゼント状態に関係なくオフラインを示しています。これは、提示のプライバシーを保護するためであり、サブスクライバーに許可を提供していないことを明らかにしたくないかもしれません。プレゼンテーションの状態が変化すると、PAは、認定サブスクリプションを使用して、すべてのサブスクライバーにこれらの状態の変更を含む通知を生成します。サブスクリプション自体の状態の変更は、リクエストを通知することもできます。その状態は、Notifyのサブスクリプションステートヘッダーフィールドに携帯されており、通常、サブスクリプションがアクティブか保留中かを示します。
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.
購読メッセージは、存在エージェントと「ダイアログ」を確立します。ダイアログはRFC 3261 [1]で定義されており、ピアツーピアのメッセージ交換を促進するために、一対のエンティティ間のSIP状態を表します。この状態には、ルートセットとリモートターゲットURIに加えて、両方向のメッセージのシーケンス番号（サブスクライバーからのサブスクライブ、存在エージェントからの通知）が含まれます。ルートセットは、購読リフレッシュまたは通知リクエストのパスに沿ってアクセスするSIPプロキシサーバーを識別するSIP（またはSIP）URIのリストです。リモートターゲットURIは、メッセージのターゲットを識別するSIPまたはSIPS URIです - サブスクライバー、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は、プロキシサーバーが通知メッセージのパスにあることを要求し、リフレッシュを購読することを要求できるレコードルーティングと呼ばれる手順を提供します。これは、最初の購読要求で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.
サブスクリプションは、初期サブスクライブの一部として交渉される期間の持続します。サブスクライバーは、サブスクリプションを保持したい場合は、有効期限の前にサブスクリプションを更新する必要があります。これは、最初のサブスクライブによって確立された同じダイアログ内でサブスクライブリフレッシュを送信することで実現されます。このサブスクライブは最初のものとほぼ同じですが、ヘッダーフィールドにタグ、より高いCSEQヘッダーフィールド値、場合によってはリクエストが実行するプロキシのパスを識別するルートヘッダーフィールド値のセットが含まれています。
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.
サブスクライバーは、ダイアログ内でサブスクライブを送信してサブスクリプションを終了できます。これにより、サブスクリプションの即時終了が発生します。その後、通知要求は、最新の状態の存在エージェントによって生成されます。実際、ゼロの有効期限が切れるサブスクライブリクエストを処理するための存在エージェントの動作は、他の有効期限の価値と変わりません。保留中または承認されたサブスクライブリクエストにより、現在のプレゼンテーションとサブスクリプション状態でトリガーされた通知が得られます。
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.
存在エージェントは、いつでもサブスクリプションを終了できます。そのために、サブスクリプションヘッダーフィールドを使用して通知要求を送信して、サブスクリプションが終了したことを示します。理由を提供する理由パラメーターを提供できます。
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.
また、現在の存在状態を取得することも可能であり、現在の状態を含む1回限りの通知をもたらします。これは、即時有効期限が切れてサブスクライブリクエストを送信することで実現されます。
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.
プレゼンテーションは、uri [3]で最も一般的な方法で特定されます。これは、pres：user@domainの形式です。これらのURIは、サーバーに維持されているドメイン固有のマッピングポリシーを介して、SIPやSIPS URIなどの特定のURIをプロトコルするように解決されます。
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（および/またはSIP）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 URIに送信された購読要求は、200 OKの連絡先ヘッダーフィールドからサブスクライブリクエストへの提示のためにSIPまたはSIPS URIを学習します。別の例として、Pres URIの検索がSIPまたはSIP URIを取得できるようにするDNSメカニズムが定義される場合があります。あるURIがプロトコルの平均を介して別のURIから学習されている場合、それらの手段は、学習されたURIの寿命を制限する何らかのスコープを提供することがよくあります。たとえば、DNSは、URIの範囲を制限するTTLを提供します。これらのスコープは、同じリソースを識別するために古くなったり矛盾する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.
サブスクライバーが、プロトコルに依存しないプレゼントのプレゼンテーションのみを認識している場合、[5]で定義されている手順に従います。これらの手順により、SIPリクエストのリクエスト-URIにPres URIが配置され、その後、[5]で定義されたDNS手順の使用が行われ、SIPリクエストを送信するホストを決定します。もちろん、RFC 3261 [1]で指定されているように、ローカルアウトバウンドプロキシを代わりに使用する場合があります。サブスクライバーが同じ提示に対してプロトコルに依存しないPres URIとSIPまたはSIPS URIの両方を認識している場合、両方が有効である（上記のように）プレスURI形式を使用する必要があります。もちろん、サブスクライバーが現在のSIP URIのみを知っている場合、URIが使用され、標準のRFC 3261処理が発生します。Pres URIが使用されると、URIスキームを理解していない購読要求のパスに沿ったプロキシは、リクエストを拒否します。そのため、ユーザーに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.
サブスクライブメッセージには、サブスクリプション（ヘッダーフィールドから）のオリジネーターと受信者を定義する論理識別子も含まれています。これらのヘッダーは、PresまたはSIP URIを取得できます。サブスクライバーが自分のアイデンティティに対してPresとSIP URIの両方を認識している場合、From Headerフィールドの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メッセージ内のSIP URIの代わりにPres URIの使用は、他のCPP準拠システムへのゲートウェイを介して相互運用性をサポートします。システム間で渡すことができるプロトコルに依存しない識別形式を提供します。そのようなアイデンティティがなければ、ゲートウェイはSIP URIを他のプロトコルのアドレス指定形式にマッピングすることを余儀なくされます。一般的に、これはSIP URIをフォームに<Foregrive-Protocol-Scheme>：<Encoded SIP URI>@<Gateway>に変換することによって行われます。これは一般に電子メールシステムで行われ、多くの既知の問題があります。Pres URIの使用は、ゲートウェイが存在しないことがわかっている場合、またはPres URIの使用がSIPコンポーネントでの相互運用性の問題を引き起こす場合がある場合、必須ではなく、必須ではありません。プレス・ウリ。
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]で指定されているように、この値は、サブスクライブおよび通知リクエストに存在するイベントヘッダーフィールドに表示されます。
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.
購読要求にはボディが含まれる場合があります。体の目的はそのタイプに依存します。サブスクリプションには通常、ボディが含まれません。
The Request-URI, which identifies the presentity, combined with the event package name, is sufficient for presence.
イベントパッケージ名と組み合わされたプレゼンテーションを識別するリクエストウリは、存在に十分です。
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.
サブスクライブリクエストに含めることができる1つのタイプのボディは、フィルタードキュメントです。これらのフィルターは、特定の存在イベントのみが通知を生成するか、通知リクエストで返されるデータセットの制限を要求することを要求します。たとえば、存在フィルターは、ユーザーのインスタント受信トレイ[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.
購読要求にフィルターが含まれていない場合、これはPAにフィルターが適用されないことを示します。PAは、独自のポリシーの裁量で通知リクエストを送信する必要があります。
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秒です。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ヘッダーフィールドにリストされている形式、またはサブスクライブから承認ヘッダーフィールドが省略された場合、パッケージ固有のデフォルトです。
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」プレゼンスデータ形式をサポートする必要があります。購読要求には、受け入れヘッダーフィールドが含まれる場合があります。そのようなヘッダーフィールドが存在しない場合、「アプリケーション/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仕様で定義されているプロキシルーティング手順に基づいて、サブスクライブリクエストはプレゼンスエージェント（PA）に到着します。このサブセクションは、購読要求のPAでパッケージ固有の処理を定義します。リクエストの一般的な処理ルールは、RFC 3265 [2]の一般的な購読処理に加えて、RFC 3261 [1]のセクション8.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で指定されているように、Digestが実装することが必須であることに注意してください。
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 [1]のセクション26.3.2.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メカニズムを適用して、サブスクライバーのIDを確立できます[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で自分自身を表現することを選択する場合があります。「表現そのもの」とは、プレゼンテーションで表現されたユーザーが、名刺、ウェブページなどで、プレゼンテーションのためにURIをSIPSすることを意味します。RFC 3261 [1]で説明されているように、このURIに関連するセマンティクスには、サブスクライバーと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.
認証のもう1つのメカニズムはS/MIMEです。SIPでの使用法は、RFC 3261 [1]で完全に説明されています。PAに使用してサブスクライバーのIDを確立することができるエンドツーエンド認証メカニズムを提供します。
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 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.
認証されると、PAは許可決定を下します。PAは、承認が提供されない限り、サブスクリプションを受け入れてはなりません。許可が提供される手段は、このドキュメントの範囲外です。おそらくWebページで指定されているアクセスリストを介して、承認が事前に提供されている可能性があります。承認は、何らかの標準化されたアクセス制御リストドキュメントのアップロードによって提供された可能性があります。直径[12]サーバーなどのバックエンド承認サーバーも使用できます。また、承認情報が提供されていないサブスクリプションリクエストの受領後、ユーザーに承認を照会できるようにすることも役立ちます。SIP [8]用の「WatcherInfo」イベントテンプレートパッケージは、ユーザーがそれを購読しようとしたことを認識し、認可決定を提供できるようにすることができる手段を定義します。
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]により、最初の通知の本体が空になります。存在の場合、その通知には存在ドキュメントが含まれる場合があります。このドキュメントは、サブスクライバーが確認することが許可されていると述べている存在感を示します。これは、サブスクライバーによって現在の存在状態と解釈されます。保留中のサブスクリプションの場合、プレゼンテーションの状態には、保留中のステータスを示す何らかのテキストノートを含める必要があります。
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を生成することで可能です。もちろん、即時の通知は引き続き送信されます。このような通知の存在文書の内容は、実装者の裁量でありますが、サブスクライバーに実際にブロックされていることをサブスクライバーに明らかにしないように構築する必要があります。通常、これは、単一の連絡先アドレスの「オフライン」または同等のステータスを示すことによって行われます。
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は、通知メッセージのフォーマットと構造を詳述しています。ただし、パッケージは、いつ通知を送信するか、リソースの状態をどのように計算するか、ニュートラルまたは偽の状態情報を生成する方法、および状態情報が完全か部分的かどうかに関する詳細な情報を提供することが義務付けられています。このセクションでは、プレゼンスイベントパッケージの詳細について説明します。
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リクエストには、現在の状態を示す本体が含まれている場合があります。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.
保留中のサブスクリプションの場合、最終的な承認が決定されると、通知を送信できます。承認の決定の結果が成功した場合、通知を送信する必要があり、現在の状態の存在文書を含める必要があります。サブスクリプションが拒否された場合、通知が送信される場合があります。RFC 3265 [2]で説明されているように、サブスクリプション状態のヘッダーフィールドは、サブスクリプションの状態を示します。
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の本文は、最新のサブスクライブリクエストのAccept Headerフィールドにリストされているタイプの1つを使用して、または受け入れヘッダーフィールドが存在しない場合は「アプリケーション/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を使用して実現できます。暗号化は、サブスクライブリクエストのFromフィールドで識別されるように、サブスクライバーのキーを使用して実行できます。同様に、通知の完全性は加入者にとって重要です。そのため、通知の内容は、S/MIMEを使用して認証とメッセージの整合性を提供する場合があります。Notifyはプレゼンスサーバーによって生成されるため、プレゼンテーションで表されるユーザーのキーにアクセスできない場合があるため、通知がサードパーティによって署名される場合があります。署名は、プレゼンテーションの領域をめぐる権限によって行うことをお勧めします。言い換えれば、ユーザーpres：user@example.comの場合、Notifyの署名者は、たとえば.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]は、イベントパッケージに任せて、コヒーレントリソース状態を形成するために必要なロジックを含む、通知要求を受け取ったときにサブスクライバーがそれに続くプロセスを記述します。
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にドキュメントが存在しない場合、Notifyに次に最高のCSEQ値を持つ存在ドキュメントが使用されます。プレゼンテーションに部分的な状態を使用することを指定する拡張は、コヒーレント状態の達成方法を決定する必要があります。
RFC 3265 [2] requires each package to describe handling of forked SUBSCRIBE requests.
RFC 3265 [2]では、各パッケージがフォーク付きサブスクライブリクエストの処理を説明する必要があります。
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.
この仕様では、初期サブスクライブリクエストを放出した結果として、単一のダイアログのみを構築できます。これにより、特定の提示の特定のサブスクリプションの通知を生成しているのは、単一の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 [2]のセクション4.4.9は、購読要求に応じて単一のダイアログの作成を保証するために必要な処理について説明します。
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によって操作されます。州のエージェントがこの状態を取得できる1つの方法は、それを購読することです。その結果、単一の提示に対して5つのPUA操作の存在状態があれば、州エージェントは各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認証メカニズムは、状態エージェントが使用できます。ただし、Digest認証では、州のエージェントがプレゼンティビティとサブスクライバーの間の共有秘密を認識する必要があります。これには、共有された秘密をプレゼンティから州のエージェントに安全に移転するための何らかの手段が必要です。
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はユーザーに承認を照会する必要があります。Edgent Edgeサーバー（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機能があるサーバーから別のサーバーに移行することは理にかなっています。たとえば、スケールの理由で、PA関数はPUAが実行されていないときに存在するサーバーに存在する場合がありますが、PUAがネットワークに接続すると、PAはネットワーク内の状態を減らすためにサブスクリプションを移行します。移行を達成するためのメカニズムは、RFC 3265 [2]のセクション3.3.5で説明されています。ただし、パッケージは、そのような移行がどの条件で行われるかを定義する必要があります。
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は、設定を介して、または動的手段を通じて、いつでもサブスクリプションを移行することを選択できます。レジスタリクエストは、機能がPUAに移行できることを発見するための1つの動的手段を提供します。具体的には、PUAがPA関数のサポートを示したい場合、Callee機能仕様[9]を使用して、購読要求方法とプレゼンスイベントパッケージをサポートすることを示す必要があります。これら2つの組み合わせはPAを定義します。もちろん、プレゼンスサーバーは、これらの明示的なヒントなしで常に移行を試みることができます。405または489の応答コードのいずれかで失敗した場合、サーバーはPUAがPA機能をサポートしていないことを知っています。この場合、サーバー自体はそのサブスクリプション要求のPAとして機能する必要があります。そのような失敗が発生したら、サーバーは登録期間中、そのPUAへのさらなる移行を試みるべきではありません。ただし、これらの失敗した要求によって生成される追加のトラフィックを回避するには、プレゼンスサーバーはCallee機能拡張機能をサポートする必要があります。
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.
さらに、購読要求とプレゼンスイベントパッケージのサポートの兆候は、サブスクリプションの移行には十分ではありません。PAは、複数のPUAから受信した集約された存在ドキュメントを構成している場合、サブスクリプションを移行しないでください。
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ネットワークに現在の通信アドレスを通知します（つまり、連絡先アドレス）。複数の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が登録データベースにアクセスし、そのデータベースの変更を通知できる場合にのみ可能です。それを達成する1つの方法は、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.
登録状態が存在状態に変換される手段は、ローカルポリシーの問題であり、この仕様の範囲を超えています。ただし、いくつかの一般的なガイドラインを提供できます。登録の住所（ヘッダーフィールドへ）は、プレゼンテーションを識別します。登録された各連絡先ヘッダーフィールドは、そのプレゼンテーションの通信ポイントを識別します。これは、タプルを使用してモデル化できます。タプルの連絡先アドレスは、登録された連絡先アドレスと同じである必要はないことに注意してください。代わりに、住所を使用すると、ウォッチャーからの後続の通信がプロキシを通過できます。これは、プレゼントとプロバイダーに代わって政策処理に役立ちます。
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 Callee機能拡張機能を使用する必要があります[9]。これにより、PUAはPAにそれ自体に関するより豊富な情報を提供することができます。たとえば、メソッド「メッセージ」をリストするメソッドパラメーターの存在は、インスタントメッセージングのサポートを示します。
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.
コンタクトヘッダーフィールド[1]のQ値を使用して、コンタクトヘッダーフィールドのさまざまな通信アドレスの中で相対的な優先順位を確立できます。
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.
プレゼンス情報を取得するための登録の使用により、登録の信頼性と整合性の要件が増加します。したがって、プレゼンスユーザーエージェントが使用する登録要求は認証する必要があります。
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.
PUAからPAにプレゼンスドキュメントをアップロードする手段が存在する場合、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.
コンテンツ長ヘッダーフィールドの値が「...」の場合、これは、値がボディの計算された長さが何であれ、必要であることを意味します。
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 subscribewatcher-> 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
F2 200 OK example.com server->watcher
F2 200 OK Example.com Server-> Watcher
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
F3 NOTIFY example.com server-> watcher
f3 example.com server-> watcherに通知します
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: ...
[PIDF Document]
[PIDFドキュメント]
F4 200 OK watcher-> example.com server
F4 200 OKウォッチャー - > 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
F5 NOTIFY example.com server -> watcher
f5 notify example.comサーバー - >ウォッチャー
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: ...
[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
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 [1]のセクション26.3.2で詳しく説明しています。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
S/MIMEを使用したSIP暗号化は、サブスクライブと通知の両方のリクエストを送信するためにエンドツーエンドを使用できます。
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.
メッセージ受信者は、メッセージの内容が実際に発信者によって送信されたものであり、メッセージの受信者がオリジネーターが実際に誰であるかを判断できることを確認することが重要です。これは、購読と通知のリクエストと応答の両方に適用されます。通知リクエストは特に重要です。認証と整合性がなければ、存在ドキュメントを偽造または修正し、ウォッチャーを誤った存在情報情報にだまします。
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とSIPをプロキシであるかのようにサポートする必要があります（RFC 3261のセクション26.3.1を参照）。
Furthermore, SMIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261.
さらに、サブスクライブおよび通知のリクエストの整合性と信ity性のために、SMIMEを使用することができます。これは、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リクエストに掲載された存在文書にはタイムスタンプが含まれている必要があります。PIDFの場合、これは[6]のセクション6で説明されているように、タイムスタンプ要素を使用して達成されます。タイムスタンプが最近受け取った存在書類のタイムスタンプよりも古いタプルは、古くなっていると見なされ、廃棄されるべきです。
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とウォッチャーの間に共有秘密がある場合、再生攻撃を防ぐために、HTTPダイジェスト認証（ウォッチャーとPAが実装する必要があります）を使用できます。そのような場合、ウォッチャーは、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）攻撃の優れた候補です。単一のサブスクライブメッセージは、適切に動的な存在データのソースが見つかる限り、ほぼ終了の通知のストリームを生成する可能性があります。したがって、ターゲットに対する攻撃を開始する簡単な方法は、サブスクリプションを多数のユーザーに送信し、コンタクトヘッダーフィールド（通知が送信される場所）で、ターゲットのアドレスを配置することです。RFC 3265は、これらの攻撃を緩和するためのいくつかのメカニズムを提供します[2]。Notifyが確認されていないか、必要でない場合、それを生成したサブスクリプションは削除されます。これにより、誤った連絡先アドレスを提供する増幅特性が排除されます。
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.
サービス拒否攻撃は、ユーザーのコミュニティへのサービスを混乱させるために、プレゼンスエージェント自体に対して開始することもできます。SIP自体は、RFC 3265 [2]とともに、これらの攻撃を緩和するためのいくつかのメカニズムを説明しています。
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.
サーバーは、ダイジェスト認証を使用して、4方向の握手を介してシン攻撃スタイルの攻撃を防ぐことができます[1]。サーバーがクライアントと共有秘密を持っていない場合でも、RFC 3261 [1]のセクション22.1で説明されている「匿名」ユーザーメカニズムを使用して、リクエストのソースIPアドレスを確認できます。SIPを使用すると、503の応答コード（RFC 3261 [1]のセクション21.5.4）を使用して、サーバーにクライアントにリクエストの送信をバックオフするよう指示できます。これを使用して、分散されたサービス拒否攻撃の結果として発売された購読要求の洪水をかわすことができます。
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.
連絡先：Jonathan Rosenberg、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 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: lennox@cs.columbia.edu
Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
Robert Sparks Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、Texas 75024
EMail: rsparks@dynamicsoft.com
Ben Campbell
ベン・キャンベル
EMail: ben@nostrum.com
Dean Willis dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
ディーン・ウィリス・ダイナミックソフト5100テニスン・パークウェイ・スイート1200プラノ、テキサス75024
EMail: dwillis@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: bernarda@microsoft.com
David Gurle Reuters Corporation
David Gurle Reuters Corporation
EMail: David.Gurle@reuters.com
David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134
David Oran Cisco Systems 170 West Tasman Dr. San Jose、CA 95134
EMail: 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.
リック・ワークマン、アダム・ローチ、ショーン・オルソン、ビリー・ビッグス、スチュアート・バークリー、マウリシオ・アランゴ、リチャード・ショッキー、ヨルゲン・ビョルクナー、ヘンリー・シン・エイカーズ、ポール・キジヴァット、ヤ・チング・タン、パトリック・ファルトストロム、アリソン・マンキンとヒシャムこの仕様のコメントとサポートについては、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、H.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[3] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2004年8月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[7] Dierks、T。およびC. Allen、「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] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[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。Rosenberg、J。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[10] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[11] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, May 2004.
[11] Peterson、J。、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理のための強化」、2004年5月の作業。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング /プレゼンスプロトコル要件」、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
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054
EMail: 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）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エディター機能の資金は現在、インターネット協会によって提供されています。