[要約] RFC 4662は、リソースリストのためのSIPイベント通知拡張に関するものであり、リソースリストの変更を通知するためのメカニズムを提供します。目的は、SIPベースのアプリケーションでリソースリストの変更を効率的に検出し、適切なアクションを実行することです。
Network Working Group A. B. Roach
Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
リソースリストのセッション開始プロトコル（SIP）イベント通知拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントでは、セッション開始プロトコル（SIP）固有のイベント通知メカニズムへの拡張が、均一なリソースリストを購読するためのメカニズムを示しています。各リソースの購読を個別に送信する代わりに、サブスクライバーはリスト全体にサブスクライブし、リスト内のリソースのいずれかの状態が変更された場合に通知を受信できます。
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
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]により、ユーザー（サブスクライバー）が特定のリソースの状態の変更を通知することを要求できます。これは、リソースを表す通知者によって処理されるリソースのサブスクライブリクエストを生成するサブスクライバーによって達成されます。
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 通知者は、長寿命のサブスクリプション状態を避けるために、低い更新間隔を主張する場合があります。これは、サブスクライバーが、容量を希望するよりも速くサブスクライブリフレッシュを生成する必要がある場合があることを意味します。
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 通知者は、サブスクライバーの欲求よりも迅速に通知要求を生成し、サブスクライバーが望んでいるよりも大きなボリュームでトラフィックを通知することができます。
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.
これらの問題を解決するために、この仕様では、リソースのリストの通知を要求して伝えることができるRFC 3265 [2]の拡張を定義します。リソースリストはURIによって識別され、ゼロ以上のURIのリストを表します。これらの各URIは、サブスクライバーが情報を受け取りたい個々のリソースの識別子です。多くの場合、リソースリストを特定するために使用されるURIは、SIP URI [1]になります。ただし、他のスキーム（pres：[10]など）の使用も予測されています。
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.
リストの通知者は、「リソースリストサーバー」または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.
リソースリストは、サブスクライバーのドメイン内にあることに制限されていません。同様に、リスト内のリソースは、リソースリストサーバーのドメインにあるように制約されていません。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [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が権限ではないリソースの状態を学ぶためのバックエンドサブスクリプションを作成します。バックエンドサブスクリプションの場合、RLSEはサブスクライバーとして機能します。
List Subscription: A subscription to a resource list. In list subscriptions, RLSes act as the notifier.
リストサブスクリプション：リソースリストのサブスクリプション。リストのサブスクリプションでは、rlsesは通知者として機能します。
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：リソースリストサーバー。RLSEは、リソースリストへのサブスクリプションを受け入れ、リソースの状態のサブスクライバーを更新するための通知をリソースリストに更新します。
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.
仮想サブスクリプション：仮想サブスクリプションは、リソースリストのリソースへのサブスクリプションを表すRLS内の論理コンストラクトです。各リストサブスクリプションITサービスについて、RLSは、サブスクライブされているリソースリスト内のすべてのリソースに対して少なくとも1つの仮想サブスクリプションを作成します。場合によっては、RLSがリソースの状態の権限ではない場合など、この仮想サブスクリプションはバックエンドサブスクリプションに関連付けられます。他の場合、RLSがリソースの状態の権限である場合など、仮想サブスクリプションには対応するバックエンドサブスクリプションがありません。
This section provides an overview of the typical mode of operation of this extension. It is not normative.
このセクションでは、この拡張機能の典型的な動作モードの概要を説明します。それは規範的ではありません。
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で表されます。リストには、サブスクライバーが情報を受け取ることを望んでいるリソースを表しているURIのセットが含まれています。リソースリストは任意のドメインに存在できます。このリストは、Webページ、音声応答システム、または他のプロトコルを通じて操作できます。リストが作成および維持される特定の手段は、この仕様の範囲外です。
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は紹介者として機能し、サブスクライバーを認証し、サブスクリプションを受け入れます。
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.
リスト通知には、タイプのマルチパート/関連のボディが含まれています。MultiPart/関連コンテンツのルートセクションは、リストに存在する各リソースに関するメタ情報を提供するXMLドキュメントです。残りのセクションには、各リソースの実際の状態情報が含まれています。
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つのイベントパッケージのみを適用できます。
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サブスクリプションではないことに注意してください（ただし、RLSの実装に応じてSIPサブスクリプションが発生する場合があります）。
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（拡張要求）応答コードの処理の規範的な説明については、RFC 3261 [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.
オプションタグの使用の意味の非規範的な説明が続きます。イベントリスト拡張子をサポートするクライアントには、リストを処理する意思のあるサブスクリプションの「サポートされている」ヘッダーフィールドに「サポートされている」ヘッダーフィールドに「イベントリスト」のオプションタグが含まれます。サブスクリプションがリストを表すURIに作成されている場合、RLSには、サブスクライブへの応答の「必要」ヘッダーフィールドに「イベントリスト」が含まれ、そのサブスクリプション内のすべてのメッセージを通知します。
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メッセージでの「要求：イベントリスト」の使用は、notifierによって適用され、UACがUACがUASが処理するために拡張機能を理解していると主張したい場合、UACが必要ヘッダーフィールドを要求に挿入する必要があるというRFC 3261要件を満たすことを満たすことができます。リクエスト。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.
「イベントリスト」を「必要」ヘッダーフィールドにサブスクライブリクエストに含めることは、特定の場合に相互運用性を破ることを除いて目的を果たさないため、推奨されません。
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メッセージに「サポート：イベントリスト」を送信することは無意味で愚かです。実装には、購読を除く任意のリクエストに「サポート：イベントリスト」を含めるべきではありません。
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には、リソースのリストと単一のリソースを表すかどうかを示すものは何もありません。したがって、サブスクライバーがリストリソースを表すが、「イベントリスト」トークンをリストするサポートされているヘッダーフィールドが含まれていないURIにリクエストを送信した場合、Notifierは通常421（拡張要求）応答コードを返します。RFC 3261 [1]は、サーバーが421の返品を避け、代わりに拡張機能なしでリクエストを処理しようとすることをアドバイスしています。ただし、この場合、URIは基本的にリストリソースを表しているため、この拡張機能なしではサブスクリプションを進めることはできません。
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.
リソースリストサーバーの主な利点は、メッセージング全体のボリュームをサブスクライバーに減らすことであるため、リストのサブスクリプション期間を合理的に長くすることをお勧めします。デフォルトは、期間が指定されていない場合、基礎となるイベントパッケージから取得されます。もちろん、標準的な手法[2]を使用して、この量を増やすか減少させることができます。
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).
この仕様に準拠した実装は、MultiPart/関連およびアプリケーション/RLMI XML MIMEタイプをサポートする必要があります。これらのタイプは、クライアントがサポートする他のタイプ（使用されているイベントパッケージに必要なタイプを含む）に加えて、サブスクライブメッセージに送信された受け入れヘッダーに含める必要があります。
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は選択した任意の承認ポリシーを使用できます。
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 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実装間の差別化要因の1つは、通知が生成される方法を集約、レート制限、または最適化する手段です。ベースラインの動作として、RLSは、リストのリソースの状態が変更されるたびに、RLSサブスクライバーに通知を生成する場合があります。
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.
特定のサブスクリプションは、単一のリソースまたはリソースのリストのいずれかのサブスクリプションであることを理解することが重要です。この性質（単一のリソース対リソースリスト）は、単一のサブスクリプションの期間中に変更することはできません。特に、これは、RLSEがRLMIを含むサブスクリプションで以前に通知メッセージを送信した場合、サブスクリプションにRLMIを含む通知メッセージを送信してはならないことを意味します。同様に、RLSEは、サブスクリプションで以前に通知メッセージを送信した場合、サブスクリプションにRLMIを含む通知メッセージを送信してはなりません。
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.
通知にはマルチパートドキュメントが含まれており、その最初の部分には常にリストに関するメタ情報が含まれています（たとえば、メンバーシップ、リソースの仮想サブスクリプションの状態）。残りの部品は、メタ情報にリストされているリソースの実際の状態を伝えるために使用されます。
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].
メタ情報のリソースの各インスタンスの「状態」属性は、仮想サブスクリプションの状態に従って設定されます。「状態」属性の意味は、RFC 3265 [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 unavailability. The RLS MAY continue to do so for future notifications.
リソースのインスタンスが以前にサブスクライバーに報告されたが使用できなくなった場合（つまり、そのインスタンスの仮想サブスクリプションが終了しました）、リソースリストサーバーには、最初のNotifyメッセージにメタ情報にそのリソースインスタンスを含める必要がありますインスタンスの利用不能に続いてサブスクライバーに送信されます。RLSは、将来の通知のために引き続きそうすることができます。
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は「終了」の状態と適切な理由値を示します。正当な理由値とその意味は、RFC 3265 [2]で説明されています。RLSが将来のある時点でリソース状態を再び回復しようとする場合（たとえば、メタ情報の理由が「保護観察」である場合）、リソースのインスタンスはインスタンスまでメタ情報のままである必要があります。状態は利用可能です、または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.
特定のサブスクリプションの最初の購読メッセージが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.
後続のサブスクライブメッセージの結果としてトリガーされた即時通知には、完全な状態が示されるRLMIドキュメントを含める必要があります。また、RLSには、RLSが状態を持っているリスト内のすべてのリソースの状態情報も含める必要があります。これは、政策制限の対象となります。これにより、サブスクライバーは状態を更新し、失われた通知から回復できます。
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 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.
MultiPart/関連ドキュメントのルートに存在するXMLドキュメントには、リスト内の一部またはすべてのリソースの<リソース>要素が含まれています。各<リソース>要素には、そのセクションが対応するリソースを一意に識別するURIが含まれています。Notifyが到着すると、完全または部分的な状態を含めることができます（トップレベル<list>要素の「フルステート」属性で示されています）。完全な状態が示されている場合、受信者はリストに関連付けられているすべての状態を通知機関のエンティティに置き換えます。完全状態が示されていない場合、識別された各リソースの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ドキュメントにのみ適用されることに注意してください。特に、ドキュメント内の<リソース>要素の1つは、別のリソースリストを参照する場合があります。そのようなサブリストは、独自の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.
最後に、リソースリストのサブスクリプションがどのように機能するかの結果として、リソース状態のポーリングは特に有用ではないかもしれないことに注意してください。そのような世論調査はリソースリストを取得しますが、リストの一部またはすべてのリソースの状態を必ずしも含むとは限りません。
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].
全体のアイデアは通知のソースの集中化であるため、イベントリストへのサブスクリプションについては、フォーキングはほとんど意味がありません。したがって、リストのサブスクライバーは、最初のリクエストがフォークされたときに複数のサブスクリプションをインストールしてはなりません。複数の応答が受信された場合、RFC 3265のセクション4.4.9で説明されている手法を使用して処理されます[2]。
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.
RLSの潜在的な役割の1つは、サブスクライバーに代わってレート制限を実行することです。そのため、この仕様は特定の料金制限を義務付けるものではなく、むしろそれを実装の裁量に残します。
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].
複数のリソースの状態を伝えるために、リスト拡張機能は「マルチパート/関連」MIMEタイプを使用します。MultiPart/関連の構文は、「Mime MultiPart/関連コンテンツタイプ」[4]で定義されています。
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.
マルチパート/関連本体のルートドキュメントは、リソースリストメタ情報（RLMI）ドキュメントでなければなりません。タイプ「アプリケーション/RLMI XML」です。このドキュメントには、通知に含まれるリソースのメタ情報が含まれています。このXMLドキュメントのスキーマを以下に示します。
<?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"
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.
このスキーマを使用してフォーマットされたドキュメントの例が続きます。
<?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">
<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>
The <list> element present in a list notification MUST contain three attributes.
リスト通知に存在する<list>要素には、3つの属性を含める必要があります。
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.
最初の必須<list>属性は「URI」で、リストに対応するURIが含まれています。通常、これは購読要求が送信されたURIです。
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.
2番目の必須<list>属性は「バージョン」で、0から2^32-1の数が含まれています。このバージョン番号は、サブスクリプション内で送信された最初のNotifyメッセージの場合は0でなければならず、サブスクリプション内で送信される各通知ごとに1つだけ増加する必要があります。
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.
3番目の必須属性は「フルステート」です。「FullState」属性は、Notifyメッセージにリスト内のすべてのリソースの情報が含まれているかどうかを示します。もしそうなら、属性の値は「真」（または「1」）です。それ以外の場合、それは「false」（または「0」）です。サブスクリプションで送信された最初のNotifyには、サブスクリプションのサブスクライブリクエストを受け取った後に最初に送信された通知が必要とするように、完全な状態を含める必要があります。
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.
最後に、<list>要素には「CID」属性が含まれる場合があります。存在する場合、「CID」属性は、リストに含まれるリソースの集計状態情報を含むマルチパート/関連する本体内のセクションを識別します。このような集計情報の定義は、このドキュメントの範囲外であり、必要に応じてパッケージごとに定義されます。CID属性は、マルチパートボディの対応するセクションのコンテンツIDです。
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.
CID属性は、それが表示されるRLMIドキュメントがルートであるMultiPart/関連ドキュメントのトップレベルの部分のみを参照する必要があります。例については、セクション5.5を参照してください。
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.
リソースリストには、通知で報告されている各リソースの1つの<リソース>要素が含まれています。これらのリソース要素には、各リソースに関連付けられたメタデータを識別する属性が含まれています。
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.
「uri」属性は、<リソース>要素が対応するリソースを識別します。通常、これは、サブスクライブされた場合、リソースの状態を返すSIP URIです。この属性は存在する必要があります。
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.
各リストとリソース要素には、ゼロ以上の名前要素が含まれています。これらの名前の要素には、リソースリストまたはリソースの人間が読みやすい説明または名前が含まれています。これらの要素の内容は、SIP名-ADDR要素に存在する「ディスプレイ名」に多少類似しています。
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.
名前の要素には、オプションで標準のXML "xml：lang"属性が含まれています。「xml：lang」属性は、存在する場合、人間が読める名前の言語を指定します。この属性が存在する場合、有効な言語タグを含める必要があります。言語タグは、RFC 3066 [6]で定義されています。言語タグは、潜在的に複数の名前要素をユーザーにレンダリングすべきかを決定する際にアプリケーションを支援します。
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.
各リソース要素には、ゼロ以上のインスタンス要素が含まれています。これらのインスタンス要素は、リソースの単一の通知者を表すために使用されます。フォーキングを可能にするイベントパッケージの場合、特定のリソースに対して複数の仮想サブスクリプションが存在する場合があります。複数の仮想サブスクリプションは、対応するリソース要素の複数のインスタンス要素として表されます。フォーキングが発生しないサブスクリプションの場合、最大で1つのインスタンスが特定のリソースに存在します。
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.
「ID」属性には、リソースのインスタンスを一意に識別するために使用される不透明な文字列が含まれています。「ID」属性は、リソースのコンテキスト内でのみ一意です。この文字列の構築は実装決定です。この文字列を生成するためのメカニズムは、リソース内の一意性が保証されている限り有効です。
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 these values are as defined for the "Subscription-State" header field in RFC 3265 [2].
「状態」属性には、リソースの識別されたインスタンスのサブスクリプション状態が含まれています。この属性には、「アクティブ」、「保留中」、または「終了」の値の1つが含まれます。これらの値の意味は、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.
「状態」属性が「終了」を示す場合、「理由」属性も存在する必要があります。この「理由」属性は、RFC 3265の「サブスクリプション状態」ヘッダーフィールドの「理由」パラメーターに与えられたものと同じ値と意味を持っています[2]。「理由」属性が情報目的で含まれていることに注意してください。リストサブスクライバーは、理由値に基づいて自動化されたアクションを実行することは期待されていません。
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.
最後に、「状態」属性が「アクティブ」である場合に存在する必要がある「CID」属性は、実際のリソース状態を含むマルチパート/関連本体内のセクションを識別します。この状態は、状態を伝えるためのイベントパッケージで定義されたコンテンツタイプで表現されています。CID属性は、マルチパートボディの対応するセクションのコンテンツIDです。
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.
CID属性は、それが表示されるRLMIドキュメントがルートであるMultiPart/関連ドキュメントのトップレベルの部分のみを参照する必要があります。
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.
たとえば、3つの部分を含むマルチパート/関連ドキュメントを検討してください。これらのパートA、B、およびCにラベルを付けます。パートAはタイプアプリケーション/RLMI XML、パートBはタイプマルチパート/関連、パートCはタイプアプリケーション/PIDF XMLです。パートBは、D、E、およびFの3つの部分を含むドキュメントです。パートDはタイプアプリケーション/RLMI XMLで、パートEとFはタイプアプリケーション/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.
ドキュメントAの「CID」属性は、パートBまたはCのみを参照する必要があります。パートD、E、またはFを参照することは違法です。同様に、ドキュメントDの「CID」属性は、パーツEまたはFのみを参照する必要があります。他のパーツを参照することは違法です。また、バックエンドサブスクリプションのサブスクリプション期間は、メタ情報状態には何らかの形で伝播されないことに注意してください。
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.
リソースリストサブスクライバーは、各リソースリストのテーブルを維持します。テーブルには、リソースリストの各リソースの行が含まれています。各行は、そのリソースのURIによってインデックス化されています。そのURIは、各<リソース>要素の「URI」属性から取得されます。各行の内容には、リソースドキュメントで伝えられるリソースの状態が含まれています。
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.
バージョン化情報（部分的な通知を許可する任意の形式について[2]によって義務付けられている）を提供するリソースの場合、各行にはリソース状態バージョン番号も含まれています。行のバージョン番号は、対応するイベントパッケージで定義されているように、受信した最初のドキュメントで指定されたバージョンで初期化されます。この値は、リソースの部分通知のバージョンを比較するときに使用されます。
The processing of the resource list notification depends on whether it contains full or partial state.
リソースリスト通知の処理は、完全な状態か部分状態が含まれているかによって異なります。
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.
通知に「True」に設定された<list>属性「Fullstate」で示される完全な状態が含まれている場合、通知はテーブルの更新に使用されます。最初にチェックが作成され、受信したメッセージの<list>属性の「バージョン」属性がローカルバージョン番号よりも大きいことを確認します。そうでない場合、受信したドキュメントは、さらに処理することなく破棄されます。それ以外の場合、リソースリストテーブルの内容は、ドキュメントの内容からフラッシュされ、再現されます。テーブル内の新しい行は、各「リソース」要素に対して作成されます。
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.
通知に「false」に設定された<list>属性「Fullstate」で示される部分状態が含まれている場合、リスト通知が失われていないことを確認するためにチェックが作成されます。ローカルバージョン番号（<list>要素の「バージョン」属性）の値は、新しいドキュメントのバージョン番号と比較されます。
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 新しいドキュメントの値がローカルバージョン番号よりも正確に1つ高い場合、ローカルバージョン番号は1つずつ増加し、ドキュメントは以下に説明するように処理されます。
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 ドキュメントのバージョンがローカルバージョン番号よりも複数高い場合、ローカルバージョン番号は新しいドキュメントの値に設定され、ドキュメントは以下に説明するように処理されます。リストサブスクライバーは、完全な状態通知をトリガーするための更新リクエストも生成する必要があります。
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 ドキュメントのバージョンがローカルバージョン以下の場合、ドキュメントはさらに処理することなく破棄されます。
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 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.
ドキュメントにリストされている各リソースについて、サブスクライバーはそのリソースの行が存在するかどうかを確認します。このチェックは、リソース-RI値を行に関連付けられたURIと比較することによって行われます。リソースがテーブルに存在しない場合、行が追加され、その状態はその「リソース」要素からの情報に設定されます。リソースが存在する場合、その状態は、イベントパッケージの定義で説明されているように、その「リソース」要素からの情報に更新されます。行が更新または作成されている場合、その状態が「終了」されるようになった場合、そのエントリはいつでもテーブルから削除される可能性があります。
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].
この特定の例では、ネストされた存在リストのサブスクリプションをリクエストします。サブスクライバーの記録アドレスは「sip：adam@vancouver.example.com」であり、購読しているネストされたリストリソースの名前は「sip：adam-buddies@pres.vancouver.example.com」と呼ばれます。。基礎となるイベントパッケージは、[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.
この例では、RLSにはリスト上のいくつかのリソースにサービスを提供する情報がありますが、他のサーバーのために他のサーバーを参照して他のサーバーを取得する必要があります。この例のRLSの実装では、SIPサブスクライブ/通知メカニズムを使用して、そのような情報を取得します。
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. 地元のRLSに購読メッセージを送信してサブスクリプションを開始します。（もちろん、私たちが接触しているRLSが私たちのドメインにある必要があるという理由はありません）。イベントリスト拡張機能をサポートするため、アプリケーション/RLMI XMLおよびマルチパート/関連のサポートを宣伝する必要があり、存在のサブスクリプションをリクエストしているため、アプリケーション/PIDF XMLを宣伝する必要があることに注意してください。
Terminal -> Local RLS
端末 - >ローカル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 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.
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>;タグ= IE4HBB8T CALL-ID：CDB34QLTOC@末端。vancouver.example.com CSEQ：322723822サブスクライブ連絡先：<sip：terminal.vancouver.example.com>イベント：存在期限：7200サポート：イベントリスト：アプリケーション/PIDF XML Accept：Application/RLMI XML Accept：MultiPART/LECAST ACCEPT：MultiPart/Signed Accept：Application/PKCS7-MIME Content-Length：0 2.ローカルRLSはサブスクライブトランザクションを完了します。認証と承認は通常、コールフローのこの時点で行われることに注意してください。これらの手順は簡潔に省略されています。
Local RLS -> Terminal
ローカルRLS->ターミナル
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. RFC 3265 [2]で必要なように、RLSはサブスクリプションを受け入れるとすぐに通知を送信します。この例では、ローカルRLSは、「vancouver.example.com」ドメインのユーザーの存在情報の権限でもあると仮定しています。Notifyには、バディリスト全体（初期通知が完全な状態を必要とする）と、すでに知っているユーザーの存在情報を説明するRLMIドキュメントが含まれています。RLSは、リストの一部のエントリの情報をまだ取得していないため、これらの要素には<インスタンス>要素が含まれています。
Local RLS -> Terminal
ローカルRLS->ターミナル
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
--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>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <bUZBsM@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <ZvSvkz@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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>
--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
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はリソース「sip：ed@dallas.example.net」の存在状態を購読しようとします。ローカルRLSは、リストサブスクリプションの通知を受信する方法を知っているため、リクエストに「サポート：イベントリスト」ヘッダーフィールドが含まれています。このサブスクリプションと端末によって送信されたものとの間のリンケージはアプリケーションに任されていますが、このメッセージは、サブスクライバー（端子）サポートを知っているすべてのボディタイプに「受け入れる」ヘッダーフィールドを含めることにより、何らかの合理的な動作を示します。ローカルRLSはこれらの形式をサブスクライバーに渡すだけで、実際にそれらを理解する必要がないため、これは安全です。
Local RLS -> Presence Server in dallas.example.net
ローカルRLS-> dallas.example.netのプレゼンスサーバー
SUBSCRIBE sip:ed@dallas.example.net SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
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
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の存在サーバーは、subscribeトランザクションを完了します。認証は通常、コールフローのこの時点で行われることに注意してください。この手順は簡潔に省略されています。
Presence Server in dallas.example.net -> Local RLS
dallas.example.netの存在サーバー - >ローカルrls
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
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のサーバーには、サブスクリプションを拒否または受け入れるのに十分な承認情報がないと想定しています。したがって、最初のNotifyには、「保留中」の「サブスクリプション状態」が含まれています。おそらく、リソースの許可を受け入れるか拒否する責任者がこの変更を通知されます。ただし、これらの手順は、簡潔にするためにこのコールフローに含まれていません。
Presence Server in dallas.example.net -> Local RLS
dallas.example.netの存在サーバー - >ローカルrls
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
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トランザクションを完了します。この時点で、ローカルRLSにはサブスクライバーに報告する新しい情報があることに注意してください。すぐに情報を報告することを選択したか、後で配達するためにそれをスプールアップするかどうかは、完全にアプリケーション次第です。この例では、サブスクリプションを送信して有用なデータを提供するのに十分な時間を出すために、RLSが短期間待機する前に待機すると仮定します。
Local RLS -> Presence Server in dallas.example.net
ローカルRLS-> dallas.example.netのプレゼンスサーバー
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
9. The Local RLS subscribes to the state of the other non-local resource.
9. ローカル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
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
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の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
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がNotifyメッセージの本文に署名することを選択しました。RFC 3851で説明されているように、署名は、2つの部分を持つマルチパート/署名ドキュメントを作成することにより実行されます。最初の部分は署名されるドキュメントです（この例では、リストリソース状態を説明するマルチパート/関連ドキュメント）、2番目の部分は実際の署名です。
RLS in stockholm.example.org -> Local RLS
stockholm.example.orgの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
--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"
--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 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>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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--
-tulll3ldypzx0gmr2yoo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
[PKCS＃7署名はこちら]
--l3WMZaaL8NpQWGnQ4mlU-- 12. The Local RLS completes the NOTIFY transaction.
-l3wmzaal8npqwgnq4mlu--12。ローカル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
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. この時点で、ローカルRLSは、新しい通知をユーザーに送信することを保証するのに十分な追加情報を収集したと判断しました。完全な通知を送信することは完全に受け入れられますが、RLSは代わりに部分的な通知を送信することにしました。RLMIドキュメントには、「Fullstate」パラメーターを「False」に設定することで示されるように、更新されたリソースの情報のみが含まれています。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
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@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="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>
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="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"
--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">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?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--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
[PKCS＃7署名はこちら]
--l3WMZaaL8NpQWGnQ4mlU--
-l3wmzaal8npqwgnq4mlu--
--TfZxoxgAvLqgj4wRWPDL-- 14. The terminal completes the NOTIFY transaction.
-TFZXOXGAVLQGJ4WRWPDL - 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
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メカニズムには、通常、そうすることに関連する独自のセキュリティ問題があります。ただし、このドキュメントでは、このようなアクセス方法を徹底的に列挙することは不可能です。このようなメカニズムを使用して、関連するセキュリティの問題について選択したアクセス方法を分析する必要があります。
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.
リソース状態情報を取得するためにバックエンドサブスクリプションが必要な場合、エンドユーザーはリソースの状態の直接サブスクライバーではなくなります。これは、ユーザーの直接認証が不可能であることを意味します。
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].
RLSEの最も一般的な展開は、RLSのサブスクライバーがRLSと同じドメインにあることを伴うことが予想されます。この場合、RLSには認証サービスとして機能する機能があります。認証サービスの役割は、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」[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はサブスクライバーを認証し、その認証されたユーザーに代わって実行されたすべてのバックエンドサブスクリプションに「ID」ヘッダーフィールドを含めます。この「アイデンティティ」ヘッダーフィールドは、「From」ヘッダーフィールドに示されているユーザーに代わって、リクエストが行われることが許可されていることを暗号化します。
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は、次のセクションで説明されているように動作します。これは、ユーザーとは異なるドメインにあるかのように効果的に動作しているためです。
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認証型ID拡張は、RLSがエンドユーザーに代わってサブスクリプションが実行されていることを安全に主張する手段を提供しません。具体的には、サブスクライバーとRLSが異なるドメインにある場合、RLSはユーザーのIDを保証できる手段を持たません。このような状況でバックエンドのサブスクリプションを認証できるメカニズムは、将来の研究のために残されています。
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.
このような一般的なソリューションが開発されるまで、バックエンドサブスクリプションを作成しているサブスクライバーとは異なるドメインにあるRLSEは、独自のアイデンティティを使用してリソースをサブスクライブする必要があります。そうすることで、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」属性に示されているものです。リソースを直接購読することで、ユーザーが適切に認証できるようになり、一般に、より完全な州情報を受信することが許可されます。このような直接サブスクリプションを実行することを選択する実装は、リストサブスクリプションを介して取得したリソースに関する情報の代わりに取得したデータを使用する必要があります。
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の実装は、リスト内のリソースへのバックエンドサブスクリプションのみを維持し、そのようなサブスクリプションの結果を複数のユーザーに提示することにより、ネットワーク負荷を最小限に抑えようとする場合があります。もちろん、そうすることで、リソースの通知者が維持する許可ポリシーを回避します。許可は、多くの場合、単純なバイナリ「許可/許可されていない」決定以上のものであることに注意してください。リソースは、購読ユーザーの身元に応じて、リソースの状態が非常に異なる場合があります。
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つのバックエンドサブスクリプションの結果を複数のユーザーに提示してはなりません。
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は、バックエンドサブスクリプションが作成されたリソースに関連する完全な承認ポリシーに十分なアクセスを持っています。
b. The RLS can and has determined that presenting the information to more than one user does not violate such policy.
b. RLSは、情報を複数のユーザーに提示することで、そのようなポリシーに違反しないと判断しました。
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.
これは正しく解決するのが非常に難しい問題であることに注意してください。そのようなアクセスが可能になっている場合でも、この動作モードは推奨されません。
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ボディのセクションには、必要に応じて署名および/または暗号化される場合があることに留意する必要があります。リソースリストサーバーは、バックエンドのサブスクリプションから受け取った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).
セキュリティを容易にするために、リソースリストサーバーは、サブスクライバーが最初のサブスクライブメッセージにそれらを含める場合、任意のSIPバックエンドサブスクリプションに「MultiPart/ Signed」および「Application/ PKCS7-MIME」コンテンツタイプをサポートするために適応を渡す必要があります。そうしないと、実際には状態の漏れを拒否するリソース（通知者ポリシーが暗号化が必要な場合、RLSはサポートを伝えることができない場合）、またはサブスクライバーが有効な状態を破棄する場合（加入者ポリシーが署名を必要とするが、RLSはサポートを伝えることができない場合）。
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による暗号化と署名の実際の実装は、署名されたボディや暗号化されたボディを通過できるようにするために必要ではないことに注意してください。
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.
バックエンドサブスクリプションを作成するRLSEの実装者は、そのようなネストがサブスクリプションの無限のループを作成するのを防ぐために保護ガードを実装する必要があります。通常、このようなメカニズムは、バックエンドサブスクリプションプロトコルでサポートを必要とします。特に、バックエンドのサブスクリプションにフィルターを適用することは、そのような問題を排除する効果的な方法です。
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
オプションタグ名：イベントリスト
Description: Extension to allow subscriptions to lists of resources.
説明：リソースのリストにサブスクリプションを許可する拡張機能。
Published specification: RFC 4662
公開された仕様：RFC 4662
MIME Media Type Name: application
MIMEメディアタイプ名：アプリケーション
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パラメーターの議論については、RFC 3023 [12]を参照してください。このMIMEタイプはSIPのみで使用されるため、UTF-8エンコーディングの使用が強く奨励されています。
Encoding considerations: 8-bit text 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.
考慮事項のエンコーディング：8ビットテキストセキュリティに関する考慮事項：このMIMEタイプの使用に固有のセキュリティ考慮事項は、RFC 4662で説明されています。RFC1874[11]およびRFC 3023 [12]は、XMLのすべての用途に共通するセキュリティの問題を議論します。
Interoperability considerations: The use of this MIME body is intended to be generally interoperable. No unique considerations have been identified.
相互運用性の考慮事項：このマイムボディの使用は、一般に相互運用可能であることを目的としています。独自の考慮事項は特定されていません。
Published specification: RFC 4662
公開された仕様：RFC 4662
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.
このメディアタイプを使用するアプリケーション：このメディアタイプは、セッション開始プロトコル（SIP）サブスクリプション内のリソースのリストの状態のメタ情報を伝えるために使用されます。
Additional information: Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None. Object Identifier(s) or OID(s): None.
追加情報：マジック番号：なし。ファイル拡張子：なし。Macintoshファイルタイプコード：なし。オブジェクト識別子または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.
詳細については連絡先：名前：Adam Roach E-mail：adam@estacado.net著者/変更コントローラー：このMimeタイプの仕様は、シンプルなワーキンググループの作業製品であり、Adam Roach、Jonathan Rosenbergによって作成されました。とベン・キャンベル。IETFには、その仕様を変更することができます。
URI: urn:ietf:params:xml:ns: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.
説明：これは、RFC 4662で定義されたXML名のURIで、そのようなサブスクリプションが単一のSIPサブスクリプション内に集約されている場合のサブスクリプションに関する情報を説明するXML要素のXML要素です。アプリケーション/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.
登録者の連絡先：名前：Adam Roach電子メール：adam@estacado.net著者/変更コントローラー：このMimeタイプの仕様は、シンプルなワーキンググループの作業製品であり、Adam Roach、Jonathan Rosenberg、およびBen Campbellによって執筆されました。IETFには、その仕様を変更することができます。
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
Thanks to Sean Olson for a review of and corrections to the usage of XML in this protocol.
このプロトコルでのXMLの使用のレビューと修正についてSean Olsonに感謝します。
Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage, and Robert Sparks for their careful reviews of and comments on this document.
Hisham Khartabil、Paul Kyzivat、Keith Drage、およびRobert Sparksにも感謝します。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A。B.、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[4] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[6] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[7] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[9] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9] Burger、E。、「セッション開始プロトコル（SIP）メッセージにおけるコンテンツ間接メカニズム」、RFC 4483、2006年5月。
[10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[10] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2004年8月。
[11] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[11] レビンソン、E。、「SGMLメディアタイプ」、RFC 1874、1995年12月。
[12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[12] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[13] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、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] Galvin、J.、Murphy、S.、Crocker、S.、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[15] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
Authors' Addresses
著者のアドレス
Adam Roach Estacado Systems US
Adam Roach Estacado Systems US
EMail: adam@estacado.net
Ben Campbell Estacado Systems US
Ben Campbell Estacado Systems US
EMail: ben@estacado.net
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054-2711 US
EMail: jdrosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。