RFC4662 日本語訳
4662 A Session Initiation Protocol (SIP) Event Notification Extensionfor Resource Lists. A. B. Roach, B. Campbell, J. Rosenberg. August 2006. (Format: TXT=82778 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. B. Roach
Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
コメントを求めるワーキンググループA.B.ローチ要求をネットワークでつないでください: 4662年のB.キャンベルカテゴリ: 標準化過程エスタカードシステムJ.ローゼンバーグシスコシステムズ2006年8月
A Session Initiation Protocol (SIP) Event Notification Extension
for Resource Lists
リソースリストのためのセッション開始プロトコル(一口)イベント通知拡張子
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.
このドキュメントは、リソースの均質のリストに加入するためにSession Initiationプロトコル(SIP)の特定のEvent Notificationメカニズムに拡大を提示します。 個別に登録を各リソースのために送ることの代わりに、リストのリソースのどれかの状態が変化するとき、加入者は、全体のリストに加入して、次に、通知を受け取ることができます。
Roach, et al. Standards Track [Page 1] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[1ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Operation of List Subscriptions .................................5
4.1. Negotiation of Support for Resource Lists ..................6
4.2. Subscription Duration ......................................7
4.3. NOTIFY Bodies ..............................................7
4.4. RLS Processing of SUBSCRIBE Requests .......................7
4.5. RLS Generation of NOTIFY Requests ..........................7
4.6. Subscriber Processing of NOTIFY Requests ...................9
4.7. Handling of Forked Requests ...............................10
4.8. Rate of Notifications .....................................10
5. Using multipart/related to Convey Aggregate State ..............10
5.1. XML Syntax ................................................11
5.2. List Attributes ...........................................13
5.3. Resource Attributes .......................................14
5.4. Name Attributes ...........................................14
5.5. Instance Attributes .......................................14
5.6. Constructing Coherent Resource State ......................16
5.6.1. Processing Full State Notifications ................17
5.6.2. Processing Partial State Notifications .............17
6. Example ........................................................18
7. Security Considerations ........................................31
7.1. Authentication ............................................31
7.1.1. RLS and Subscriber in the Same Domain ..............31
7.1.2. RLS and Subscriber in Different Domains ............32
7.2. Risks of Improper Aggregation .............................33
7.3. Signing and Sealing .......................................33
7.4. Infinite Loops ............................................34
8. IANA Considerations ............................................34
8.1. New SIP Option Tag: eventlist .............................34
8.2. New MIME type for Resource List Meta-Information ..........34
8.3. URN Sub-Namespace .........................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
1. 序論…3 2. 用語…4 3. 操作の概観…4 4. リスト購読の操作…5 4.1. リソースのサポートの交渉は記載します…6 4.2. 購読持続時間…7 4.3. ボディーに通知してください…7 4.4. RLS、処理する、要求を申し込んでください…7 4.5. RLS世代、要求に通知してください…7 4.6. 加入者、処理する、要求に通知してください…9 4.7. 股状の要求の取り扱い…10 4.8. 通知の速度…10 5. 複合/を使用するのはConvey Aggregate州に関係しました…10 5.1. XML構文…11 5.2. 属性を記載してください…13 5.3. リソース属性…14 5.4. 属性を命名してください…14 5.5. 例の属性…14 5.6. 一貫性を持っているリソース状態を構成します…16 5.6.1. いっぱいに処理して、通知を述べてください…17 5.6.2. 部分的な州の通知を処理します…17 6. 例…18 7. セキュリティ問題…31 7.1. 認証…31 7.1.1. 同じドメインのRLSと加入者…31 7.1.2. 異なったドメインのRLSと加入者…32 7.2. 不適当な集合のリスク…33 7.3. 署名捺印します…33 7.4. 無限は輪にされます…34 8. IANA問題…34 8.1. 新しい一口オプションタグ: eventlist…34 8.2. Resource List Meta-情報のための新しいMIMEの種類…34 8.3. つぼのサブ名前空間…35 9. 承認…36 10. 参照…36 10.1. 標準の参照…36 10.2. 有益な参照…37
Roach, et al. Standards Track [Page 2] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[2ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
1. Introduction
1. 序論
The SIP-specific event notification mechanism [2] allows a user (the subscriber) to request to be notified of changes in the state of a particular resource. This is accomplished by the subscriber generating a SUBSCRIBE request for the resource, which is processed by a notifier that represents the resource.
SIP特有のイベント通知メカニズム[2]は特定のリソースの状態の変化について通知されるよう要求する(加入者)をユーザに許容します。 これは登録を発生させるとリソースを表すnotifierによって処理されるリソースのために要求される加入者によって達成されます。
In many cases, a subscriber has a list of resources they are interested in. Without some aggregating mechanism, this will require the subscriber to generate a SUBSCRIBE request for each resource about which they want information. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. Some specific problems are:
多くの場合、加入者には、それらが興味を持っているリソースのリストがあります。 何らかの集合メカニズムがなければ、これは、加入者が登録を発生させるのを必要とするでしょう。彼らが情報が欲しい各リソースのために、要求します。 帯域幅がワイヤレス・ネットワークなどのように制限される環境において、各リソースに加入するのは個別に問題が多いです。 いくつかの特定の問題は以下の通りです。
o Doing so generates substantial message traffic, in the form of the
initial SUBSCRIBE requests for each resource and the refreshes of
each individual subscription.
o そして、そうするのはかなりのメッセージ交通を発生させます、初期の形で登録、各リソースに関する要求、それぞれの個々の購読をリフレッシュします。
o The notifier may insist on low refresh intervals, in order to
avoid a long-lived subscription state. This means that the
subscriber may need to generate SUBSCRIBE refreshes faster than it
would like to or has the capacity to.
o notifierは、長命の購読状態を避けるために間隔をリフレッシュするように安値を主張するかもしれません。 加入者が発生する必要があるかもしれないこの手段、登録、そうしたいより速くリフレッシュするか、または容量を持っています。
o The notifier may generate NOTIFY requests more rapidly than the
subscriber desires, causing NOTIFY traffic at a greater volume
than is desired by the subscriber.
o notifierはNOTIFY要求を加入者願望より急速に発生させるかもしれません、加入者によって望まれているより大きいボリュームでNOTIFYに交通を引き起こして。
To solve these problems, this specification defines an extension to RFC 3265 [2] that allows for requesting and conveying notifications for lists of resources. A resource list is identified by a URI, and it represents a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information. In many cases, the URI used to identify the resource list will be a SIP URI [1]; however, the use of other schemes (such as pres: [10]) is also foreseen.
これらの問題を解決するために、この仕様はリソースに関する通知繰返し要素の並びを要求して、伝えると考慮するRFC3265[2]と拡大を定義します。 リソースリストはURIによって特定されます、そして、それはゼロのリストか、より多くのURIを表します。 それぞれのこれらのURIは加入者が情報を受け取りたがっている個々のリソースのための識別子です。 多くの場合、リソースリストを特定するのに使用されるURIはSIP URIにな[1]るでしょう。 しかしながら、他の使用は計画されます。(また、: [10])をpresするとき、そのようなものは見通されます。
The notifier for the list is called a "resource list server", or RLS. In order to determine the state of the entire list, the RLS will act as if it has generated a subscription to each resource in the list.
リストのためのnotifierは「リソースリストサーバ」、またはRLSと呼ばれます。 全体のリストの状態を決定するために、まるでリストの各リソースの購読を発生させたかのようにRLSは行動するでしょう。
The resource list is not restricted to be inside the domain of the subscriber. Similarly, the resources in the list are not constrained to be in the domain of the resource list server.
リソースリストは、加入者のドメインの中にあるように制限されません。 同様に、リストのリソースがリソースリストサーバのドメインにあるのが抑制されません。
Roach, et al. Standards Track [Page 3] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[3ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
The following terms are used throughout the remainder of this document.
次の用語はこのドキュメントの残り中で使用されます。
Back-End Subscription: Any subscription (SIP or otherwise) that an
RLS creates to learn of the state of a resource. An RLS will
create back-end subscriptions to learn of the state of a resource
about which the RLS is not an authority. For back-end
subscriptions, RLSes act as a subscriber.
バックエンド購読: RLSがリソースの状態を知るために作成するどんな購読(SIPの、または、そうでない)。 RLSは、RLSが権威でないリソースの状態を知るためにバックエンド購読を作成するでしょう。 バックエンド購読のために、RLSesは加入者として機能します。
List Subscription: A subscription to a resource list. In list
subscriptions, RLSes act as the notifier.
購読を記載してください: リソースリストの購読。 リスト購読では、RLSesはnotifierとして機能します。
Resource: A resource is any logical entity that has a state or
states that can be subscribed to. Resources are identified by
URIs.
リソース: リソースは加入できる州か州を持っているあらゆる論理的な実体です。 リソースはURIによって特定されます。
Resource List: A list of zero or more resources that can have their
individual states subscribed to with a single subscription.
リソースリスト: ただ一つの購読でそれらの個々の州に加入できるゼロのリストか、より多くのリソース。
RLMI: Resource List Meta-Information. RLMI is a document that
describes the state of the virtual subscriptions associated with a
list subscription.
RLMI: リソースリストメタ情報。 RLMIはリスト購読に関連している仮想の購読の状態について説明するドキュメントです。
RLS: Resource List Server. RLSes accept subscriptions to resource
lists and send notifications to update subscribers of the state of
the resources in a resource list.
RLS: リソースList Server. RLSesは、リソースリストの購読を受け入れて、リソースリストのリソースの状態の加入者をアップデートするために通告を送っています。
Virtual Subscription: A Virtual Subscription is a logical construct
within an RLS that represents subscriptions to the resources in a
resource list. For each list subscription it services, an RLS
creates at least one virtual subscription for every resource in
the resource list being subscribed to. In some cases, such as
when the RLS is not the authority for the state of the resource,
this virtual subscription will be associated with a back-end
subscription. In other cases, such as when the RLS is the
authority for the state of the resource, the virtual subscription
will not have a corresponding back-end subscription.
仮想の購読: Virtual Subscriptionはリソースリストのリソースの購読を表すRLSの中の論理的な構造物です。 それが修理するそれぞれのリスト購読のために、RLSは加入されるリソースリストの各リソースあたり少なくとも1つの仮想の購読を作成します。 RLSがリソースの状態への権威でない時などのいくつかの場合では、この仮想の購読はバックエンド購読に関連するでしょう。 RLSがリソースの状態への権威である時などの他の場合では、仮想の購読は対応するバックエンド購読を持たないでしょう。
3. Overview of Operation
3. 操作の概観
This section provides an overview of the typical mode of operation of this extension. It is not normative.
このセクションはこの拡大の典型的な運転モードの概観を提供します。 それは規範的ではありません。
Roach, et al. Standards Track [Page 4] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[4ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
When users wish to subscribe to the resource of a list of resources, they can use the mechanisms described in this specification. The first step is the creation of a resource list. This resource list is represented by a SIP URI. The list contains a set of URIs, each of which represents a resource for which the subscriber wants to receive information. The resource list can exist in any domain. The list could be manipulated through a web page, through a voice response system, or through some other protocol. The specific means by which the list is created and maintained is outside the scope of this specification.
ユーザがリソースのリストに関するリソースに加入したがっているとき、それらはこの仕様で説明されたメカニズムを使用できます。 第一歩はリソースリストの創造です。 このリソースリストはSIP URIによって表されます。 リストは1セットのURIを含んでいます。それはそれぞれ、加入者が情報を受け取りたがっているリソースを表します。 リソースリストはどんなドメインにも存在できます。 ウェブページを通して、または、音声応答システムを通して、または、ある他のプロトコルを通してリストを操ることができました。 この仕様の範囲の外にリストが作成されて、維持される特定の手段があります。
To learn the resource state of the set of elements on the list, the user sends a single SUBSCRIBE request targeted to the URI of the list. This will be routed to an RLS for that URI. The RLS acts as a notifier, authenticates the subscriber, and accepts the subscription.
リストの要素のセットのリソース状態を学ぶために、ユーザがシングルを送る、登録、リストのURIに狙う要求。 これはそのURIのためにRLSに発送されるでしょう。 RLSはnotifierとして機能して、加入者を認証して、購読を認めます。
The RLS may have direct information about some or all of the resources specified by the list. If it does not, it could subscribe to any non-local resources specified by the list resource.
RLSはリストでリソースのいくつかかすべてのダイレクト情報を指定させるかもしれません。 そうしないなら、それはリストリソースによって指定されたどんな非ローカル資源にも加入するかもしれません。
Note that subscriptions to non-local resources may or may not be SIP subscriptions; any mechanism for determining such information may be employed. This document uses the term "back-end subscription" to refer to such a subscription, regardless of whether SIP is used to establish and service it.
非ローカル資源の購読がSIP購読であるかもしれないことに注意してください。 そのような情報を決定するためのどんなメカニズムも使われるかもしれません。 このドキュメントはそのような購読について言及するのに「バックエンド購読」という用語を使用します、SIPがそれを設立して、調整するのに使用されるかどうかにかかわらず。
As the state of resources in the list change, the RLS generates notifications to the list subscribers. The RLS can, at its discretion, buffer notifications of resource changes and send the resource information to the subscriber in batches, rather than individually. This allows the RLS to provide rate limiting for the subscriber.
リスト変化におけるリソースの状態として、RLSはリスト加入者に通知を発生させます。 RLSが自己判断でリソース変化の通知をバッファリングして、バッチでリソース情報を加入者にむしろ送ることができる、個別に。 これで、RLSは加入者のためのレート制限を提供できます。
The list notifications contain a body of type multipart/related. The root section of the multipart/related content is an XML document that provides meta-information about each resource present in the list. The remaining sections contain the actual state information for each resource.
リスト通知は複合である、または関連していた状態でタイプのボディーを含んでいます。 複合の、または、関連する内容の根の部はリストの現在のそれぞれのリソースのメタ情報を提供するXMLドキュメントです。 残っているセクションは各リソースのための実際の州の情報を含みます。
4. Operation of List Subscriptions
4. リスト購読の操作
The event list extension acts, in many ways, like an event template package. In particular, any single list subscription must be homogeneous with respect to the underlying event package. In other words, a single list subscription can apply only one event package to all the resources in the resource list.
イベントリスト拡張子は様々な意味でイベントテンプレートパッケージのように行動します。 どんなただ一つのリスト購読も基本的なイベントパッケージに関して特に、均質でなければなりません。 言い換えれば、ただ一つのリスト購読はリソースリストのすべてのリソースへの1個のイベントパッケージしか適用できません。
Roach, et al. Standards Track [Page 5] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[5ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Note that it is perfectly valid for an RLS to allow multiple subscriptions to the same list to use differing event packages.
RLSが同じリストの複数の購読に異なったイベントパッケージを使用させるのが、完全に有効であることに注意してください。
The key difference between a list subscription and templates in general is that support for list subscriptions indicates support for arbitrary nesting of list subscriptions. In other words, elements within the list may be atomic elements, or they may be lists themselves.
リスト購読と一般に、テンプレートの主要な違いはサポート繰返し要素の並び購読がリスト購読の任意の巣篭もりのサポートを示すということです。 言い換えれば、リストの中の要素は原子であるかもしれませんかそれらがリスト自体であるかもしれません。
The consequence of this is that subscription to a URI that represents a list actually results in several virtual subscriptions to a tree of resources. The leaf nodes of this tree are virtual subscriptions of the event type given in the "Event" header field; all other nodes in the tree are list subscriptions that are serviced as described in this section and its subsections.
この結果はリストを表すURIの購読が実際にリソースの木のいくつかの仮想の購読をもたらすということです。 この木の葉の節は「出来事」ヘッダーフィールドで与えられているイベントタイプの仮想の購読です。 木の他のすべてのノードが、このセクションで説明されるように修理されるリスト購読とその小区分です。
Keep in mind that these virtual subscriptions are not literal SIP subscriptions (although they may result in SIP subscriptions, depending on the RLS implementation).
これらの仮想の購読が文字通りのSIP購読でないことを覚えておいてください(SIP購読をもたらして、RLS実現によるかもしれませんが)。
4.1. Negotiation of Support for Resource Lists
4.1. リソースリストのサポートの交渉
This specification uses the SIP option tag mechanism for negotiating support for the extension defined herein. Refer to RFC 3261 [1] for the normative description of processing of the "Supported" and "Require" header fields and the 421 (Extension Required) response code.
この仕様は、ここに定義された拡大のサポートを交渉するのにSIPオプションタグメカニズムを使用します。 「支持」の処理の標準の記述、「必要」ヘッダーフィールド、および421(拡大Required)応答コードのためのRFC3261[1]を参照してください。
A non-normative description of the implications of the use of
option tags follows.
Any client that supports the event list extension will include an
option tag of "eventlist" in a "Supported" header field of every
SUBSCRIBE message for a subscription for which it is willing to
process a list. If the subscription is made to a URI that
represents a list, the RLS will include "eventlist" in a "Require"
header field of the response to the SUBSCRIBE, and in all NOTIFY
messages within that subscription.
オプションタグの使用の含意の非標準の記述は続きます。 イベントリスト拡張子をサポートするどんなクライアントもaの"eventlist"のオプションタグがヘッダーフィールドを「支持した」インクルードを望んでいる、あらゆる、登録、それがリストを処理しても構わないと思っている購読へのメッセージ。 購読をリストを表すURIにするなら、RLSがaの"eventlist"が応答のヘッダーフィールドを「必要である」インクルードを望んでいる、登録、全部で、NOTIFYはその購読の中で通信します。
Use of "Require: eventlist" in NOTIFY messages is applied by the
notifier to satisfy the RFC 3261 requirement that a UAC MUST
insert a Require header field into a request if the UAC wishes to
insist that a UAS understand an extension in order to process the
request. Because the NOTIFY would not be usable without applying
the eventlist option, the notifier is obligated to include it.
「以下を必要としてください」の使用 NOTIFYメッセージの"eventlist"は、UACが、UASが要求を処理するために拡大を理解していると主張したいならUAC MUSTがRequireヘッダーフィールドを要求に挿入するというRFC3261要件を満たすためにnotifierによって適用されます。 eventlistオプションを適用しないで、NOTIFYは使用可能でないでしょう、したがって、notifierがそれを含んでいるのが義務付けられます。
Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except to break interoperability in certain cases, and is consequently NOT RECOMMENDED.
登録の「必要」ヘッダーフィールドにおける含んでいる"eventlist"要求は、ある場合には、相互運用性を壊す以外に、目的に全く役立たないで、その結果、NOT RECOMMENDEDです。
Roach, et al. Standards Track [Page 6] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[6ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Sending of "Supported: eventlist" in a NOTIFY message is meaningless and silly. Implementations SHOULD NOT include "Supported: eventlist" in any requests except for SUBSCRIBE.
「支持された」発信 NOTIFYメッセージの"eventlist"は、無意味であって、愚かです。 実現SHOULD NOTは「支持されたこと」を含んでいます。 どんな要求でも"eventlist"、登録。
There is nothing in a SIP URI that indicates whether it represents a list of resources or a single resource. Therefore, if a subscriber sends a request to a URI that represents a list resource but does not include a Supported header field listing the "eventlist" token, the notifier will typically return a 421 (Extension Required) response code. RFC 3261 [1] advises that servers avoid returning a 421 and instead attempt to process the request without the extension. However, in this case, the URI fundamentally represents a list resource, and therefore the subscription cannot proceed without this extension.
何もそれがリソースのリストかただ一つのリソースを表すかどうかを示すSIP URIにありません。 したがって、加入者が"eventlist"象徴を記載するリストリソースを表しますが、Supportedヘッダーフィールドを含んでいないURIに要求を送ると、notifierは421(拡大Required)応答コードを通常返すでしょう。 RFC3261[1]は、サーバが、421を返すのを避けて、代わりに拡大なしで要求を処理するのを試みると忠告します。 しかしながら、この場合、URIは基本的にリストリソースを表します、そして、したがって、購読はこの拡大なしで続くことができません。
4.2. Subscription Duration
4.2. 購読持続時間
Since the primary benefit of the resource list server is to reduce the overall messaging volume to a subscriber, it is RECOMMENDED that the subscription duration to a list be reasonably long. The default, when no duration is specified, is taken from the underlying event package. Of course, the standard techniques [2] can be used to increase or reduce this amount.
リソースリストサーバの主要便益が総合的なメッセージングボリュームを加入者に減少させることであるので、リストへの購読持続時間が適度に長いのは、RECOMMENDEDです。 持続時間を全く指定しないとき、基本的なイベントパッケージからデフォルトを取ります。 もちろん、この量を増加するか、または減少させるのに標準のテクニック[2]を使用できます。
4.3. NOTIFY Bodies
4.3. ボディーに通知してください。
An implementation compliant to this specification MUST support the multipart/related and application/rlmi+xml MIME types. These types MUST be included in an Accept header sent in a SUBSCRIBE message, in addition to any other types supported by the client (including any types required by the event package being used).
この仕様への対応することの実現は複合/が関係づけたサポートとアプリケーション/rlmi+xml MIMEの種類がそうしなければなりません。 これらのタイプは含まれていて、メッセージが登録でAcceptヘッダーでは、発信していました、クライアントによって支持されたいかなる他のタイプに加えて(どんなタイプも含むのが使用されるイベントパッケージが必要です)ことであるに違いありません。
4.4. RLS Processing of SUBSCRIBE Requests
4.4. RLS、処理する、要求を申し込んでください。
Once the subscriber is authenticated, the RLS performs authorization per its local policy. In many cases, each resource list is associated with a particular user (the one who created it and manages the set of elements in it), and only that user will be allowed to subscribe. Of course, this mode of operation is not inherent in the use of resource lists, and an RLS can use any authorization policy it chooses.
加入者がいったん認証されると、RLSはローカルの方針あたりの認可を実行します。 多くの場合、それぞれのリソースリストは特定のユーザ(それを作成して、それの要素のセットを経営する人)に関連しています、そして、そのユーザだけが申し込むことができるでしょう。 もちろん、この運転モードはリソースリストの使用が固有ではありません、そして、RLSはそれが選ぶどんな認可方針も使用できます。
4.5. RLS Generation of NOTIFY Requests
4.5. RLS世代、要求に通知してください。
This specification leaves the choice about how and when to generate NOTIFY requests at the discretion of the implementor. One of the differentiators between various RLS implementations is the means by which they aggregate, rate-limit, or optimize the way in which
この仕様は作成者の裁量でNOTIFY要求をどのように、いつ発生させるかに関する選択を残します。 様々なRLS実現の間の識別因子の1つがそれらが入口を集めるか、レートで制限するか、または最適化する手段である、どれ
Roach, et al. Standards Track [Page 7] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[7ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
notifications are generated. As a baseline behavior, the RLS MAY generate a NOTIFY to the RLS subscriber whenever the state of any resource on the list changes.
通知は発生します。 基線の振舞いとして、リストの上のどんなリソースの状態も変化するときはいつも、RLS MAYはRLS加入者にNOTIFYを発生させます。
It is important to understand that any given subscription is a subscription either to a single resource or to a list of resources. This nature (single resource versus list of resources) cannot change during the duration of a single subscription. In particular, this means that RLSes MUST NOT send NOTIFY messages that do not contain RLMI for a subscription if they have previously sent NOTIFY messages in that subscription containing RLMI. Similarly, RLSes MUST NOT send NOTIFY messages that do contain RLMI for a subscription if they have previously sent NOTIFY messages in that subscription which do not.
どんな与えられた購読もただ一つのリソースかリソースのリストの購読であることを理解しているのは重要です。 この種(ただ一つのリソース対リソースのリスト)はただ一つの購読の持続時間の間、変化できません。 特に、これは、それらが以前にRLMIを含むその購読におけるメッセージをNOTIFYに送ったならRLSesが購読のためにRLMIを含まないメッセージをNOTIFYに送ってはいけないことを意味します。 同様に、それらが以前にその購読におけるそうしないメッセージをNOTIFYに送ったなら、RLSesは購読のためにRLMIを含むメッセージをNOTIFYに送ってはいけません。
List representations necessarily contain RLMI documents for two
reasons. Importantly, they identify the resource to which the
event state corresponds. Many state syntaxes do not fully
identify the resource to which the state applies, or they may
identify the resource in a different way than it is represented in
the list; for example, PIDF documents may contain resource URIs
that are not identical to the URI used to retrieve them. Further,
RLMI documents serve to disambiguate multiple instances of a
single resource.
リスト表現は2つの理由で必ずRLMIドキュメントを含んでいます。 重要に、彼らはイベント状態が相当するリソースを特定します。 多くの州の構文が完全に、状態が適用されるリソースを特定するというわけではありませんか、またはそれがリストに表されるのと異なった方法でリソースを特定するかもしれません。 例えば、PIDFドキュメントはそれらを検索するのに使用されるURIと同じでないリソースURIを含むかもしれません。 さらに、RLMIドキュメントは、ただ一つのリソースの複数の例のあいまいさを除くのに役立ちます。
See Section 5 for a detailed definition of the syntax used to convey the state of resource lists. For the purposes of the following discussion, it is important to know that the overall list contains zero or more resources, and that the resources contain zero or more instances. Each instance has a state associated with it (pending, active, or terminating) representing the state of the virtual subscription.
構文の詳細な定義のためのセクション5が以前はよくリソースリストの状態を運んでいたのを確実にしてください。 以下の議論の目的のために、総合的なリストがゼロか、より多くのリソースを含んでいて、リソースがゼロか、より多くの例を含むのを知るのは重要です。 各例には、仮想の購読の状態を表すそれ(未定の、または、アクティブであるか、終わっている)に関連している状態があります。
Notifications contain a multipart document, the first part of which always contains meta-information about the list (e.g., membership, state of the virtual subscription to the resource). Remaining parts are used to convey the actual state of the resources listed in the meta-information.
通知は複合ドキュメント(それの一部がいつもリスト(例えば、会員資格、リソースの仮想の購読の状態)のメタ情報を含む1番目)を含んでいます。 残存部分は、メタ情報にリストアップされたリソースの実際の状態を運ぶのに使用されます。
The "state" attribute of each instance of a resource in the meta-information is set according to the state of the virtual subscription. The meanings of the "state" attribute are described in RFC 3265 [2].
仮想の購読の状態に従って、メタ情報のリソースのそれぞれの例の「状態」属性は設定されます。 「状態」属性の意味はRFC3265[2]で説明されます。
If an instance of a resource was previously reported to the subscriber but is no longer available (i.e., the virtual subscription to that instance has been terminated), the resource list server SHOULD include that resource instance in the meta-information in the first NOTIFY message sent to the subscriber following the instance's
リソースの例が以前に、加入者に報告されましたが、もう利用可能でないなら(すなわち、その例の仮想の購読は終えられました)、リソースリストサーバSHOULDは例のものに従って、加入者に送られた最初のNOTIFYメッセージのメタ情報にそのリソース例を含んでいます。
Roach, et al. Standards Track [Page 8] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[8ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
unavailability. The RLS MAY continue to do so for future notifications.
使用不能。 RLS MAYは、今後の通知のためにそうし続けています。
When sending information for a terminated resource instance, the RLS indicates a state of "terminated" and an appropriate reason value. Valid reason values and their meanings are described in RFC 3265 [2]. If the RLS will attempt to recover the resource state again at some point in the future (e.g., when the reason in the meta-information is "probation"), then the instance of the resource SHOULD remain in the meta-information until the instance state is available, or until the RLS gives up on making such state available.
終えられたリソース例のための情報を送るとき、RLSは「終えられること」の状態と適切な理由値を示します。 正当な理由値とそれらの意味はRFC3265[2]で説明されます。 RLSが、将来(例えば、いつメタ情報の理由は「執行猶予」である)再び何らかのポイントでリソース状態を回復するのを試みるなら、SHOULDがメタ情報に例の状態が利用可能であるか、またはRLSまで残っているリソースの例は、そのような状態を利用可能にするのに見切りをつけます。
When the first SUBSCRIBE message for a particular subscription is received by an RLS, the RLS will often not know state information for all the resources specified by the resource list. For any resource for which state information is not known, the corresponding "uri" attribute will be set appropriately, and no <instance> elements will be present for the resource.
登録、1日であるとき、特定の購読へのメッセージはそうです。RLSによって受け取られて、RLSはしばしばリソースリストによって指定されたすべてのリソースのための州の情報を知るというわけではないでしょう。 州の情報が知られていないどんなリソースにおいても、対応する"uri"属性は適切に設定されるでしょう、そして、どんな<例の>要素もリソースのために存在しないでしょう。
For an initial notification, sections corresponding to resources for which the RLS does have state will be populated with appropriate data (subject, of course, to local policy decisions). This will often occur if the resource list server is co-located with the server for one or more of the resources specified on the list.
初期の通知において、RLSには状態があるリソースに対応するセクションは適切なデータ(もちろん、ローカルの政策決定にかける)で居住されるでしょう。 リソースリストサーバがリストで指定されたリソースの1つ以上のサーバで共同見つけられていると、これはしばしば起こるでしょう。
Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document in which the full state is indicated. The RLS SHOULD also include state information for all resources in the list for which the RLS has state, subject to policy restrictions. This allows the subscriber to refresh their state, and to recover from lost notifications.
登録、メッセージSHOULDがRLMIドキュメントを含む完全が示されると述べるその後の結果として引き起こされた即座の通知。 また、RLS SHOULDはRLSが方針制限を条件として状態を持っているリストのすべてのリソースのための州の情報を含んでいます。 これで、加入者は、それらの状態をリフレッシュして、無くなっている通知から回復します。
4.6. Subscriber Processing of NOTIFY Requests
4.6. 加入者、処理する、要求に通知してください。
Notifications for a resource list can convey information about a subset of the list elements. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state.
リソースリストのための通知はリスト要素の部分集合に関して情報を伝達できます。 これは、明白なアルゴリズムが、一貫性を持っていて一貫した状態を構成するために定義される必要を意味します。
The XML document present in the root of the multipart/related document contains a <resource> element for some or all of the resources in the list. Each <resource> element contains a URI that uniquely identifies the resource to which that section corresponds. When a NOTIFY arrives, it can contain full or partial state (as indicated by the "fullState" attribute of the top-level <list> element). If full state is indicated, then the recipient replaces all state associated with the list with the entities in the NOTIFY body. If full state is not indicated, the recipient of the NOTIFY
複合の、または、関連するドキュメントの根における現在のXMLドキュメントはリストのリソースのいくつかかすべてのための<リソース>要素を含んでいます。 それぞれの<リソース>要素は唯一、そのセクションが相当するリソースを特定するURIを含んでいます。 NOTIFYが到着するとき、それは完全であるか部分的な状態を含むことができます(トップレベル<リスト>要素の"fullState"属性によって示されるように)。 完全な状態が示されるなら、受取人はNOTIFYボディーでリストに関連しているすべての状態を実体に取り替えます。 完全な状態が示されないならNOTIFYの受取人
Roach, et al. Standards Track [Page 9] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[9ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
updates information for each identified resource. Information for any resources that are not identified in the NOTIFY is not changed, even if they were indicated in previous NOTIFY messages. See Section 5.6 for more information.
それぞれの特定されたリソースのための情報をアップデートします。 NOTIFYで特定されないどんなリソースのための情報も変えられません、それらが前のNOTIFYメッセージで示されたとしても。 詳しい情報に関してセクション5.6を見てください。
When full state is indicated, note that it applies only to the
RLMI document in which it occurs. In particular, one of the
<resource> elements in the document may in turn refer to another
list of resources. Any such sub-lists will be detailed in their
own RLMI documents, which may or may not have full state
indicated.
完全な状態が示されたら、それが起こるRLMIドキュメントだけに適用されることに注意してください。 特に、ドキュメントの<リソース>要素のひとりは順番にリソースの別のリストを示すかもしれません。 どんなそのようなサブリストもそれら自身のRLMIドキュメントでなるでしょう。(詳細であり、ドキュメントは示された完全な状態を持っているかもしれません)。
Further note that the underlying event package may have its own
rules for compositing partial state notification. When processing
data related to those packages, their rules apply (i.e., the fact
that they were reported as part of a list does not change their
partial notification semantics).
基本的なイベントパッケージには合成部分的な州の通知のためのそれ自身の規則があるかもしれないことにさらに注意してください。 処理データがそれらのパッケージに関連したとき、それらの規則は(すなわち、リストの一部がそれらの部分的な通知意味論を変えないときそれらが報告されたという事実)を当てはまります。
Finally, note that as a consequence of the way in which resource
list subscriptions work, polling of resource state may not be
particularly useful. While such polls will retrieve the resource
list, they will not necessarily contain state for some or all of
the resources on the list.
最終的に、リソースリスト購読が働いている方法の結果として、リソース状態の世論調査が特に役に立たないかもしれないことに注意してください。 そのような投票がリソースリストを検索している間、それらは必ずリストにリソースのいくつかかすべてのための状態を含むというわけではないでしょう。
4.7. Handling of Forked Requests
4.7. 股状の要求の取り扱い
Forking makes little sense with subscriptions to event lists, since the whole idea is a centralization of the source of notifications. Therefore, a subscriber to a list MUST NOT install multiple subscriptions when the initial request is forked. If multiple responses are received, they are handled using the techniques described in Section 4.4.9 of RFC 3265 [2].
分岐はイベントリストの購読で少ししか理解できません、全体構想が通知の源の中央集権化であるので。 したがって、初期の要求が股状であるときに、リストへの加入者は複数の購読をインストールしてはいけません。 複数の応答が受け取られているなら、それらは、.9セクション4.4RFC3265[2]で説明されたテクニックを使用することで扱われます。
4.8. Rate of Notifications
4.8. 通知の速度
One potential role of the RLS is to perform rate limitations on behalf of the subscriber. As such, this specification does not mandate any particular rate limitation, and rather leaves that to the discretion of the implementation.
One potential role of the RLS is to perform rate limitations on behalf of the subscriber. As such, this specification does not mandate any particular rate limitation, and rather leaves that to the discretion of the implementation.
5. Using multipart/related to Convey Aggregate State
5. Using multipart/related to Convey Aggregate State
In order to convey the state of multiple resources, the list extension uses the "multipart/related" mime type. The syntax for multipart/related is defined in "The MIME Multipart/Related Content- type" [4].
In order to convey the state of multiple resources, the list extension uses the "multipart/related" mime type. The syntax for multipart/related is defined in "The MIME Multipart/Related Content- type" [4].
Roach, et al. Standards Track [Page 10] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 10] RFC 4662 SIP Event Lists August 2006
5.1. XML Syntax
5.1. XML Syntax
The root document of the multipart/related body MUST be a Resource List Meta-Information (RLMI) document. It is of the type "application/rlmi+xml". This document contains the meta-information for the resources contained in the notification. The schema for this XML document is given below.
The root document of the multipart/related body MUST be a Resource List Meta-Information (RLMI) document. It is of the type "application/rlmi+xml". This document contains the meta-information for the resources contained in the notification. The schema for this XML document is given below.
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi"
elementFormDefault="qualified"
xmlns="urn:ietf:params:xml:ns:rlmi"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="resource" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:attribute name="version" type="xs:unsignedInt"
use="required" />
<xs:attribute name="fullState" type="xs:boolean"
use="required" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="resource">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="instance" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="instance">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
<?xml version="1.0" encoding="UTF-8" ?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi" elementFormDefault="qualified" xmlns="urn:ietf:params:xml:ns:rlmi" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:element name="list"> <xs:complexType> <xs:sequence> <xs:element ref="name" minOccurs="0" maxOccurs="unbounded" /> <xs:element ref="resource" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="uri" type="xs:anyURI" use="required" /> <xs:attribute name="version" type="xs:unsignedInt" use="required" /> <xs:attribute name="fullState" type="xs:boolean" use="required" /> <xs:attribute name="cid" type="xs:string" use="optional" /> <xs:anyAttribute processContents="lax" /> </xs:complexType> </xs:element> <xs:element name="resource"> <xs:complexType> <xs:sequence> <xs:element ref="name" minOccurs="0" maxOccurs="unbounded" /> <xs:element ref="instance" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="uri" type="xs:anyURI" use="required" /> <xs:anyAttribute processContents="lax" /> </xs:complexType> </xs:element> <xs:element name="instance"> <xs:complexType> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded"
Roach, et al. Standards Track [Page 11] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 11] RFC 4662 SIP Event Lists August 2006
processContents="lax" />
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active" />
<xs:enumeration value="pending" />
<xs:enumeration value="terminated" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="reason" type="xs:string"
use="optional" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
processContents="lax" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="active" /> <xs:enumeration value="pending" /> <xs:enumeration value="terminated" /> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="reason" type="xs:string" use="optional" /> <xs:attribute name="cid" type="xs:string" use="optional" /> <xs:anyAttribute processContents="lax" /> </xs:complexType> </xs:element> <xs:element name="name"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema>
An example of a document formatted using this schema follows.
An example of a document formatted using this schema follows.
<?xml version="1.0"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@lists.vancouver.example.com"
version="7" fullState="true">
<name xml:lang="en">Buddy List</name>
<name xml:lang="fr">Liste d'amis</name>
<resource uri="sip:bob@vancouver.example.com">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="12345.aaa@vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="12345.aab@vancouver.example.com"/>
</resource>
<resource uri="sip:jim@vancouver.example.com">
<?xml version="1.0"?> <list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:adam-friends@lists.vancouver.example.com" version="7" fullState="true"> <name xml:lang="en">Buddy List</name> <name xml:lang="fr">Liste d'amis</name> <resource uri="sip:bob@vancouver.example.com"> <name>Bob Smith</name> <instance id="juwigmtboe" state="active" cid="12345.aaa@vancouver.example.com"/> </resource> <resource uri="sip:dave@vancouver.example.com"> <name>Dave Jones</name> <instance id="hqzsuxtfyq" state="active" cid="12345.aab@vancouver.example.com"/> </resource> <resource uri="sip:jim@vancouver.example.com">
Roach, et al. Standards Track [Page 12] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 12] RFC 4662 SIP Event Lists August 2006
<name>Jim</name>
<instance id="oflzxqzuvg" state="terminated"
reason="rejected" />
</resource>
<resource uri="sip:ed@vancouver.example.com">
<name>Ed</name>
<instance id="grqhzsppxb" state="pending"/>
</resource>
</list>
<name>Jim</name> <instance id="oflzxqzuvg" state="terminated" reason="rejected" /> </resource> <resource uri="sip:ed@vancouver.example.com"> <name>Ed</name> <instance id="grqhzsppxb" state="pending"/> </resource> </list>
5.2. List Attributes
5.2. List Attributes
The <list> element present in a list notification MUST contain three attributes.
The <list> element present in a list notification MUST contain three attributes.
The first mandatory <list> attribute is "uri", which contains the uri that corresponds to the list. Typically, this is the URI to which the SUBSCRIBE request was sent.
The first mandatory <list> attribute is "uri", which contains the uri that corresponds to the list. Typically, this is the URI to which the SUBSCRIBE request was sent.
The second mandatory <list> attribute is "version", which contains a number from 0 to 2^32-1. This version number MUST be 0 for the first NOTIFY message sent within a subscription, and MUST increase by exactly one for each subsequent NOTIFY sent within a subscription.
The second mandatory <list> attribute is "version", which contains a number from 0 to 2^32-1. This version number MUST be 0 for the first NOTIFY message sent within a subscription, and MUST increase by exactly one for each subsequent NOTIFY sent within a subscription.
The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription.
The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription.
Finally, <list> elements MAY contain a "cid" attribute. If present, the "cid" attribute identifies a section within the multipart/related body that contains aggregate state information for the resources contained in the list. The definition of such aggregate information is outside the scope of this document and will be defined on a per- package basis, as needed. The cid attribute is the Content-ID for the corresponding section in the multipart body.
Finally, <list> elements MAY contain a "cid" attribute. If present, the "cid" attribute identifies a section within the multipart/related body that contains aggregate state information for the resources contained in the list. The definition of such aggregate information is outside the scope of this document and will be defined on a per- package basis, as needed. The cid attribute is the Content-ID for the corresponding section in the multipart body.
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root. See Section 5.5 for an example.
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root. See Section 5.5 for an example.
Roach, et al. Standards Track [Page 13] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 13] RFC 4662 SIP Event Lists August 2006
5.3. Resource Attributes
5.3. Resource Attributes
The resource list contains one <resource> element for each resource being reported in the notification. These resource elements contain attributes that identify meta-data associated with each resource.
The resource list contains one <resource> element for each resource being reported in the notification. These resource elements contain attributes that identify meta-data associated with each resource.
The "uri" attribute identifies the resource to which the <resource> element corresponds. Typically, this will be a SIP URI that, if subscribed to, would return the state of the resource. This attribute MUST be present.
The "uri" attribute identifies the resource to which the <resource> element corresponds. Typically, this will be a SIP URI that, if subscribed to, would return the state of the resource. This attribute MUST be present.
5.4. Name Attributes
5.4. Name Attributes
Each list and resource element contains zero or more name elements. These name elements contain human-readable descriptions or names for the resource list or resource. The contents of these elements are somewhat analogous to the "Display Name" present in the SIP name-addr element.
Each list and resource element contains zero or more name elements. These name elements contain human-readable descriptions or names for the resource list or resource. The contents of these elements are somewhat analogous to the "Display Name" present in the SIP name-addr element.
Name elements optionally contain the standard XML "xml:lang" attribute. The "xml:lang" attribute, if present, specifies the language of the human-readable name. If this attribute is present, it MUST contain a valid language tag. Language tags are defined in RFC 3066 [6]. The language tag assists applications in determining which of potentially several name elements should be rendered to the user.
Name elements optionally contain the standard XML "xml:lang" attribute. The "xml:lang" attribute, if present, specifies the language of the human-readable name. If this attribute is present, it MUST contain a valid language tag. Language tags are defined in RFC 3066 [6]. The language tag assists applications in determining which of potentially several name elements should be rendered to the user.
5.5. Instance Attributes
5.5. Instance Attributes
Each resource element contains zero or more instance elements. These instance elements are used to represent a single notifier for the resource. For event packages that allow forking, multiple virtual subscriptions may exist for a given resource. Multiple virtual subscriptions are represented as multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, at most one instance will be present for a given resource.
Each resource element contains zero or more instance elements. These instance elements are used to represent a single notifier for the resource. For event packages that allow forking, multiple virtual subscriptions may exist for a given resource. Multiple virtual subscriptions are represented as multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, at most one instance will be present for a given resource.
The "id" attribute contains an opaque string used to uniquely identify the instance of the resource. The "id" attribute is unique only within the context of a resource. Construction of this string is an implementation decision. Any mechanism for generating this string is valid, as long as uniqueness within the resource is assured.
The "id" attribute contains an opaque string used to uniquely identify the instance of the resource. The "id" attribute is unique only within the context of a resource. Construction of this string is an implementation decision. Any mechanism for generating this string is valid, as long as uniqueness within the resource is assured.
The "state" attribute contains the subscription state for the identified instance of the resource. This attribute contains one of the values "active", "pending", or "terminated". The meanings for
The "state" attribute contains the subscription state for the identified instance of the resource. This attribute contains one of the values "active", "pending", or "terminated". The meanings for
Roach, et al. Standards Track [Page 14] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 14] RFC 4662 SIP Event Lists August 2006
these values are as defined for the "Subscription-State" header field in RFC 3265 [2].
these values are as defined for the "Subscription-State" header field in RFC 3265 [2].
If the "state" attribute indicates "terminated", then a "reason" attribute MUST also be present. This "reason" attribute has the same values and meanings as those given for the "reason" parameter on the "Subscription-State" header field in RFC 3265 [2]. Note that the "reason" attribute is included for informational purposes; the list subscriber is not expected to take any automated actions based on the reason value.
If the "state" attribute indicates "terminated", then a "reason" attribute MUST also be present. This "reason" attribute has the same values and meanings as those given for the "reason" parameter on the "Subscription-State" header field in RFC 3265 [2]. Note that the "reason" attribute is included for informational purposes; the list subscriber is not expected to take any automated actions based on the reason value.
Finally, the "cid" attribute, which MUST be present if the "state" attribute is "active", identifies the section within the multipart/related body that contains the actual resource state. This state is expressed in the content type defined by the event package for conveying state. The cid attribute is the Content-ID for the corresponding section in the multipart body.
Finally, the "cid" attribute, which MUST be present if the "state" attribute is "active", identifies the section within the multipart/related body that contains the actual resource state. This state is expressed in the content type defined by the event package for conveying state. The cid attribute is the Content-ID for the corresponding section in the multipart body.
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root.
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root.
Roach, et al. Standards Track [Page 15] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 15] RFC 4662 SIP Event Lists August 2006
For example, consider a multipart/related document containing
three parts; we'll label these parts A, B, and C. Part A is type
application/rlmi+xml, part B is type multipart/related, and part C
is type application/pidf+xml. Part B is in turn a document
containing three parts: D, E, and F. Part D is of type
application/rlmi+xml, and parts E and F are of type
application/pidf+xml.
For example, consider a multipart/related document containing three parts; we'll label these parts A, B, and C. Part A is type application/rlmi+xml, part B is type multipart/related, and part C is type application/pidf+xml. Part B is in turn a document containing three parts: D, E, and F. Part D is of type application/rlmi+xml, and parts E and F are of type application/pidf+xml.
+-------------------------------------------+
| Top Level Document: multipart/related |
| |
| +---------------------------------------+ |
| | Part A: application/rlmi+xml | |
| +---------------------------------------+ |
| | Part B: multipart/related | |
| | | |
| | +-----------------------------------+ | |
| | | Part D: application/rlmi+xml | | |
| | +-----------------------------------+ | |
| | | Part E: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | Part F: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | |
| +---------------------------------------+ |
| | Part C: application/pidf+xml | |
| +---------------------------------------+ |
| |
+-------------------------------------------+
+-------------------------------------------+ | Top Level Document: multipart/related | | | | +---------------------------------------+ | | | Part A: application/rlmi+xml | | | +---------------------------------------+ | | | Part B: multipart/related | | | | | | | | +-----------------------------------+ | | | | | Part D: application/rlmi+xml | | | | | +-----------------------------------+ | | | | | Part E: application/pidf+xml | | | | | +-----------------------------------+ | | | | | Part F: application/pidf+xml | | | | | +-----------------------------------+ | | | | | | | +---------------------------------------+ | | | Part C: application/pidf+xml | | | +---------------------------------------+ | | | +-------------------------------------------+
Any "cid" attributes in document A must refer only to parts B or
C. Referring to parts D, E, or F would be illegal. Similarly,
any "cid" attributes in document D must refer only to parts E or
F. Referring to any other parts would be illegal.
Also note that the subscription durations of any back-end
subscriptions are not propagated into the meta-information state
in any way.
Any "cid" attributes in document A must refer only to parts B or C. Referring to parts D, E, or F would be illegal. Similarly, any "cid" attributes in document D must refer only to parts E or F. Referring to any other parts would be illegal. Also note that the subscription durations of any back-end subscriptions are not propagated into the meta-information state in any way.
5.6. Constructing Coherent Resource State
5.6. Constructing Coherent Resource State
The resource list subscriber maintains a table for each resource list. The table contains a row for each resource in the resource list. Each row is indexed by the URI for that resource. That URI is obtained from the "uri" attribute on each <resource> element. The contents of each row contain the state of that resource as conveyed in the resource document.
The resource list subscriber maintains a table for each resource list. The table contains a row for each resource in the resource list. Each row is indexed by the URI for that resource. That URI is obtained from the "uri" attribute on each <resource> element. The contents of each row contain the state of that resource as conveyed in the resource document.
Roach, et al. Standards Track [Page 16] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 16] RFC 4662 SIP Event Lists August 2006
For resources that provide versioning information (which is mandated by [2] for any formats that allow partial notification), each row also contains a resource state version number. The version number of the row is initialized with the version specified in the first document received, as defined by the corresponding event package. This value is used when comparing versions of partial notifications for a resource.
For resources that provide versioning information (which is mandated by [2] for any formats that allow partial notification), each row also contains a resource state version number. The version number of the row is initialized with the version specified in the first document received, as defined by the corresponding event package. This value is used when comparing versions of partial notifications for a resource.
The processing of the resource list notification depends on whether it contains full or partial state.
The processing of the resource list notification depends on whether it contains full or partial state.
5.6.1. Processing Full State Notifications
5.6.1. Processing Full State Notifications
If a notification contains full state, indicated by the <list> attribute "fullState" set to "true", the notification is used to update the table. A check is first made to ensure that the "version" attribute of the <list> attribute in the received message is greater than the local version number. If not, the received document is discarded without any further processing. Otherwise, the contents of the resource-list table are flushed and repopulated from the contents of the document. A new row in the table is created for each "resource" element.
If a notification contains full state, indicated by the <list> attribute "fullState" set to "true", the notification is used to update the table. A check is first made to ensure that the "version" attribute of the <list> attribute in the received message is greater than the local version number. If not, the received document is discarded without any further processing. Otherwise, the contents of the resource-list table are flushed and repopulated from the contents of the document. A new row in the table is created for each "resource" element.
5.6.2. Processing Partial State Notifications
5.6.2. Processing Partial State Notifications
If a notification contains partial state, indicated by the <list> attribute "fullState" set to "false", a check is made to ensure that no list notifications have been lost. The value of the local version number (the "version" attribute of the <list> element) is compared to the version number of the new document.
If a notification contains partial state, indicated by the <list> attribute "fullState" set to "false", a check is made to ensure that no list notifications have been lost. The value of the local version number (the "version" attribute of the <list> element) is compared to the version number of the new document.
o If the value in the new document is exactly one higher than the
local version number, the local version number is increased by
one, and the document is processed as described below.
o If the value in the new document is exactly one higher than the local version number, the local version number is increased by one, and the document is processed as described below.
o If the version in the document is more than one higher than the
local version number, the local version number is set to the value
in the new document, and the document is processed as described
below. The list subscriber SHOULD also generate a refresh request
to trigger a full state notification.
o If the version in the document is more than one higher than the local version number, the local version number is set to the value in the new document, and the document is processed as described below. The list subscriber SHOULD also generate a refresh request to trigger a full state notification.
o If the version in the document is less than or equal to the local
version, the document is discarded without any further processing.
o If the version in the document is less than or equal to the local version, the document is discarded without any further processing.
For each resource listed in the document, the subscriber checks to see whether a row exists for that resource. This check is done by comparing the Resource-URI value with the URI associated with the row. If the resource doesn't exist in the table, a row is added, and
For each resource listed in the document, the subscriber checks to see whether a row exists for that resource. This check is done by comparing the Resource-URI value with the URI associated with the row. If the resource doesn't exist in the table, a row is added, and
Roach, et al. Standards Track [Page 17] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 17] RFC 4662 SIP Event Lists August 2006
its state is set to the information from that "resource" element. If the resource does exist, its state is updated to be the information from that "resource" element, as described in the definition of the event package. If a row is updated or created such that its state is now "terminated," that entry MAY be removed from the table at any time.
its state is set to the information from that "resource" element. If the resource does exist, its state is updated to be the information from that "resource" element, as described in the definition of the event package. If a row is updated or created such that its state is now "terminated," that entry MAY be removed from the table at any time.
6. Example
6. Example
This section gives an example call flow. It is not normative. If a conflict arises between this call flow and the normative behavior described in this or any other document, the normative descriptions are to be followed.
This section gives an example call flow. It is not normative. If a conflict arises between this call flow and the normative behavior described in this or any other document, the normative descriptions are to be followed.
In this particular example, we request a subscription to a nested presence list. The subscriber's address-of-record is "sip:adam@vancouver.example.com", and the name of the nested list resource that we are subscribing to is called "sip:adam-buddies@pres.vancouver.example.com". The underlying event package is "presence", described by [8].
In this particular example, we request a subscription to a nested presence list. The subscriber's address-of-record is "sip:adam@vancouver.example.com", and the name of the nested list resource that we are subscribing to is called "sip:adam-buddies@pres.vancouver.example.com". The underlying event package is "presence", described by [8].
In this example, the RLS has information to service some of the resources on the list, but must consult other servers to retrieve information for others. The implementation of the RLS in this example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such information.
In this example, the RLS has information to service some of the resources on the list, but must consult other servers to retrieve information for others. The implementation of the RLS in this example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such information.
Roach, et al. Standards Track [Page 18] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 18] RFC 4662 SIP Event Lists August 2006
Terminal pres.vancouver.example.com pres.stockholm.example.org
| | pres.dallas.example.net |
1 |---SUBSCRIBE--->| | |
2 |<-----200-------| | |
3 |<----NOTIFY-----| | |
4 |------200------>| | |
5 | |---SUBSCRIBE--->| |
6 | |<-----200-------| |
7 | |<----NOTIFY-----| |
8 | |------200------>| |
9 | |------------SUBSCRIBE----------->|
10| |<--------------200---------------|
11| |<-------------NOTIFY-------------|
12| |---------------200-------------->|
13|<----NOTIFY-----| | |
14|------200------>| | |
Terminal pres.vancouver.example.com pres.stockholm.example.org | | pres.dallas.example.net | 1 |---SUBSCRIBE--->| | | 2 |<-----200-------| | | 3 |<----NOTIFY-----| | | 4 |------200------>| | | 5 | |---SUBSCRIBE--->| | 6 | |<-----200-------| | 7 | |<----NOTIFY-----| | 8 | |------200------>| | 9 | |------------SUBSCRIBE----------->| 10| |<--------------200---------------| 11| |<-------------NOTIFY-------------| 12| |---------------200-------------->| 13|<----NOTIFY-----| | | 14|------200------>| | |
1. We initiate the subscription by sending a SUBSCRIBE message to
our local RLS. (There is no reason that the RLS we contact has
to be in our domain, of course). Note that we must advertise
support for application/rlmi+xml and multipart/related because
we support the eventlist extension, and that we must advertise
application/pidf+xml because we are requesting a subscription to
presence.
1. We initiate the subscription by sending a SUBSCRIBE message to our local RLS. (There is no reason that the RLS we contact has to be in our domain, of course). Note that we must advertise support for application/rlmi+xml and multipart/related because we support the eventlist extension, and that we must advertise application/pidf+xml because we are requesting a subscription to presence.
Terminal -> Local RLS
Terminal -> Local RLS
SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip:adam-buddies@pres.vancouver.example.com>
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:terminal.vancouver.example.com>
Event: presence
Expires: 7200
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP terminal.vancouver.example.com; branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: <sip:adam-buddies@pres.vancouver.example.com> From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 322723822 SUBSCRIBE Contact: <sip:terminal.vancouver.example.com> Event: presence Expires: 7200 Supported: eventlist Accept: application/pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: application/pkcs7-mime Content-Length: 0
Roach, et al. Standards Track [Page 19] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 19] RFC 4662 SIP Event Lists August 2006
2. The Local RLS completes the SUBSCRIBE transaction. Note that
authentication and authorization would normally take place at
this point in the call flow. Those steps are omitted for
brevity.
2. The Local RLS completes the SUBSCRIBE transaction. Note that authentication and authorization would normally take place at this point in the call flow. Those steps are omitted for brevity.
Local RLS -> Terminal
Local RLS -> Terminal
SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
To: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Expires: 7200
Require: eventlist
Content-Length: 0
SIP/2.0 200 OK Via: SIP/2.0/TCP terminal.vancouver.example.com; branch=z9hG4bKwYb6QREiCL To: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 322723822 SUBSCRIBE Contact: <sip:pres.vancouver.example.com> Expires: 7200 Require: eventlist Content-Length: 0
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY
immediately upon accepting the subscription. In this example,
we are assuming that the local RLS is also an authority for
presence information for the users in the
"vancouver.example.com" domain. The NOTIFY contains an RLMI
document describing the entire buddy list (initial notifies
require full state), as well as presence information for the
users about which it already knows. Note that, since the RLS
has not yet retrieved information for some of the entries on the
list, those <resource> elements contain no <instance> elements.
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are assuming that the local RLS is also an authority for presence information for the users in the "vancouver.example.com" domain. The NOTIFY contains an RLMI document describing the entire buddy list (initial notifies require full state), as well as presence information for the users about which it already knows. Note that, since the RLS has not yet retrieved information for some of the entries on the list, those <resource> elements contain no <instance> elements.
Local RLS -> Terminal
Local RLS -> Terminal
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<nXYxAE@pres.vancouver.example.com>";
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
NOTIFY sip:terminal.vancouver.example.com SIP/2.0 Via: SIP/2.0/TCP pres.vancouver.example.com; branch=z9hG4bKMgRenTETmm Max-Forwards: 70 From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935768 NOTIFY Contact: <sip:pres.vancouver.example.com> Event: presence Subscription-State: active;expires=7200 Require: eventlist Content-Type: multipart/related;type="application/rlmi+xml"; start="<nXYxAE@pres.vancouver.example.com>"; boundary="50UBfW7LSCVLtggUPe5z" Content-Length: 1560
Roach, et al. Standards Track [Page 20] RFC 4662 SIP Event Lists August 2006
Roach, et al. Standards Track [Page 20] RFC 4662 SIP Event Lists August 2006
--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: <nXYxAE@pres.vancouver.example.com> Content-Type: application/rlmi+xml;charset="UTF-8"
--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: <nXYxAE@pres.vancouver.example.com> Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com"
version="1" fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:bob@vancouver.example.com"">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="bUZBsM@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="ZvSvkz@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
</resource>
</list>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リストxmlns=「つぼ:ietf:params:xml:ナノ秒: rlmi」uriが「一口: adam-friends@pres.vancouver.example.com 」バージョンの=「1インチのfullState=」本当の「><名前xml: lang=」アンと等しい、「>バディがCOM</名の><名前xml: lang=「deに、「COM</名の><リソースがuriする>Liste der Freundeは」 一口: bob@vancouver.example.com と等し」」に記載する、gt;、「アクティブな」<名前>ボブ・スミス</名><例イド="juwigmtboe"状態=Cidは" bUZBsM@pres "と等しいです; "vancouver.example.com"/></リソース><リソースuriは「一口: dave@vancouver.example 」と等しいです; com、「><名前>デーヴジョーンズ名前><例イド="hqzsuxtfyq"州=</「能動態」Cidが" ZvSvkz@pres.vancouver.example.com "/と等しい、gt;、</リソース><リソースuriは「: ed@dallas.example をちびちび飲んでください。」と等しいです; 「「NET</名の></リソース><リソースuri=の>の<の名義の>エド」一口: adam-friends@stockholm.example.org を網で覆ってください」、gt;、lt;、xml: langを=と命名してください、「アン、「ORG</名の><の>My Friendsがxml: langを=と命名する、「de、「ORG</名義の></リソース></が記載する>マイネFreunde、>、」
--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: <bUZBsM@pres.vancouver.example.com> Content-Type: application/pidf+xml;charset="UTF-8"
--50UBfW7LSCVLtggUPe5zの満足している転送コード化: 2進のコンテントID: <bUZBsM@pres.vancouver.example.com>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:bob@vancouver.example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:bob@vancouver.example.com</contact>
</tuple>
</presence>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: bob@vancouver.example.com 」と等しい、gt;、<tupleイド=、「1インチのsg89ae「>の<の状態の>の<の基本的な>開いている</基本的な></状態><接触優先権=」>一口: bob@vancouver.example.com 、lt;、/接触></tupleな></存在>、」
--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary
--50UBfW7LSCVLtggUPe5zの満足している転送コード化: バイナリー
Roach, et al. Standards Track [Page 21] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[21ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Content-ID: <ZvSvkz@pres.vancouver.example.com> Content-Type: application/pidf+xml;charset="UTF-8"
コンテントID: <ZvSvkz@pres.vancouver.example.com>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:dave@vancouver.example.com">
<tuple id="slie74">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: dave@vancouver.example.com 」と等しい、gt;、<tupleイド=「slie74"の<の基本的な>閉じている</基本的な>><状態></状態></tuple></存在>」
--50UBfW7LSCVLtggUPe5z--
--50UBfW7LSCVLtggUPe5z--
4. The terminal completes the transaction.
4. 端末は取引を完了します。
Terminal -> Local RLS
端末の->地方のRLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.vancouver.example.com。 ブランチ=z9hG4bKMgRenTETmm From: <一口: adam-buddies@pres.vancouver.example.com 、gt;、;=zpNctbZq To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =ie4hbb8t呼び出しIDにタグ付けをしてください: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935768 接触に通知してください: <一口: terminal.vancouver.example.com>コンテンツの長さ: 0
5. In order to service the subscription, the local RLS subscribes
to the state of the resources. In this step, the RLS attempts
to subscribe to the presence state of the resource
"sip:ed@dallas.example.net". Since the local RLS knows how to
receive notifications for list subscriptions, it includes the
"Supported: eventlist" header field in its request. Although
the linkage between this subscription and the one sent by the
terminal is left up to the application, this message
demonstrates some reasonable behavior by including "Accept"
header fields for all the body types it knows the subscriber
(Terminal) supports. This is safe to do, since the local RLS
will only pass these formats through to the subscriber and does
not need to actually understand them.
5. 購読を修理するために、地方のRLSはリソースの状態に加入します。 このステップでは、RLSは、「一口: ed@dallas.example.net 」というリソースの存在状態に加入するのを試みます。 地方のRLSが通知繰返し要素の並び購読を受ける方法を知っているので、それは「支持されたこと」を含んでいます。 要求における"eventlist"ヘッダーフィールド。 端末によって送られたこの購読とものの間のリンケージはアプリケーションに任せられますが、このメッセージは、それが、加入者(端末)が支持するのを知っているすべてのボディータイプのために「受け入れてください」というヘッダーフィールドを含んでいることによって、何らかの合理的な振舞いを示します。 これはするために安全です、地方のRLSが加入者にとって終えたこれらの形式を通過するだけであり、実際にそれらを理解する必要はないので。
Local RLS -> Presence Server in dallas.example.net
dallas.example.netの地方のRLS->Presence Server
SUBSCRIBE sip:ed@dallas.example.net SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
一口: 登録、 ed@dallas.example.net SIP/2.0Via: SIP/2.0/TCP pres.vancouver.example.com。 ブランチ=z9hG4bKMEyGjdG1LH
Roach, et al. Standards Track [Page 22] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[22ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Max-Forwards: 70
To: <sip:ed@dallas.example.net>
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn
Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V
zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
マックス-フォワード: 70 To: <一口: ed@dallas.example.net 、gt;、From: <一口: adam@vancouver.example.com 、gt;、; =aM5icQu9呼び出しIDにタグ付けをしてください: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 870936068 接触を申し込んでください: <一口: pres.vancouver.example.com>のアイデンティティ: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8Kアイデンティティインフォメーション: https://vancouver.example.com/cert 出来事: 存在Expires: 3600は支持しました: eventlist Accept: アプリケーション/pidf+xml Accept: アプリケーション/rlmi+xml Accept: 複合の、または、関連するAccept: 複合の、または、サインされたAccept: pkcs7アプリケーション/パントマイムのContent-長さ: 0
6. The Presence Server in dallas.example.net completes the
SUBSCRIBE transaction. Note that authentication would normally
take place at this point in the call flow. This step is omitted
for brevity.
6. dallas.example.netのPresence Serverが完成する、登録、取引。 通常、認証がここに呼び出し流動で行われることに注意してください。 このステップは簡潔さのために省略されます。
Presence Server in dallas.example.net -> Local RLS
dallas.example.net->Local RLSの存在Server
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
To: <sip:ed@dallas.example.net>;tag=e45TmHTh
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:dallas.example.net>
Expires: 3600
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.vancouver.example.com。 ブランチ=z9hG4bKMEyGjdG1LH To: <一口: ed@dallas.example.net 、gt;、;=e45TmHTh From:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =aM5icQu9呼び出しIDにタグ付けをしてください: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 870936068 接触を申し込んでください: <一口: dallas.example.net>は期限が切れます: 3600年のコンテンツの長さ: 0
7. In this example, we assume that the server at dallas.example.net
doesn't have enough authorization information to reject or
accept our subscription. The initial notify, therefore,
contains a "Subscription-State" of "pending". Presumably, the
party responsible for accepting or denying authorization for the
resource is notified of this change; however, those steps are
not included in this call flow for brevity.
7. この例では、私たちは、dallas.example.netのサーバには私たちの購読を拒絶するか、または受け入れることができるくらいの認可情報がないと思います。 初期は、したがって、通知して、「未定」の「購読状態」を含んでいます。 おそらく、リソースのための認可を受け入れるか、または否定するのに責任があるパーティーはこの変化について通知されます。 しかしながら、それらのステップは簡潔さのためのこの呼び出し流動に含まれていません。
Roach, et al. Standards Track [Page 23] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[23ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Presence Server in dallas.example.net -> Local RLS
dallas.example.net->Local RLSの存在Server
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:dallas.example.net>
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
NOTIFY一口: pres.vancouver.example.com SIP/2.0Via: SIP/2.0/TCP pres.dallas.example.net。 ブランチは前方へz9hG4bKfwpklPxmrWマックスと等しいです: 70 From: <一口: ed@dallas.example.net 、gt;、;=e45TmHTh To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =aM5icQu9呼び出しIDにタグ付けをしてください: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 1002640632 接触に通知してください: <一口: dallas.example.net>購読州: 未定である、; =3600Eventを吐き出します: 存在Require: eventlist Content-長さ: 0
8. The local RLS completes the NOTIFY transaction. Note that, at
this point, the Local RLS has new information to report to the
subscriber. Whether it chooses to report the information
immediately or spool it up for later delivery is completely up
to the application. For this example, we assume that the RLS
will wait for a short period of time before doing so, in order
to allow the subscriptions it sent out sufficient time to
provide useful data.
8. 地方のRLSはNOTIFY取引を完了します。 ここに、Local RLSには加入者に報告する新情報があることに注意してください。 それが、すぐに、情報を報告するか、または後の配送のためにそれをスプールするのを選ぶかどうかが完全にアプリケーションまで達しています。 この例に関しては、私たちは、RLSがそうする前に短期間の間待つと思います、役に立つデータを提供できるくらいの時間をそれが出した購読に許容するために。
Local RLS -> Presence Server in dallas.example.net
dallas.example.netの地方のRLS->Presence Server
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.dallas.example.net。 ブランチ=z9hG4bKfwpklPxmrW From: <一口: ed@dallas.example.net 、gt;、;=e45TmHTh To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =aM5icQu9呼び出しIDにタグ付けをしてください: Ugwz5ARxNw@pres.vancouver.example.com CSeq: 1002640632 接触に通知してください: <一口: pres.vancouver.example.com>コンテンツの長さ: 0
9. The Local RLS subscribes to the state of the other non-local
resource.
9. Local RLSはもう片方の非ローカル資源の状態に加入します。
Local RLS -> RLS in stockholm.example.org
stockholm.example.orgの地方のRLS->RLS
SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70
To: <sip:adam-friends@stockholm.example.org>
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
一口: 登録、 adam-friends@stockholm.example.org SIP/2.0Via: SIP/2.0/TCP pres.vancouver.example.com。 ブランチは前方へz9hG4bKFSrAF8CZFLマックスと等しいです: 70 To: <一口: adam-friends@stockholm.example.org 、gt;、From: <一口: adam@vancouver.example.com 、gt;、;=a12eztNfにタグ付けをしてください
Roach, et al. Standards Track [Page 24] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[24ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
呼び出しID: kBq5XhtZLN@pres.vancouver.example.com CSeq: 980774491 接触を申し込んでください: <一口: pres.vancouver.example.com>のアイデンティティ: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8Kアイデンティティインフォメーション: https://vancouver.example.com/cert 出来事: 存在Expires: 3600は支持しました: eventlist Accept: アプリケーション/pidf+xml Accept: アプリケーション/rlmi+xml Accept: 複合の、または、関連するAccept: 複合の、または、サインされたAccept: pkcs7アプリケーション/パントマイムのContent-長さ: 0
10. The RLS in stockholm.example.org completes the SUBSCRIBE
transaction. Note that authentication would normally take place
at this point in the call flow. This step is omitted for
brevity.
10. stockholm.example.orgのRLSが完成する、登録、取引。 通常、認証がここに呼び出し流動で行われることに注意してください。 このステップは簡潔さのために省略されます。
RLS in stockholm.example.org -> Local RLS
stockholm.example.org->Local RLSのRLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:stockholm.example.org>
Expires: 3600
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.vancouver.example.com。 ブランチ=z9hG4bKFSrAF8CZFL To: <一口: adam-friends@stockholm.example.org 、gt;、;=JenZ40P3From:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =a12eztNf呼び出しIDにタグ付けをしてください: kBq5XhtZLN@pres.vancouver.example.com CSeq: 980774491 接触を申し込んでください: <一口: stockholm.example.org>は期限が切れます: 3600年のコンテンツの長さ: 0
11. In this example, we assume that the RLS in stockholm.example.org
is also an authority for presence information for the users in
the "stockholm.example.org" domain. The NOTIFY contains an RLMI
document describing the contained buddy list, as well as
presence information for those users. In this particular case,
the RLS in stockholm.example.org has chosen to sign [14] the
body of the NOTIFY message. As described in RFC 3851, signing
is performed by creating a multipart/signed document that has
two parts. The first part is the document to be signed (in this
example, the multipart/related document that describes the list
resource states), while the second part is the actual signature.
11. この例では、私たちは、また、stockholm.example.orgのRLSが"stockholm.example.org"ドメインのユーザへの存在情報のための権威であると思います。 NOTIFYはそれらのユーザのために含まれた友達リスト、および存在情報について説明するRLMIドキュメントを含んでいます。 この場合は、stockholm.example.orgのRLSは、[14] NOTIFYメッセージのボディーにサインするのを選びました。 RFC3851で説明されるように、調印は2つの部品を持っている複合の、または、サインされたドキュメントを作成することによって、実行されます。 最初の部分はサインされるべきドキュメント(この例のリストリソース州について説明する複合の、または、関連するドキュメント)です、第二部が実際の署名ですが。
Roach, et al. Standards Track [Page 25] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[25ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
RLS in stockholm.example.org -> Local RLS
stockholm.example.org->Local RLSのRLS
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:stockholm.example.org>
Event: presence
Subscription-State: active;expires=3600
Require: eventlist
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038
NOTIFY一口: pres.vancouver.example.com SIP/2.0Via: SIP/2.0/TCP pres.stockholm.example.org。 ブランチは前方へz9hG4bKmGL1nyZfQIマックスと等しいです: 70 From: <一口: adam-friends@stockholm.example.org 、gt;、;=JenZ40P3To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =a12eztNf呼び出しIDにタグ付けをしてください: kBq5XhtZLN@pres.vancouver.example.com CSeq: 294444656 接触に通知してください: <一口: stockholm.example.org>出来事: 存在Subscription-州: 能動態; =3600Requireを吐き出します: eventlistコンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1; 境界は"l3WMZaaL8NpQWGnQ4mlU"コンテンツの長さと等しいです: 2038
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--l3WMZaaL8NpQWGnQ4mlUの満足している転送コード化: 2進のコンテントID: <ZPvJHL@stockholm.example.org>コンテントタイプ: 複合である、または関連しています; タイプ=「アプリケーション/rlmi+xml」;。 「= "<Cvjpeo@stockholm.example.org を始動してください、gt;、」、。 境界="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <Cvjpeo@stockholm.example.org> Content-Type: application/rlmi+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <Cvjpeo@stockholm.example.org>コンテントタイプ: アプリケーション/rlmi+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リストxmlns=「つぼ:ietf:params:xml:ナノ秒: rlmi」uriは「一口: adam-friends@stockholm.example.org 」バージョンの=「1インチのfullState=」本当の「><名前xml: lang=」アンと等しいです。「COM</名の><の>バディ・リストはxmlを命名します」; 「langが等しい、「deに、「COM</名の><リソースがuriする>Liste der Freundeは」 一口: joe@stockholm.example.org と等しい」、gt;、<名前>Joe Thomas</名の><例のイド=「1インチの状態は」 能動態と等しく」Cid=" mrEakg@stockholm.example.org "/、gt; 「</リソース><リソースuri=「一口: mark@stockholm.example.org 」、gt;、<名前>マークエドワーズ</名の><例のイド=「1インチの状態は」 能動態と等しく」Cid=" KKMDmv@stockholm.example.org "/、gt;、</リソース></リスト>。
Roach, et al. Standards Track [Page 26] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[26ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <mrEakg@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <mrEakg@stockholm.example.org>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: joe@stockholm.example.org 」と等しい、gt;、1インチの<tupleイド=「x823a4"の>の<の状態の>の<の基本的な>開いている</基本的な></状態><接触優先権=」>一口: joe@stockholm.example.org 、lt;、/接触></tupleな></存在>。
--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <KKMDmv@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <KKMDmv@stockholm.example.org>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: mark@stockholm.example.org 」と等しい、gt;、<tupleイド=、「z98075「>の<の基本的な>閉じている</基本的な><状態></状態></tuple></存在>」
--tuLLl3lDyPZX0GMr2YOo--
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: <K9LB7k@stockholm.example.org> Content-Type: application/pkcs7-signature
--l3WMZaaL8NpQWGnQ4mlUの満足している転送コード化: 2進のコンテントID: <K9LB7k@stockholm.example.org>コンテントタイプ: pkcs7アプリケーション/署名
[PKCS #7 signature here]
[ここでのPKCS#7署名]
--l3WMZaaL8NpQWGnQ4mlU--
--l3WMZaaL8NpQWGnQ4mlU--
Roach, et al. Standards Track [Page 27] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[27ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
12. The Local RLS completes the NOTIFY transaction.
12. Local RLSはNOTIFY取引を完了します。
Local RLS -> RLS in stockholm.example.org
stockholm.example.orgの地方のRLS->RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.stockholm.example.org。 ブランチ=z9hG4bKmGL1nyZfQI From: <一口: adam-friends@stockholm.example.org 、gt;、;=JenZ40P3To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =a12eztNf呼び出しIDにタグ付けをしてください: kBq5XhtZLN@pres.vancouver.example.com CSeq: 294444656 接触に通知してください: <一口: pres.vancouver.example.com>コンテンツの長さ: 0
13. At this point, the Local RLS decides it has collected enough
additional information to warrant sending a new notification to
the user. Although sending a full notification would be
perfectly acceptable, the RLS decides to send a partial
notification instead. The RLMI document contains only
information for the updated resources, as indicated by setting
the "fullState" parameter to "false". To avoid corrupting the
S/MIME signature on the data received from the RLS in
stockholm.example.org, the local RLS copies the entire
multipart/signed body as-is into the notification that it sends.
13. ここに、Local RLSは、新しい通知をユーザに送るのを保証できるくらいの追加情報を集めたと決めます。 完全な通知を送るのは完全に許容できるでしょうが、RLSは、代わりに部分的な通知を送ると決めます。 RLMIドキュメントはアップデートされたリソースのために「誤っていること」に"fullState"パラメタを設定することによって示されるように情報だけを含んでいます。 stockholm.example.orgのRLSから受け取られたデータでS/MIME署名を崩壊させるのを避けるために、地方のRLSはそのままで全体の複合の、または、サインされたボディーを発信するという通知にコピーします。
Local RLS -> Terminal
地方のRLS->端末
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.vancouver.example.com>";
boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862
NOTIFY一口: terminal.vancouver.example.com SIP/2.0Via: SIP/2.0/TCP pres.vancouver.example.com。 ブランチは前方へz9hG4bK4EPlfSFQK1マックスと等しいです: 70 From: <一口: adam-buddies@pres.vancouver.example.com 、gt;、;=zpNctbZq To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =ie4hbb8t呼び出しIDにタグ付けをしてください: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935769 接触に通知してください: <一口: pres.vancouver.example.com>出来事: 存在Subscription-州: 能動態; =7200Requireを吐き出します: eventlistコンテントタイプ: 複合である、または関連しています; タイプ=「アプリケーション/rlmi+xml」;。 「= "<2BEI83@pres.vancouver.example.com を始動してください、gt;、」、。 境界は"TfZxoxgAvLqgj4wRWPDL"コンテンツの長さと等しいです: 2862
--TfZxoxgAvLqgj4wRWPDL Content-Transfer-Encoding: binary Content-ID: <2BEI83@pres.vancouver.example.com> Content-Type: application/rlmi+xml;charset="UTF-8"
--TfZxoxgAvLqgj4wRWPDLの満足している転送コード化: 2進のコンテントID: <2BEI83@pres.vancouver.example.com>コンテントタイプ: アプリケーション/rlmi+xml; charset=「UTF8インチ」
Roach, et al. Standards Track [Page 28] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[28ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com" version="2"
fullState="false">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
<instance id="sdlkmeopdf" state="pending"/>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
<instance id="cmpqweitlp" state="active"
cid="1KQhyE@pres.vancouver.example.com"/>
</resource>
</list>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リストxmlns=「つぼ:ietf:params:xml:ナノ秒: rlmi」uriは「一口: adam-friends@pres.vancouver.example.com 」バージョンの=「2インチのfullState=」誤った「><名前xml: lang=」アンと等しいです。「COM</名の><の>バディ・リストはxmlを命名します」; langが等しい、「deに、「COM</名の><リソースがuriする>Liste der Freundeは」 一口: ed@dallas.example.net と等しい」、gt;、NET</名><例イド="sdlkmeopdf"状態の<の名義の>エドが「未定」/></リソース><リソースuri=「一口: adam-friends@stockholm.example.org 」と等しい、gt;、lt;、xmlを命名してください:; langが等しい、「アン、「ORG</名の><の>My Friendsがxml: langを=と命名する、「de、「>マイネFreunde ORG</名の><例のイド="cmpqweitlp"州=「能動態」Cidが" 1KQhyE@pres.vancouver.example.com "/と等しい、gt;、</リソース></リスト>、」
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--TfZxoxgAvLqgj4wRWPDLの満足している転送コード化: 2進のコンテントID: <1KQhyE@pres.vancouver.example.com>コンテントタイプ: 複合かサインされる。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1; 境界="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--l3WMZaaL8NpQWGnQ4mlUの満足している転送コード化: 2進のコンテントID: <ZPvJHL@stockholm.example.org>コンテントタイプ: 複合である、または関連しています; タイプ=「アプリケーション/rlmi+xml」;。 「= "<Cvjpeo@stockholm.example.org を始動してください、gt;、」、。 境界="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at ORG</name>
<name xml:lang="de">Liste der Freunde an ORG</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <Cvjpeo@stockholm.example.org>コンテントタイプ: アプリケーション/rlmi+xml; =をcharsetする、「」 =「UTF-8インチ?」をコード化するUTF-8インチの<?xmlバージョン=1インチ><リストxmlns=「つぼ:ietf:params:xml:ナノ秒: rlmi」uriは「一口: adam-friends@stockholm.example.org 」バージョンの=「1インチのfullState=」本当の「><名前xml: lang=」アンと等しいです。「ORG</名の><の>バディ・リストはxmlを命名します」; 「langが等しい、「deに、「ORG</名の><リソースがuriする>Liste der Freundeは」 一口: joe@stockholm.example.org と等しい」、gt;、<名前>Joe Thomas</名の><例のイド=「1インチの状態は」 能動態と等しく」Cid=" mrEakg@stockholm.example.org "/、gt;、</リソース><リソースuri=「一口: mark@stockholm.example.org 」、gt。
Roach, et al. Standards Track [Page 29] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[29ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
「<名前>マークエドワーズ名前><例イド=</「1インチの状態=」能動態」Cidが" KKMDmv@stockholm.example.org "/と等しい、gt;、</リソース></リスト>。
--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <mrEakg@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <mrEakg@stockholm.example.org>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: joe@stockholm.example.org 」と等しい、gt;、1インチの<tupleイド=「x823a4"の>の<の状態の>の<の基本的な>開いている</基本的な></状態><接触優先権=」>一口: joe@stockholm.example.org 、lt;、/接触></tupleな></存在>。
--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <KKMDmv@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOoの満足している転送コード化: 2進のコンテントID: <KKMDmv@stockholm.example.org>コンテントタイプ: アプリケーション/pidf+xml; charset=「UTF8インチ」
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><存在xmlnsが「つぼ:ietf:params:xml:ナノ秒: pidf」実体=「一口: mark@stockholm.example.org 」と等しい、gt;、<tupleイド=、「z98075、「><状態の>の<の基本的な>は</基本的な></状態></tuple></存在>--tuLLl3lDyPZX0GMr2YOoを閉じました」。
--l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: <K9LB7k@stockholm.example.org> Content-Type: application/pkcs7-signature
--l3WMZaaL8NpQWGnQ4mlUの満足している転送コード化: 2進のコンテントID: <K9LB7k@stockholm.example.org>コンテントタイプ: pkcs7アプリケーション/署名
[PKCS #7 signature here]
[ここでのPKCS#7署名]
--l3WMZaaL8NpQWGnQ4mlU--
--l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL--
--TfZxoxgAvLqgj4wRWPDL--
Roach, et al. Standards Track [Page 30] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[30ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
14. The terminal completes the NOTIFY transaction.
14. 端末はNOTIFY取引を完了します。
Terminal -> Local RLS
端末の->地方のRLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
以下を通って一口/2.0 200OK SIP/2.0/TCP pres.vancouver.example.com。 ブランチ=z9hG4bK4EPlfSFQK1From: <一口: adam-buddies@pres.vancouver.example.com 、gt;、;=zpNctbZq To:にタグ付けをしてください <一口: adam@vancouver.example.com 、gt;、; =ie4hbb8t呼び出しIDにタグ付けをしてください: cdB34qLToC@terminal.vancouver.example.com CSeq: 997935769 接触に通知してください: <一口: terminal.vancouver.example.com>コンテンツの長さ: 0
7. Security Considerations
7. セキュリティ問題
Note that the mechanisms for obtaining state information for resources in a list are generally left to the RLS implementor. Some of the security issues below are specific to the circumstance in which a SIP back-end subscription is used for such a purpose. Non- SIP mechanisms for obtaining state information of resources in a list will typically have their own security issues associated with doing so; however, exhaustively enumerating such access methods is not possible in this document. Implementors using such mechanisms must analyze their chosen access methods for relevant security issues.
一般に、リストのリソースのための州の情報を得るためのメカニズムがRLS作成者に任せることに注意してください。 以下の安全保障問題のいくつかがSIPバックエンド購読がそのような目的に使用される状況に特定です。 リストのリソースの州の情報を得るための非SIPのメカニズムには、それら自身のそうすると関連している安全保障問題が通常あるでしょう。 しかしながら、そのようなアクセス法を徹底的に列挙するのは本書では可能ではありません。 そのようなメカニズムを使用している作成者は関連安全保障問題のためにそれらの選ばれたアクセス法を分析しなければなりません。
7.1. Authentication
7.1. 認証
If back-end subscriptions are required to retrieve resource state information, the end user is no longer the direct subscriber to the state of the resource. This means that direct authentication of the user is no longer possible.
バックエンド購読がリソース州の情報を検索するのに必要であるなら、エンドユーザはもうリソースの状態へのダイレクト加入者ではありません。 これは、ユーザのダイレクト認証がもう可能でないことを意味します。
7.1.1. RLS and Subscriber in the Same Domain
7.1.1. 同じドメインのRLSと加入者
It is expected that the most common deployment of RLSes entails that the subscribers to the RLS will be in the same domain as the RLS. When this is the case, the RLS then has the ability to act as an authentication service. The role of authentication service is defined in "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [7].
RLSes限嗣相続のRLSへの加入者がそうする中で最も一般的な展開がRLSと同じドメインにあると予想されます。 そして、これがそうであるときに、RLSには認証サービスとして機能する能力があります。 認証サービスの役割は「セッション開始プロトコル(一口)における認証されたアイデンティティ管理のための増進」[7]で定義されます。
At a high level, under this system, the RLS authenticates the subscriber and then includes an "Identity" header field in all of the back-end subscriptions performed on behalf of that authenticated user. This "Identity" header field cryptographically asserts that the request has been authorized to be made on behalf of the user indicated in the "From" header field.
高いレベルでは、RLSはこのシステムの下では、加入者を認証して、次に、その認証されたユーザを代表して実行されたバックエンド購読のすべてに「アイデンティティ」ヘッダーフィールドを含んでいます。 この「アイデンティティ」ヘッダーフィールドは、“From"ヘッダーフィールドで示されたユーザを代表して要求が作られているのが認可されたと暗号で断言します。
Roach, et al. Standards Track [Page 31] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[31ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Because the ability to authenticate requests is central to the proper functioning of the network, any RLS that uses SIP back-end subscriptions to acquire information about the resources in a resource list MUST be able to act as an authentication service as defined in [7], provided that local administrative policy allows it to do so.
要求を認証する能力がネットワークの適切な機能に主要であるので、リソースリストのリソースの情報を取得するのにSIPバックエンド購読を使用するどんなRLSも[7]で定義される認証サービスとして機能できなければなりません、ローカルの施政方針がそうさせれば。
In other words, all RLS implementations that support back-end SIP
subscriptions also must include the ability to be configured to
act as an authentication service. Whether any given administrator
chooses to activate such a feature is completely up to them. Of
course, lacking the ability to act as an identity server, any RLS
so configured will behave as described in the following section,
since it is effectively acting as if it were in a different domain
than the user.
言い換えれば、バックエンドSIP購読を支持するすべてのRLS実現も、認証サービスとして機能するように構成されるべき能力を含まなければなりません。 何か与えられた管理者が、そのような特徴を活性化するのを選ぶかどうかが、完全なそれら次第です。 もちろん、アイデンティティサーバとして機能する能力を欠いていて、そのように構成されたどんなRLSも以下のセクションで説明されるように振る舞うでしょう、まるで異なったドメインにあるかのようにユーザより事実上行動しているので。
7.1.2. RLS and Subscriber in Different Domains
7.1.2. 異なったドメインのRLSと加入者
In the general case, the SIP Authenticated Identity extensions do not provide a means for the RLS to securely assert that subscriptions are being performed on the end user's behalf. Specifically, when the subscriber and the RLS are in different domains, the RLS will have no means by which it can vouch for the user's identity. Mechanisms by which back-end subscriptions in such circumstances can be authenticated are left for future study.
一般的な場合では、SIP Authenticated Identity拡張子はRLSが、購読がエンドユーザの代理に実行されているとしっかりと断言する手段を提供しません。 加入者とRLSが異なったドメインにあるとき、明確に、RLSには、それがユーザのアイデンティティを保証できる手段が全くないでしょう。 そのような事情におけるバックエンド購読を認証できるメカニズムは今後の研究に残されます。
Until such general solutions are developed, RLSes that are in a different domain than the subscriber on whose behalf they are creating back-end subscriptions SHOULD subscribe to the resources using their own identity. By doing so, the RLS will generally obtain only the resource information that is made publicly available.
そのようなものまで、一般解は開発されています、逆終わりの購読SHOULDがそれら自身のアイデンティティを使用するリソースに彼らが作成しているだれの代理を申し込むかの加入者より異なったドメインにあるRLSes。 一般に、そうすることによって、RLSは公的に利用可能にされるリソース情報だけを得るでしょう。
Absent such general solutions, implementations of subscriber user agents MAY attempt direct subscriptions to resources in the resource list when subscribing to an RLS outside of their domain (either directly or by way of another resource list subscription). The resources to be subscribed to will be those indicated in the "uri" attribute of the <resource> elements present in the RLMI document returned by the RLS. Directly subscribing to the resources allows proper authentication of the user to take place, which will generally authorize them to receive more complete state information. Implementations that choose to perform such direct subscriptions SHOULD use the data retrieved instead of any information about the resource obtained via the list subscription.
彼らのドメイン(直接か別のリソースリスト購読を通した)の外でRLSに加入するとき、そのような一般解がなければ、加入者ユーザエージェントの実装はリソースリストのリソースのダイレクト購読を試みるかもしれません。 加入されるべきリソースはRLSによって返されたRLMIドキュメントの現在の<リソース>要素の"uri"属性で示されたものになるでしょう。 直接リソースに加入するのは行われるユーザの適切な認証を許します。(一般に、それは、彼らが、より完全な州の情報を受け取るのを認可するでしょう)。 そのようなダイレクト購読SHOULDを実行するのを選ぶ実装がリスト購読で得られたリソースのどんな情報の代わりに検索されたデータを使用します。
Roach, et al. Standards Track [Page 32] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[32ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
7.2. Risks of Improper Aggregation
7.2. 不適当な集合のリスク
A resource list server typically serves information to multiple subscribers at once. In many cases, resources may be present in several lists; additionally, it is quite possible that resource list servers will have two users subscribe to the same list.
リソースリストサーバはすぐに、複数の加入者に情報を通常サービスします。 多くの場合、リソースはいくつかのリストに存在しているかもしれません。 さらに、2人のユーザがリソースリストサーバで同じリストに加入するのは、かなり可能です。
In these cases, misguided RLS implementations may attempt to minimize network load by maintaining only one back-end subscription to a resource in a list and presenting the result of such a subscription to more than one user. Of course, doing so circumvents any authorization policy that the notifier for the resource maintains. Keep in mind that authorization is often much more than a simple binary "allowed/not allowed" decision; resources may render very different -- and even conflicting -- resource states, depending on the identity of the subscribing user.
これらの場合では、見当違いのRLS実装は、1つのバックエンド購読だけをリストのリソースに維持して、そのような購読の結果を1人以上のユーザまで提示することによってネットワーク負荷を最小にするのを試みるかもしれません。 もちろん、そうするのはリソースのためのnotifierが維持するどんな承認方針も回避します。 承認が簡単なバイナリーが「許容されなかった/を許容した」という決定よりはるかにしばしば多いのを覚えておいてください。 リソースは非常に異なって、同等の闘争をレンダリングするかもしれません--申し込んでいるユーザのアイデンティティに依存するリソース州。
To prevent the transmission of event information to anyone other than the intended recipient, implementations MUST NOT present the result of one back-end subscription to more than one user, unless:
意図している受取人以外のだれにもイベント情報の伝達を防ぐために、実装が1人以上のユーザの1つのバックエンド購読の結果を提示してはいけない、:
a. The RLS has adequate access to the complete authorization policy
associated with the resource to which the back-end subscription
has been made, AND
a。 RLSはバックエンド購読がされたリソースに関連している完全な承認方針に適切に近づく手段を持っています、AND
b. The RLS can and has determined that presenting the information to
more than one user does not violate such policy.
b。 そして、RLSがそうすることができる、情報を1人以上のユーザまで提示するのがそのような方針に違反しないと決心しているのに、持っています。
Note that this is a very difficult problem to solve correctly. Even in the cases where such access is believed possible, this mode of operation is NOT RECOMMENDED.
正解するためにこれが非常に難しい問題であることに注意してください。 そのようなアクセスが可能であると信じられている場合ではさえ、この運転モードはNOT RECOMMENDEDです。
7.3. Signing and Sealing
7.3. 署名捺印します。
Implementors should keep in mind that any section of the MIME body may be signed and/or encrypted as necessary. Resource List Servers should take care not to modify any MIME bodies they receive from any back-end subscriptions, and should not generally rely on being able to read them.
作成者は、MIME本体のどんなセクションも必要に応じて署名される、そして/または、暗号化されるかもしれないのを覚えておくべきです。 リソースList Serversは、それらを読むことができるので、彼らがどんなバックエンド購読からも受けて、一般に、当てにするべきでないどんなMIME本体も変更しないように注意するはずです。
In order to facilitate security, resource list servers SHOULD pass along indication for support of "multipart/signed" and "application/ pkcs7-mime" content types to any SIP back-end subscriptions, if the subscriber includes them in the initial SUBSCRIBE message. Not doing so may actually result in resources refusing to divulge state (if notifier policy requires encryption, but the RLS fails to convey support), or subscribers discarding valid state (if subscriber policy requires a signature, but the RLS fails to convey support).
セキュリティを容易にするために、リソースリストサーバSHOULDは「複合か署名されること」のサポートのための指示と「pkcs7アプリケーション/パントマイム」content typeをどんなSIPバックエンド購読にも回します、加入者が初期でそれらを入れるなら登録、メッセージ。 そうしないのが実際に状態を明かすのを拒否するリソースをもたらすかもしれない、(notifier方針が暗号化を必要としますが、RLSがサポートを伝えない、)、または、有効な状態(加入者方針がaを必要とするなら、しかし、署名、RLSはサポートを伝えない)を捨てている加入者。
Roach, et al. Standards Track [Page 33] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[33ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Note that actual implementation of encryption and signing by the RLS is not necessary to be able to pass through signed and/or encrypted bodies.
RLSによる暗号化と署名の実際の実装は通り抜けることができるように必要でないというメモが、ボディーを署名する、そして/または、暗号化しました。
7.4. Infinite Loops
7.4. 無限ループ
One risk introduced by the ability to nest resource lists is the possibility of creating lists that ultimately contain themselves as a sub-list. Detection and handling of such a case is trivial when the RLS services all the virtual subscriptions internally. When back-end subscriptions are created to service virtual subscriptions, however, detection of such situations becomes a more difficult problem.
リスクが能力で巣のリソースリストに取り入れた1は結局サブリストとして気持ちを抑えるリストを作成する可能性です。 RLSが内部的にすべての仮想の購読を修理するとき、そのような場合の検出と取り扱いは些細です。 しかしながら、バックエンド購読が仮想の購読を修理するために作成されるとき、そのような状況の検出は、より難しい問題になります。
Implementors of RLSes that create back-end subscriptions MUST implement safeguards to prevent such nestings from creating an infinite loop of subscriptions. Typically, such mechanisms will require support in the back-end subscription protocol. In particular, applying filters to the back-end subscriptions can be an effective way to preclude such problems.
バックエンド購読を作成するRLSesの作成者は、そのような巣篭もりが購読の無限ループを作成するのを防ぐために安全装置を実装しなければなりません。 通常、そのようなメカニズムはバックエンド購読プロトコルで支持を要するでしょう。 バックエンド購読にフィルタを適用するのは、特に、そのような問題を排除する効果的な方法であるかもしれません。
8. IANA Considerations
8. IANA問題
8.1. New SIP Option Tag: eventlist
8.1. 新しい一口オプションタグ: eventlist
This section defines a new option tag for the registry established by Section 27.1 of RFC 3261[1].
このセクションはRFC 3261[1]のセクション27.1によって確立された登録と新しいオプションタグを定義します。
Option Tag Name: eventlist
オプションタグ名: eventlist
Description: Extension to allow subscriptions to lists of resources.
記述: リソースのリストの購読を許す拡大。
Published specification: RFC 4662
広められた仕様: RFC4662
8.2. New MIME type for Resource List Meta-Information
8.2. Resource List Meta-情報のための新しいMIMEの種類
MIME Media Type Name: application
メディア型名をまねてください: アプリケーション
MIME subtype name: rlmi+xml
MIME「副-タイプ」は以下を命名します。 rlmi+xml
Required parameters: None
必要なパラメタ: なし
Optional parameters: charset
任意のパラメタ: charset
See RFC 3023 [12] for a discussion of the charset parameter on
XML-derived MIME types. Since this MIME type is used exclusively
in SIP, the use of UTF-8 encoding is strongly encouraged.
XMLによって派生させられたMIMEの種類についてのcharsetパラメタの議論のためのRFC3023[12]を見てください。 このMIMEの種類が排他的にSIPで使用されるので、UTF-8コード化の使用は強く奨励されます。
Encoding considerations: 8-bit text
問題をコード化します: 8ビットのテキスト
Roach, et al. Standards Track [Page 34] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[34ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Security considerations: Security considerations specific to uses of
this MIME type are discussed in RFC 4662. RFC 1874 [11] and RFC
3023 [12] discuss security issues common to all uses of XML.
セキュリティ問題: RFC4662でこのMIMEの種類の用途に特定のセキュリティ問題について議論します。 RFC1874[11]とRFC3023[12]はXMLのすべての用途に共通の安全保障問題について議論します。
Interoperability considerations: The use of this MIME body is
intended to be generally interoperable. No unique considerations
have been identified.
相互運用性問題: 一般に、このMIME本体の使用を共同利用できさせることを意図します。 どんなユニークな問題も特定されていません。
Published specification: RFC 4662
広められた仕様: RFC4662
Applications that use this media type: This media type is used to
convey meta-information for the state of lists of resources within
a Session Initiation Protocol (SIP) subscription.
このメディアタイプを使用するアプリケーション: このメディアタイプは、Session Initiationプロトコル(SIP)購読の中でリソースのリストの状態のためのメタ情報を伝えるのに使用されます。
Additional information:
Magic Number(s): None.
File Extension(s): None.
Macintosh File Type Code(s): None.
Object Identifier(s) or OID(s): None.
追加情報: マジックナンバー(s): なし。 ファイル拡張子(s): なし。 マッキントッシュファイルタイプは(s)をコード化します: なし。 識別子かOID(s)が反対します: なし。
Intended usage: Limited Use
意図している用法: 株式会社使用
Other Information/General Comment: None.
他の情報/概評: なし。
Person to contact for further information:
Name: Adam Roach
E-Mail: adam@estacado.net
Author/Change Controller: The specification of this MIME type is
a work product of the SIMPLE working group and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
詳細のために連絡する人: 以下を命名してください。 アダムローチE-Mail: adam@estacado.net 作者/変化コントローラ: このMIMEの種類の仕様は、SIMPLEワーキンググループの作業生産物であり、アダム・ローチ、ジョナサン・ローゼンバーグ、およびベン・キャンベルによって書かれました。 IETFには、仕様の変化コントロールがあります。
8.3. URN Sub-Namespace
8.3. つぼのサブ名前空間
URI: urn:ietf:params:xml:ns:rlmi
URI: つぼ:ietf:params:xml:ナノ秒: rlmi
Description: This is the XML namespace URI for XML elements defined
by RFC 4662 to describe information about subscriptions when such
subscriptions are aggregated within a single SIP subscription. It
is used in the application/rlmi+xml body type.
記述: これはそのような購読がただ一つのSIP購読の中で集められるとき、購読の情報について説明するためにRFC4662によって定義されたXML要素のためのXML名前空間URIです。 それはアプリケーション/rlmi+xmlボディータイプで使用されます。
Registrant Contact:
Name: Adam Roach
E-Mail: adam@estacado.net
Author/Change Controller: The specification of this MIME type is
a work product of the SIMPLE working group and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
記入者接触: 以下を命名してください。 アダムローチE-Mail: adam@estacado.net 作者/変化コントローラ: このMIMEの種類の仕様は、SIMPLEワーキンググループの作業生産物であり、アダム・ローチ、ジョナサン・ローゼンバーグ、およびベン・キャンベルによって書かれました。 IETFには、仕様の変化コントロールがあります。
Roach, et al. Standards Track [Page 35] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[35ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SIP Event Resource List
Meta-Information</title>
</head>
<body>
<h1>Namespace for SIP Event Resource List
Meta-Information</h1>
<h2>application/rlmi+xml</h2>
<p>See <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]">
RFC4662</a>.</p>
</body>
</html>
END
XML: BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」><html xmlns=内容=「テキスト/html; 一口イベントリソースのためのcharset=utf-8インチの/><タイトル>名前空間」; リストMeta-情報</タイトル></ヘッド><がSIP Event Resource List Meta-情報</h1><h2>アプリケーション/rlmi+xml</h2><p>See<a href=のために><h1>Namespaceを具体化させる、「 http://www.rfc-editor.org/rfc/rfc4662.txt 「>RFC4662</a>。」; </p></ボディー></html>エンド
9. Acknowledgements
9. 承認
Thanks to Sean Olson for a review of and corrections to the usage of XML in this protocol.
XMLの使用法へのレビューと修正をこのプロトコルでショーン・オルソンをありがとうございます。
Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage, and Robert Sparks for their careful reviews of and comments on this document.
また、このドキュメントの彼らの慎重なレビューとコメントをHisham Khartabil、ポールKyzivat、キースDrage、およびロバート・スパークスをありがとうございます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[3]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Roach, et al. Standards Track [Page 36] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[36ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[4] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[6]、BCP47、RFC3066、2001年1月。
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[7] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
10.2. Informative References
10.2. 有益な参照
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[9] Burger, E., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9]バーガー(E.、「セッション開始プロトコル(一口)メッセージでの満足している間接指定のためのメカニズム」、RFC4483)は2006がそうするかもしれません。
[10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[10] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
[11] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[11] レヴィンソン、E.、「SGMLメディアタイプ」、RFC1874、1995年12月。
[12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[12] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[13]、RFC3851、2004年7月。
[14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[14] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[15] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
Roach, et al. Standards Track [Page 37] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[37ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Authors' Addresses
作者のアドレス
Adam Roach Estacado Systems US
アダムローチエスタカードSystems米国
EMail: adam@estacado.net
メール: adam@estacado.net
Ben Campbell Estacado Systems US
ベンキャンベルエスタカードSystems米国
EMail: ben@estacado.net
メール: ben@estacado.net
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaパーシッパニー、ニュージャージー07054-2711米国
EMail: jdrosen@cisco.com
メール: jdrosen@cisco.com
Roach, et al. Standards Track [Page 38] RFC 4662 SIP Event Lists August 2006
ローチ、他 標準化過程[38ページ]RFC4662はイベントリスト2006年8月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Roach, et al. Standards Track [Page 39]
ローチ、他 標準化過程[39ページ]
一覧
スポンサーリンク
