RFC3856 日本語訳
3856 A Presence Event Package for the Session Initiation Protocol(SIP). J. Rosenberg. August 2004. (Format: TXT=62956 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 3856 dynamicsoft Category: Standards Track August 2004
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3856dynamicsoft Category: 標準化過程2004年8月
A Presence Event Package for the Session Initiation Protocol (SIP)
セッション開始プロトコルのための存在イベントパッケージ(一口)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントは存在の購読と通知のためにSession Initiationプロトコル(SIP)の用法を説明します。 存在はユーザがネットワークで他のユーザとコミュニケートする意欲と能力と定義されます。 歴史的に、存在は「オンライン」の、そして、「オフライン」のインディケータに制限されました。 ここでの存在の概念は、より広いです。 存在の購読と通知は、一般的なSIPイベント通知フレームワークの中でイベントパッケージを定義することによって、サポートされます。 また、このプロトコルもCommon Presence Profile(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
1. 序論… 2 2. 用語… 3 3. 定義… 3 4. 操作の概要… 4 5. 存在URIの用法… 6 6. 存在イベントパッケージ… 7 6.1. 名前をパッケージしてください… 8 6.2. イベントパッケージパラメタ… 8 6.3. ボディーを申し込んでください… 8 6.4. 購読持続時間… 9 6.5. ボディーに通知してください… 9 6.6. より多くのNotifierに処理する、要求を申し込んでください… 9 6.6.1. 認証… 10 6.6.2. 承認… 10 6.7. Notifier世代、要求に通知してください… 11
Rosenberg Standards Track [Page 1] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[1ページ]RFC3856は存在2004年8月にちびちび飲みます。
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
6.8. 加入者、処理する、要求に通知してください… 13 6.9. 股状の要求の取り扱い… 13 6.10. 通知の速度… 14 6.11. エージェントを述べてください… 14 6.11.1. 集合、認証、および承認。 14 6.11.2. 移行… 15 7. 学習存在状態… 16 7.1. コロケーション… 16 7.2. 登録してください… 16 7.3. アップロード存在ドキュメント… 17 8. 例のメッセージ流動… 17 9. セキュリティ問題… 20 9.1. 秘密性… 20 9.2. メッセージの保全と信憑性… 21 9.3. 外国行きの認証… 22 9.4. 防止を再演してください… 22 9.5. サービス妨害は第三者に対して攻撃されます… 22 9.6. サービスの否定はサーバに対して攻撃されます… 23 10. IANA問題… 23 11. 貢献者… 24 12. 承認… 25 13. 標準の参照… 25 14. 有益な参照… 26 15. 作者のアドレス… 26 16. 完全な著作権宣言文… 27
1. Introduction
1. 序論
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.
また、存在情報として知られている存在はユーザが1セットのデバイスの向こう側に交信する能力と意欲を伝えます。 RFC2778[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
このドキュメントは存在プロトコルとしてSession Initiationプロトコル(SIP)[1]の用法を提案します。 これが通知フレームワークがSIP[2]、およびそのようなものと定義して、使用をする一般的なイベントの具体的な具体化を通して達成される、登録、そして、そこで定義されたNOTIFYメソッド。 明確に、このドキュメントはRFC3265[2]で説明されるようにイベントパッケージを定義します。 SIPは存在プロトコルとして特によく合っています。 SIP位置のサービスは登録証明書の形に既に存在情報を含んでいます。 その上、ユーザにとって、SIPネットワークはネットワークのどんなユーザから登録状態を支えるサーバまでのルーティング要求もできます。 この状態がユーザ存在の主要なコンポーネントであるのでそれら
Rosenberg Standards Track [Page 2] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[2ページ]RFC3856は存在2004年8月にちびちび飲みます。
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ネットワークは、登録を許容できます。同じサーバこれに発送されるという要求は、存在購読と通知のためにグローバルな接続性を証明するために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 Profile(CPP)フレームワークで対応します。 存在が他の存在と共にCPPへの対応することのシステムを容易に織り込むように、これはSIPを許容します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[4]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Definitions
3. 定義
This document uses the terms as defined in RFC 2778 [10]. Additionally, the following terms are defined and/or additionally clarified:
このドキュメントはRFC2778[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): Presence Userエージェントはpresentityのための存在情報を操ります。 この操作がある他の動作(新しいContactを加えるというSIP REGISTER要求を送ることなどの)の副作用であることができるか存在ドキュメントの公表を通して明らかにできます。 私たちは明らかに複数の1presentityあたりのPUAsを許します。 これは、ユーザが多くのデバイス(携帯電話やパーソナル・デジタル・アシスタント(PDA)などの)を持つことができることを意味します。それはそれぞれ独自にpresentityのための総合的な存在情報の成分を生成しています。 PUAsは存在システムにデータを押し込みます、それ登録を受けないので外部が通信するということであるかメッセージを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): 存在エージェントはSIPユーザエージェントです(存在状態の変化の通知をそれらに応じて、要求して、生成しながら、登録を受けることができます)。 存在エージェントには、presentityの存在状態に関する知識がなければなりません。 これは、presentityのためにPUAsによって操られた存在データに近づく手段を持たなければならないことを意味します。 これをする1つの方法はプロキシ/記録係がいるPAの共同場所を見つけることです。
Rosenberg Standards Track [Page 3] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[3ページ]RFC3856は存在2004年8月にちびちび飲みます。
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.
別の方法はpresentityの存在ユーザエージェントと共にそれの共同場所を見つけることです。 しかしながら、これらは唯一の道ではありません、そして、この仕様はPA機能が位置するべきであるところに関して推薦状を全くしません。 PAは唯一、presentity(すなわち、一口: joe@example.com )を特定するSIP URIと共にいつもアドレス可能です。 複数のPAsが特定のpresentityのためにあることができます。それはそれぞれpresentityに、現在活発な総購読の何らかの部分集合を扱います。 また、PAはnotifierです。(存在イベントパッケージを支えるRFC3265[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として機能するとき、それはいくつかのプロトコル手段でpresentityの存在情報を意識しています。 登録、要求はそうです。プロキシとして務めるとき、proxiedする、PAとして機能するかもしれない別の実体に、proxiedしました。
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と共に共同見つけられている存在エージェントです。 それは、この存在情報を操る実体で共同見つけられているので、presentityの存在情報を意識しています。
4. Overview of Operation
4. 操作の概要
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.
実体(加入者)が存在情報に関してユーザから学びたがっているとき、それは登録を作成します。要求します。 この要求はRequest-URIで必要なpresentityを特定します、SIP URI、SIPS URI[1]または存在(pres)URI[3]を使用して。 登録、要求はそうです。いかなる他のSIPも要求するように運ばれたSIPプロキシがあるでしょう。 多くの場合、結局要求(その場合、それはpresentityの存在エージェントとして務める)への応答を生成することができる存在サーバかプロキシに到着する、それ、縁の存在サーバにオンである. 縁の存在サーバが購読を扱うなら、それはpresentityの存在エージェントとして務めています。 存在サーバにおける決定、周囲でプロキシに終わってください、登録、地域にかかわる事柄はそうです。 しかしながら、REGISTERを使用して、私たちはそのような構成に作用する1つの方法を述べます。
Rosenberg Standards Track [Page 4] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[4ページ]RFC3856は存在2004年8月にちびちび飲みます。
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.
存在エージェント(存在サーバか縁の存在サーバにかかわらず)は、最初に、購読を認証して、次に、それを認可します。 このプロトコルの範囲の外に承認のための手段があります、そして、私たちは多くのメカニズムが使用されると予想します。 認可するなら、200OK応答を返します。 このとき承認を得ることができないなら、「未定である」と購読を考えます、そして、202応答を返します。 どちらの場合も、PAはpresentityと購読の状態を含む即座のNOTIFYメッセージを送ります。 例えば、presentityの実際の状態が何であってもオフラインで示して、presentity状態は未定の購読の場合でにせであるかもしれません。 これは、presentityのプライバシーを保護するためのものです。(presentityは、彼らが承認を加入者に提供していないのを明らかにしたがっていないかもしれません)。 presentity変化の状態として、PAはすべての加入者への認可された購読があるそれらの州の変化を含むNOTIFYsを生成します。 また、購読自体の状態の変化はNOTIFY要求の引き金となることができます。 その州は、NOTIFYのSubscription-州のヘッダーフィールドで運ばれて、購読が活発であるか、または未定であるかを通常示すでしょう。
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.
登録、メッセージは存在エージェントと共に「対話」を設立します。 対話はRFC3261[1]で定義されます、そして、それはピアツーピア交換処理を容易にするために1組の実体の間のSIP状態を表します。 この州は両方の方向によるメッセージのための一連番号を含めます(加入者から登録、存在エージェントからのNOTIFY)、ルートセットとリモート目標URIに加えて。 ルートセットが経路に沿って訪問されることになっているSIPプロキシサーバを特定するSIP(または、SIPS)URIのリストである、登録、リフレッシュ、または、NOTIFY要求。 リモート目標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はNOTIFYの経路にあるのが通信して、登録よう要求するプロキシサーバがリフレッシュするのでそれが許す記録的なルーティングと呼ばれる手順を提供します。 これが初期のRecord-ルートヘッダーフィールドに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.
購読は初期の一部として交渉される持続時間のために持続しています。登録。 彼らが購読を保有したいなら、加入者は、満了の前に購読をリフレッシュする必要があるでしょう。 これによる登録が同じくらい中でリフレッシュする発信で達成されて、対話が、初期で登録を確証したということです。 これ、登録、初期のものとほとんど同じですが、要求が連れて行くことになっているプロキシの経路を特定するToヘッダーフィールド、より高いCSeqヘッダーフィールド価値、およびことによると1セットのRouteヘッダーフィールド値にタグを含んでいます。
Rosenberg Standards Track [Page 5] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[5ページ]RFC3856は存在2004年8月にちびちび飲みます。
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ヘッダーフィールド(購読の持続時間を示す)値で。 これは購読の即座の終了を引き起こします。 そして、NOTIFY要求は最新の州の存在エージェントによって生成されます。 事実上、登録がゼロのExpiresと共に要求する取り扱いのための存在エージェントの振舞いはいかなる他の満了値ほども異なっていません。 未定であるか認可される、登録、要求は現在のpresentityと購読状態がある引き起こされたNOTIFYをもたらします。
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-州のヘッダーフィールドが、購読が終えられたのを示していて、それは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.
また、現状を含む1回の通知をもたらして、現在の存在状態をとって来るのも可能です。 これは、即座の満了と共に要求を登録に送ることによって、達成されます。
5. Usage of Presence URIs
5. 存在URIの用法
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.
presentityは存在URI[3]を通して最も一般的な方法で特定されます: user@domain 。URIはフォームpresのものです。 これらのURIは特定のURIについて議定書の中で述べるために決議されています、SIPやSIPS 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(そして/または、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を学びます。 登録、例、URI意志の結果が中で要求で200OKのContactヘッダーフィールドからのpresentityのためのSIPかSIPS URIをpresに学んだ登録、要求。 別の例と、pres URIのルックアップがSIPかSIPS URIを入手できるDNSメカニズムは定義されるかもしれません。 1つのURIが別のものからプロトコル手段で学習される場合では、それらの手段は学術的URIの生涯を制限するある種の見ることをしばしば提供するでしょう。 例えば、DNSはURIの範囲を制限するTTLを提供します。 これらの範囲は、同じリソースを特定するために聞き古した闘争しているURIを避けるために非常に役に立ちます。 ユーザが、いつも学術的URIがまだ有効であるかどうかと決心できるのを保証するために、存在URIのためのルックアップサービスを提供するシステムがある種の見るメカニズムを持っているのは、RECOMMENDEDです。
Rosenberg Standards Track [Page 6] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[6ページ]RFC3856は存在2004年8月にちびちび飲みます。
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.
presentityだけにおいて、加入者がプロトコルから独立しているpres URIを意識しているなら、それは[5]で定義された手順に従います。 これらの手順はホストがSIP要求を送ることを決定する[5]で定義されたDNS手順の用法があとに続いたSIP要求のRequest-URIにおける、pres URIのプレースメントをもたらすでしょう。 もちろん、あるいはまた、地元の外国行きのプロキシはRFC3261[1]で指定されるように使用されるかもしれません。 加入者がプロトコルから独立しているpres URIとSIPの両方を意識しているか、そして、同じくらいのためのSIPS URIがpresentityします、そして、両方が有効です。(議論された上) それとして、SHOULDはpres URI形式を使用します。 もちろん、加入者がpresentityでSIP URIを知っているだけであるなら、そのURIは使用されています、そして、標準のRFC3261処理は起こるでしょう。 いつで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.
登録、また、メッセージは購読(ToとFromヘッダーフィールド)の創始者と受取人を定義する論理的な識別子を含んでいます。 これらのヘッダーはpresかSIP URIのどちらかを取ることができます。 加入者はpresとそれ自身のアイデンティティのためのSIP URIの両方を意識しています、それ。いつ、SHOULDはFromヘッダーフィールドにpres URIを使用するか。 加入者が両方を意識しているとき、同様に、presと必要のためのSIP URIはpresentityします、それ。SHOULDはToヘッダーフィールドに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を変換することによって、これをします: <はSIP URI>@<ゲートウェイ>をコード化しました。 これは、メールシステムで一般的にして、pres URIをサポートしないSIPの部品でどんな存在しているゲートウェイもないのが知られているか、またはpres URIの用法が相互運用性問題を引き起こすケースを考慮するために. pres URIの用法がaではなく、SHOULDであるのにおける知られている問題が持たなければならない多くを持っています。
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.
Contact、Record-ルート、およびRoute分野は論理的な実体ではなく、SIPメッセージングに使用されるかなり具体的なものを特定します。 SIP[1]は彼らの工事のための規則を指定します。
6. Presence Event Package
6. 存在イベントパッケージ
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
SIPイベントフレームワーク[2]はイベントについて申し込んで、通知を受け取るためのSIP拡張子を定義します。 それ、拡大が具体的であるようにこれらのイベントの多くの局面の定義を残して、知っています。
Rosenberg Standards Track [Page 7] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[7ページ]RFC3856は存在2004年8月にちびちび飲みます。
event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 [2].
イベントパッケージ。 このドキュメントはイベントパッケージの資格を得ます。 このセクションはすべてのイベントパッケージのためにRFC3265[2]によって必要とされた情報に記入します。
6.1. Package Name
6.1. パッケージ名
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.
このパッケージの名前は「存在」です。 この値がRFC3265[2]で指定されるようにEventヘッダー分野で存在しているように見える、登録、そして、NOTIFY要求。
Example:
例:
Event: presence
イベント: 存在
6.2. Event Package Parameters
6.2. イベントパッケージパラメタ
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イベントフレームワークで、イベントパッケージはEventヘッダーフィールドで運ばれた追加パラメタを定義できます。 このパッケージ(存在)はどんな追加パラメタも定義しません。
6.3. SUBSCRIBE Bodies
6.3. ボディーを申し込んでください。
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.
イベントパッケージ名に結合したRequest-URI(presentityを特定する)は存在に十分です。
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つ。 これらのフィルタは、ある存在イベントだけが通知を生成するよう要求するか、または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.
登録、要求はそうしません。これは、適用されるためにフィルタを含んでください、そして、どんなフィルタもそうでないとPAに言います。 PA SHOULDはそれ自身の方針の裁量で要求をNOTIFYに送ります。
Rosenberg Standards Track [Page 8] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[8ページ]RFC3856は存在2004年8月にちびちび飲みます。
6.4. Subscription Duration
6.4. 購読持続時間
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秒です。 RFC3265[2]に従って、加入者はExpiresヘッダーフィールドにおける代替の満了を指定するかもしれません。
6.5. NOTIFY Bodies
6.5. ボディーに通知してください。
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.
RFC3265[2]で説明されるように、NOTIFYメッセージは申し込まれたリソースの状態について説明するボディーを含むでしょう。 このボディーが形式がAcceptヘッダーフィールドで記載したコネである、登録、パッケージ詳細がヘッダーフィールドが省略された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.
このイベントパッケージでは、通知のボディーは存在ドキュメントを含みます。 このドキュメントは加入されたpresentityの存在について説明します。 すべての加入者とnotifiersは、「アプリケーション/pidf+xml」存在が[6]で説明されたデータの形式であるとサポートしなければなりません。 5月がAcceptヘッダーフィールドを含んでいるという要求を申し込んでください。 そのような何かヘッダーフィールドが存在していないなら、それには、「アプリケーション/pidf+xml」のデフォルト値があります。 ヘッダーフィールドが存在しているなら、それは、「アプリケーション/pidf+xml」を含まなければならなくて、ユーザ存在を表すことができるいかなる他のタイプも含むかもしれません。
6.6. Notifier Processing of SUBSCRIBE Requests
6.6. より多くのNotifierに処理する、要求を申し込んでください。
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で処理されるパッケージ詳細要求を定義します。 要求がRFC3261[1]のセクション8.2でカバーされていること一般的に加えて一般処理は、登録と裁決します。RFC3265[2]での処理。
Rosenberg Standards Track [Page 9] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[9ページ]RFC3856は存在2004年8月にちびちび飲みます。
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に課されます。
6.6.1. Authentication
6.6.1. 認証
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.
存在エージェントはすべての購読要求を認証しなければなりません。 この認証はRFC3261[1]で定義されたメカニズムのどれかを使用し終わることができます。 RFC3261で指定されるようにダイジェストが実行するために義務的であることに注意してください。
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].
単一領域システムでは、Transport Layer Security(TLS)[7]の上のダイジェスト認証の組み合わせは安全、そして、実行し得る解決法を認証に提供します。そこで、加入者は皆、PAと秘密を共有しました。 ケースはセクション26.3で説明されます。この使用、.2 .1RFC3261[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].
相互ドメインシナリオでは、加入者の認証されたアイデンティティを確立するのは、より困難です。 認証が他動な信用でしばしば確立されると予期されます。 加入者[11]のアイデンティティを証明するためにアイデンティティであると断言されたネットワークのためのSIPメカニズムを適用できます。
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.
presentityは、SIPS URIと共にそれ自体を表すのを選ぶかもしれません。 「それ自体を表してください」で、それは、presentityによって代理をされたユーザが名刺の上にウェブページなど(それらのpresentityのためのSIPS URI)を与えることを意味します。 意味論がRFC3261[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.
認証のための別のメカニズムはS/MIMEです。 SIPがある用法はRFC3261[1]で完全に説明されます。 それは終わりから終わりへのPAが加入者のアイデンティティを証明するのに使用できる認証機構を提供します。
6.6.2. Authorization
6.6.2. 認可
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は認可決定をします。 認可がpresentityによって提供されていない場合、PAは申し込みに応じてはいけません。 このドキュメントの範囲の外に認可がどれであるかによって提供された手段があります。 早めに、恐らくウェブページで指定されたアクセスリストを通して認可を提供したかもしれません。 ある種の標準化されたアクセスコントロールリストドキュメントのアップロードによって認可を提供したかもしれません。 また、DIAMETER[12]サーバなどのバックエンド認可サーバがあることができます。
Rosenberg Standards Track [Page 10] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[10ページ]RFC3856は存在2004年8月にちびちび飲みます。
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[8]のための"watcherinfo"イベントテンプレートパッケージはpresentityがユーザが、それに加入するのを試みたのを意識するようになることができる手段を定義します、次に、認可決定を提供できるように。
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つの州の1つに写像できます: 拒絶されて、うまくいって、未定です。 クライアントが時間内に諸点で存在状態の何らかの部分集合の情報を受け取るのに権限を与えられるどんな購読もうまくいっている購読です。 クライアントが存在状態のどんな部分集合のどんな情報も決して受け取らないどんな購読も拒絶された購読です。 それがうまくいきますかそれとも拒絶されているかがまだ知られていないどんな購読も未定です。 一般に、未定の購読は、サーバが購読時点で認可を得ることができないとき、起こりますが、後でそうすることができるかもしれません、恐らくpresentityが利用可能になると。
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)を伝えるための適切な応答コードはRFC3265[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.
リソースが重要な状態にないなら、RFC3265[2]は、初期のNOTIFYのボディーが空であることを許容します。 存在の場合では、そのNOTIFY MAYは存在ドキュメントを含んでいます。 このドキュメントは加入者が見るのを権限を与えられたどんな存在状態も示すでしょう。 それはpresentityの現在の存在状態として加入者によって解釈されます。 未定の購読のために、presentity SHOULDの州は未定の状態を示すある種の原文の注意を含めます。
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]で説明される礼儀正しいブロッキングはそれが拒絶されましたが(または、未定であるとマークされます)、200OKを購読に発生させることによって、可能です。 もちろん、それでも、即座のNOTIFYを送るでしょう。 しかし、作成者、SHOULDの裁量にはそのようなNOTIFYの存在ドキュメントのコンテンツがあります。彼らの要求が実際に妨げられたのを加入者に明らかにしないほどそのような方法で組み立てられます。 通常、ただ一つの連絡先のために「オフライン」の、または、同等な状態を示すことによって、これをします。
6.7. Notifier Generation of NOTIFY Requests
6.7. Notifier世代、要求に通知してください。
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
RFC3265はNOTIFYメッセージの形式と構造について詳述します。 しかしながら、パッケージはいつNOTIFYを送るかの詳細な情報を提供するために強制されます、どうリソースの状態を計算するか、どのように
Rosenberg Standards Track [Page 11] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[11ページ]RFC3856は存在2004年8月にちびちび飲みます。
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.
中立を発生させるか、または見せかけるには、州の情報が情報的であって完全であるか、または部分的であるかを述べてください。 このセクションは存在イベントパッケージのためのそれらの詳細について説明します。
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を送るかもしれません。 presentityの状態が変化するとき、通常、それは1つを送るでしょう。 NOTIFY要求はpresentityの状態を示すボディーを含むかもしれません。 NOTIFYが特定の加入者のために送られる回、およびその通知の中のボディーのコンテンツは購読を治める認可方針で指定されたどんな規則も受けることがあります。 このプロトコルはそのような方針の範囲を決して制限しません。 基線として、合理的な方針は存在tuplesのどれかの状態が変化するとき、通知を発生させることです。 これらの通知は存在エージェントへの知られるとしてのpresentityの完全で現在の存在状態を含んでいるでしょう。 加入者が、通知が完全な状態より単に、そして、むしろ存在情報における変化を含むよう要求できる今後の拡大を定義できます。
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を送ることができます。 送られて、成功、aは認可決定の結果であるならNOTIFY SHOULDでした。SHOULDはpresentityの現状がある存在ドキュメントを含んでいます。 購読が拒絶されたa NOTIFY MAYであるなら、送ってください。 RFC3265[2]で説明されるように、Subscription-州のヘッダーフィールドは購読の状態を示します。
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.
ボディー、どんなAcceptヘッダーフィールドも存在していなかったならタイプの送られた使用ひとりが、最新のAcceptヘッダーフィールドで登録と「pidfであるかアプリケーション/xmlで」タイプを要求するか、または使用することで記載したというNOTIFY MUSTでは、ことになってください。
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がpresentityの状態を学ぶ手段があります。 登録証明書はpresentity状態のコンポーネントを提供できます。 しかしながら、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
通知のコンテンツをコード化するのは頻繁にプライバシーの理由に、必要になるでしょう。 S/MIMEを使用することでこれを達成できます。 From分野で特定されるように加入者のキーを使用することで暗号化を実行できる、登録、要求。 同様に、加入者には、通知の保全は重要です。 そういうものとして、S/MIMEを使用して、通知のコンテンツは認証とメッセージの保全を提供するかもしれません。 NOTIFYが存在サーバで発生するので、どれに、アクセスがないかもしれないか。
Rosenberg Standards Track [Page 12] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[12ページ]RFC3856は存在2004年8月にちびちび飲みます。
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.
presentityによって代理をされたユーザのキー、頻繁にNOTIFYが第三者によってサインされるのは、事実でしょう。 署名がpresentityのドメインの上の権威であるのは、RECOMMENDEDです。 ユーザが権威がfor example.comであったなら言い換えれば: user@example.com 、NOTIFY SHOULDのsignatorをpresするので。
6.8. Subscriber Processing of NOTIFY Requests
6.8. 加入者、処理する、要求に通知してください。
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.
RFC3265[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はpresentityの完全で一貫性を持っている状態を表さないどんな存在ドキュメントもドキュメントのどちらかも含んでいます。 対話の中では、最も高いCSeqヘッダーフィールド価値があるNOTIFY要求における存在ドキュメントは現在のものです。 どんなドキュメントもそのNOTIFYに存在していないとき、NOTIFYの次の最も高いCSeq値の現在の存在ドキュメントは使用されています。 部分的な状態のpresentitiesの使用を指定する拡張子は、コヒーレント状態がどう獲得されるかを書き取る必要があるでしょう。
6.9. Handling of Forked Requests
6.9. 股状の要求の取り扱い
RFC 3265 [2] requires each package to describe handling of forked SUBSCRIBE requests.
[2]が、各パッケージが取り扱いについて説明するのを必要とするRFC3265が分岐した、登録、要求。
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だけが特定のpresentityの特定の購読のための通知を発生させているのを保証します。 この結果はpresentityが複数のPAsをアクティブにすることができますが、これらが均質であるべきであるということです、それぞれがpresentityのための同じセットの通知を発生させることができるように。 異種のPAsを支持するのは、複雑であって、管理するのは難しいです。それは存在データの部分集合のための通知をそれぞれ発生させます。 そうするのは、加入者が存在データのためのアグリゲータとして務めるのを必要とするでしょう。 presentityを表すエージェントは合理的にこの総計機能を実行できるだけです。 したがって、集合を必要とするなら、presentityを表して、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.
.9セクション4.4RFC3265[2]が登録に対応したただ一つの対話の創造が要求する保証に必要である処理について説明します。
Rosenberg Standards Track [Page 13] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[13ページ]RFC3856は存在2004年8月にちびちび飲みます。
6.10. Rate of Notifications
6.10. 通知の速度
RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent.
RFC3265[2]は、通知を送ることができる最高率を指定するために各パッケージを必要とします。
A PA SHOULD NOT generate notifications for a single presentity at a rate of more than once every five seconds.
PA SHOULD NOTは5秒あたりの一度以上の速度で単一のpresentityのための通知を発生させます。
6.11. State Agents
6.11. 州のエージェント
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.
RFC3265[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.
州のエージェントはこのパッケージへのコアです。 presentityのためのPUAと共に共同見つけられていないときはいつも、PAは州のエージェントとして務めています。 それは、PUAから存在状態を集めて、それを存在ドキュメントに集めます。 複数のPUAがあることができるので、中央主権国家のエージェントがこの集合を実行するのに必要です。 それは州のエージェントが存在に基本的である理由です。 本当に、彼らには、それらについて説明する種の用語があります--存在サーバ。
6.11.1. Aggregation, Authentication, and Authorization
6.11.1. 集合、認証、および認可
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.
集合が州のエージェントで行われる手段は純粋に方針の問題です。 方針はプロバイダーの願望に伴うpresentityの願望を通常結合するでしょう。 このドキュメントは適用されるかもしれない方針のセットを決して制限しません。
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.
しかしながら、明確に、州のエージェントがpresentityの状態に近づく手段を持つ必要があります。 この状態はPUAによって操られます。 州のエージェントがこの状態を得ることができる1つの方法はそれに加入することです。 その結果、単一のpresentityのために存在状態を操る5PUAがあれば、州のエージェントは5つの購読(各PUAへの1)を発生させるでしょうに。 有効であってください、すべてのPUA SHOULD。このメカニズム、彼らが操って、認証できる購読を認可する状態へのpresentityのドメインから来る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認証機構のいずれも使用できます。 しかしながら、ダイジェスト認証は、州のエージェントがpresentityと加入者の間の共有秘密キーを意識しているのを必要とするでしょう。 これはpresentityから州のエージェントまでしっかりと共有秘密キーを移すいくつかの手段を必要とするでしょう。
Rosenberg Standards Track [Page 14] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[14ページ]RFC3856は存在2004年8月にちびちび飲みます。
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]の理由です。 すべての州のエージェントSHOULDがwatcherinfoテンプレートパッケージを支えます。
6.11.2. Migration
6.11.2. 移動
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機能のために、1つのサーバから別のサーバまで移動するのは理解できます。 スケールの理由で、PUAが走っていないとき、例えば、PA機能が存在サーバであるかもしれませんが、PUAがネットワークに接続するときPAが移動する、購読、それに、減少するために中にネットワークを述べてください。 移動を実行するためのメカニズムは.5セクション3.3RFC3265[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つのダイナミックな手段を提供します。 明確に、PAのサポートを示すという願望がPUAであるなら機能して、それがSHOULD使用である、示すそれが支持する訪問される人能力仕様[9]、登録、方法と存在イベントパッケージを要求してください。 これらの2の組み合わせはPAを定義します。 もちろん、存在サーバはこれらの明白なヒントなしで移動をいつも試みることができます。 どちらかで405か489応答コードに失敗するなら、サーバは、PUAがPA機能をサポートしないのを知っています。 この場合、サーバ自体は、その購読要求のためのPAとして機能する必要があるでしょう。 そのような失敗がいったん起こると、サーバSHOULD NOTは登録の持続時間のためにそのPUAにさらなる移動を試みます。 しかしながら、これらの失敗した要求、存在サーバで発生する余分な交通を避けるために、SHOULDは訪問される人能力拡大を支持します。
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 SHOULD NOTは移動します。構成しているなら、購読は複数のPUAから受け取られた存在ドキュメントに集められました。
Rosenberg Standards Track [Page 15] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[15ページ]RFC3856は存在2004年8月にちびちび飲みます。
7. Learning Presence State
7. 学習存在状態
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は様々な意味で存在情報を得ることができます。 どんな特定のメカニズムもこの仕様で強制されません。 これは情報の目的だけのためのオプションについて概観をいくつか区分します。
7.1. Co-location
7.1. コロケーション
When the PA function is co-located with the PUA, presence is known directly by the PA.
PA機能がPUAと共に共同見つけられているとき、存在は直接PAによって知られています。
7.2. REGISTER
7.2. レジスタ
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は現在のコミュニケーションアドレス(すなわち、Contactアドレス)についてSIPネットワークに知らせるSIP REGISTER方法を使用します。 複数のUAが独自に同じ記録されている住所のためのContactアドレスを登録できます。 この登録州はpresentityのための総合的な存在情報の重要な断片を表します。 それはコミュニケーションのための基本的な可到達性のしるしです。
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情報の用法は可能です。 それを達成する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.
登録状態が存在状態に変えられる手段は、ローカルの方針の問題であり、この仕様の範囲を超えてそうです。 しかしながら、いくつかの一般的ガイドラインを提供できます。 登録(Toヘッダーフィールド)における記録されている住所はpresentityを特定します。 それぞれの登録されたContactヘッダーフィールドはtupleを使用することでモデル化できるそのpresentityのためのコミュニケーションのポイントを特定します。 tupleの連絡先が登録された連絡先と同じである必要はないことに注意してください。 記録されている住所を使用するのに、ウォッチャーからのその後のコミュニケーションは代わりにプロキシを通り抜けることができます。 これはpresentityとプロバイダーを代表して方針処理の役に立ちます。
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.
SHOULDがSIP訪問される人能力拡張子[9]の使用をする存在状態を操るのに登録証明書を使用するPUA。 これで、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.
様々なコミュニケーションアドレスの中で相対的なプライオリティをContactヘッダーフィールドに証明するのにContactヘッダーフィールド[1]からのq値を使用できます。
Rosenberg Standards Track [Page 16] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[16ページ]RFC3856は存在2004年8月にちびちび飲みます。
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要求を認証しなければなりません。
7.3. Uploading Presence Documents
7.3. アップロード存在ドキュメント
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から受け取られた存在ドキュメントを同じpresentityに連れて行って、それらのPUAのすべての向こう側にただ一つの存在ドキュメントにtuplesを合併するでしょう。 通常、この集合は集合がどう完了しているべきであるかに関する管理者かユーザの定義された方針で達成されるでしょう。
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に加入者に分配される存在の直接操作がありたいとき、存在ドキュメントのダイレクトアップロードはRECOMMENDEDです。
8. Example Message Flow
8. 例のメッセージ流動
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.
このメッセージ流動は存在サーバがどうpresentityのために通告を送るのに原因となる場合があるかを例証します。 この流れは、以前にウォッチャーがサーバでこのリソースに加入するのに権限を与えられたと仮定します。
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-長さのヘッダーフィールドの値がある」とき、」 これは、値がボディーの計算された長さがことなら何でもであるべきであるか意味します。
Rosenberg Standards Track [Page 17] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[17ページ]RFC3856は存在2004年8月にちびちび飲みます。
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
ウォッチャーサーバPUA| F1は申し込まれます。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| F2 200OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| F3は通知します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| F4 200OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、| アップデート存在| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| F5は通知します。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| F6 200OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|
Message Details
メッセージの詳細
F1 SUBSCRIBE watcher->example.com server
登録、F1ウォッチャー->、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
一口: 登録、 resource@example.com SIP/2.0Via: 一口/2.0/TCP watcherhost.example.com; ブランチ=z9hG4bKnashds7To: <一口: resource@example.com 、gt;、From: <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com CSeq: 17766 前方へマックスを申し込んでください: 70出来事: 存在Accept: アプリケーション/pidf+xml Contact: <一口: user@watcherhost.example.com 、gt;、期限が切れます: 600 コンテンツの長さ: 0
Rosenberg Standards Track [Page 18] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[18ページ]RFC3856は存在2004年8月にちびちび飲みます。
F2 200 OK example.com server->watcher
F2 200が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
以下を通って一口/2.0 200OK 一口/2.0/TCP watcherhost.example.com; ブランチはz9hG4bKnashds7と等しいです; =192.0.2.1To:を受けます。 <一口: resource@example.com 、gt;、;=ffd2From:にタグ付けをしてください <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com CSeq: 17766が申し込まれる、期限が切れます: 600 接触: 一口: server.example.com Content-長さ: 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: ...
NOTIFY一口: user@watcherhost.example.com SIP/2.0Via: 一口/2.0/TCP server.example.com; ブランチ=z9hG4bKna998sk From: <一口: resource@example.com 、gt;、;=ffd2To:にタグ付けをしてください <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com 出来事: 存在Subscription-州: 能動態; 前方へ=599マックスを吐き出します: 70CSeq: 8775は接触に通知します: 一口: server.example.comコンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[PIDF Document]
[PIDFドキュメント]
F4 200 OK watcher-> example.com server
F4 200OKウォッチャー->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
以下を通って一口/2.0 200OK 一口/2.0/TCP server.example.com; ブランチはz9hG4bKna998skと等しいです; =192.0.2.2From:を受けます。 <一口: resource@example.com 、gt;、;=ffd2To:にタグ付けをしてください <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com CSeq: 8775はコンテンツの長さに通知します: 0
Rosenberg Standards Track [Page 19] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[19ページ]RFC3856は存在2004年8月にちびちび飲みます。
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: ...
NOTIFY一口: user@watcherhost.example.com SIP/2.0Via: 一口/2.0/TCP server.example.com; ブランチ=z9hG4bKna998sl From: <一口: resource@example.com 、gt;、;=ffd2To:にタグ付けをしてください <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com CSeq: 8776は出来事に通知します: 存在Subscription-州: 能動態; 前方へ=543マックスを吐き出します: 70 接触: 一口: server.example.comコンテントタイプ: アプリケーション/pidf+xml Content長さ: ...
[New PIDF Document]
[新しいPIDFドキュメント]
F6 200 OK
F6 200OK
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
以下を通って一口/2.0 200OK 一口/2.0/TCP server.example.com; ブランチはz9hG4bKna998slと等しいです; =192.0.2.2From:を受けます。 <一口: resource@example.com 、gt;、;=ffd2To:にタグ付けをしてください <一口: user@example.com 、gt;、; =xfg9呼び出しIDにタグ付けをしてください: 2010@watcherhost.example.com CSeq: 8776はコンテンツの長さに通知します: 0
9. Security Considerations
9. セキュリティ問題
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.
存在において多数のセキュリティ問題があります。 RFC2779[13]はそれらの多くについて概説します、そして、上でそれらについて議論します。 このセクションは、問題でそれらが問題であると考えます。
9.1. Confidentiality
9.1. 秘密性
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 通知(結果をとって来る)は加入者以外のだれにも明らかにされるべきでない極秘データを含むかもしれません。
Rosenberg Standards Track [Page 20] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[20ページ]RFC3856は存在2004年8月にちびちび飲みます。
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]がこの機能を提供するのに要素の間で使用されるのは、RECOMMENDEDです。 サーバからサーバとクライアントからサーバへのセキュリティのためのTLSの使用法のための詳細は.2セクション26.3RFC3261[1]で詳細です。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
S/MIMEを使用して、SIP暗号化が中古の両方のトランスミッションのための終わりから終わりであるかもしれない、登録、そして、NOTIFY要求。
9.2. Message Integrity and Authenticity
9.2. メッセージの保全と信憑性
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.
メッセージ受取人が、メッセージ内容が実際に創始者によって送られたものであり、メッセージの受取人が、創始者が本当にだれであるかを決定できるのを保証するのは、重要です。 これが要求と応答の両方に適用する、登録、そして、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).
RFC3261は、これらの特徴を提供するために多くのメカニズムを提供します。 PAがウォッチャーを認証するように、それはHTTP Digest(RFC3261のセクション22)を使用するかもしれません。 その結果、すべてのウォッチャーがHTTP Digestをサポートしなければなりません。 すべてのSIPユーザエージェントがRFC3261でそれをサポートするために強制されるので、しかしながら、これは余分な要件です。 presentityに加入するとき、信憑性と保全にサービスを提供するために、ウォッチャーはSIPS体系を使用するかもしれません。 これをサポートするために、すべてのPAがまるで彼らがプロキシであるかのようにTLSとSIPSをサポートしなければなりません(.1セクション26.3RFC3261を見てください)。
Furthermore, SMIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261.
その上、SMIME MAY、保全と信憑性に使用されてください、登録、そして、NOTIFY要求。 これはRFC3261のセクション23で説明されます。
Rosenberg Standards Track [Page 21] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[21ページ]RFC3856は存在2004年8月にちびちび飲みます。
9.3. Outbound Authentication
9.3. 外国行きの認証
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.
地元のプロキシが外国行きのメッセージの伝達に使用されるとき、プロキシ認証はRECOMMENDEDです。 これは、創始者のアイデンティティについて確かめて、起因するネットワークにだまして、ばらまくのを防ぐために役に立ちます。
9.4. Replay Prevention
9.4. 再生防止
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.
攻撃者は、ウォッチャーが、presentityのために時代遅れの存在が状態であると信じているようにだますのに反射攻撃を使用できます。 例えば、presentityが「オフラインである」と記述するドキュメントは再演できます、ウォッチャーが、ユーザが決してオンラインでないと考えるようにだまして。 事実上、これは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要求ボディーの上にメッセージの保全と認証を提供できます。 ウォッチャーとPAsは、これらの反射攻撃を防ぐためにS/MIME署名を実装するかもしれません。 それがそのために使用されるとき、NOTIFY要求で運ばれた存在ドキュメントはタイムスタンプを含まなければなりません。 PIDFの場合では、これは[6]のセクション6で説明されるようにタイムスタンプ要素を使用するのに優れています。 タイムスタンプが大部分に関するタイムスタンプが最近存在を受けたより古いTuplesは聞き古したである考えられて、捨てられたSHOULDを記録します。
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.
最終的に、HTTPダイジェスト認証(ウォッチャーとPAsは実装しなければならない)は反射攻撃を防ぐのに使用されるかもしれません、PAとウォッチャーの間に共有秘密キーがあるとき。 このような場合には、ウォッチャーは保護のauth-int品質でNOTIFY要求に挑戦できます。
9.5. Denial of Service Attacks Against Third Parties
9.5. 第三者に対するサービス不能攻撃
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)攻撃は開いている相互ドメイン、存在プロトコルのための重大問題です。 残念ながら、存在は増幅の特性によるDistributed DoS(DDOS)攻撃の良い候補です。 登録、メッセージはそうすることができました。シングル、通知のほとんど果てしないストリームを生成してください、存在データの適当にダイナミックな源を見つけることができる限り。 したがって、目標に対して攻撃を開始する簡単な方法がヘッダーフィールド(通知が送られるところである)を多くのユーザ、およびContactでの購読に送ることであり、場所は目標のアドレスです。 RFC3265は、これらの攻撃[2]を緩和するためにいくつかのメカニズムを提供します。 NOTIFYが承認しなかったか、または欲しくなかったなら、それを生成した購読を取り除きます。 これは誤ったContactアドレスを提供する増幅の特性を根絶します。
Rosenberg Standards Track [Page 22] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[22ページ]RFC3856は存在2004年8月にちびちび飲みます。
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の認証と承認はこれらの攻撃を防ぐことができます。 通常、承認方針は未知のウォッチャーから購読を許さないでしょう。 攻撃がpresentity(よくある例)における、未知のウォッチャーから着手されるなら、攻撃は緩和されます。
9.6. Denial Of Service Attacks Against Servers
9.6. サーバに対するサービス不能攻撃
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自身は、これらの攻撃を緩和するためにRFC3265[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.
サーバは、ダイジェスト認証[1]を使用しながら、4方法の握手でSYN-攻撃スタイル攻撃を防ぐことができます。 サーバにクライアントがいる共有秘密キーがなくても、それは、RFC3261[1]のセクション22.1で説明された「匿名」のユーザメカニズムを使用することで要求のソースIPアドレスについて確かめることができます。 また、SIPは要求をそれに送るのから引き返すようクライアントにサーバを命令させます、503応答コードを使用して。(.4セクション21.5RFC3261[1])。 洪水で抵抗するのにこれを使用できる、登録、要求は分散DoS攻撃の結果、始められました。
10. IANA Considerations
10. IANA問題
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:
この仕様はRFC3265[2]で定義された登録手順に基づいてイベントパッケージを登録します。 ↓これはそのような登録に必要である情報です:
Package Name: presence
名前をパッケージしてください: 存在
Package or Template-Package: This is a package.
パッケージかテンプレートパッケージ: これはパッケージです。
Published Document: RFC 3856
発行されたドキュメント: RFC3856
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡する人: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net 。
Rosenberg Standards Track [Page 23] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[23ページ]RFC3856は存在2004年8月にちびちび飲みます。
11. Contributors
11. 貢献者
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/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: lennox@cs.columbia.edu
メール: lennox@cs.columbia.edu
Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
プラノ、ロバートスパークスdynamicsoft5100テニソンパークウェイSuite1200テキサス 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
プラノ、ディーンウィリスdynamicsoft5100テニソンパークウェイSuite1200テキサス 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/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Rosenberg Standards Track [Page 24] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[24ページ]RFC3856は存在2004年8月にちびちび飲みます。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: bernarda@microsoft.com
メール: bernarda@microsoft.com
David Gurle Reuters Corporation
デヴィッドGurleロイター社
EMail: David.Gurle@reuters.com
メール: David.Gurle@reuters.com
David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134
サンノゼ、デヴィッドオランシスコシステムズ170の西タスマン博士カリフォルニア 95134
EMail: oran@cisco.com
メール: oran@cisco.com
12. Acknowledgements
12. 承認
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.
彼らのこの仕様のコメントとサポートについてリックWorkman、アダム・ローチ、ショーン・オルソン、ビリー・ビッグズ、スチュアート・バークリー、マウリシオArango、リチャード・ショッキー、ヨルゲンBjorkner、ヘンリーSinnreich、ロナルド・エイカーズ、ポールKyzivat、Ya-チンTan、パトリクFaltstrom、アリソン・マンキン、およびHisham Khartabilに感謝申し上げます。
13. Normative References
13. 引用規格
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[3] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Rosenberg Standards Track [Page 25] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[25ページ]RFC3856は存在2004年8月にちびちび飲みます。
[5] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[5] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、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.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[7] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[8] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[8] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のためのウォッチャー情報イベントテンプレートパッケージ」、RFC3857、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.ローゼンバーグ、J.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
14. Informative References
14. 有益な参照
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[10] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[11] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress, May 2004.
[11] ピーターソン、J.、「セッション開始プロトコル(一口)における認証されたアイデンティティ管理のための増進」が進歩、2004年5月に働いています。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[12] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February
2000.
[13] 日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211,
December 2001.
[14] ガットマン、P.、「cmのためのパスワードベースの暗号化」、RFC3211、2001年12月。
15. Author's Address
15. 作者のアドレス
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Lanidex Plazaパーシッパニー、ジョナサンローゼンバーグdynamicsoft600ニュージャージー 07054
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Rosenberg Standards Track [Page 26] RFC 3856 SIP Presence August 2004
ローゼンバーグ標準化過程[26ページ]RFC3856は存在2004年8月にちびちび飲みます。
16. Full Copyright Statement
16. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg Standards Track [Page 27]
ローゼンバーグ標準化過程[27ページ]
一覧
スポンサーリンク
