RFC 4662 - A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists 日本語訳

URL : https://tools.ietf.org/html/rfc4662
タイトル : RFC 4662 - リソースリストのためのセッション開始プロトコル（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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（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.

この文書では、セッション開始プロトコル（SIP）リソースの均質リストに加入するための固有のイベント通知メカニズムへの拡張を提供します。代わりに、個別に各リソースのためにSUBSCRIBE送信するのでは、加入者がリスト全体に加入してからの通知を受け取ることができたときに、リストの変更内のリソースのいずれかの状態。

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. 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]ユーザ（加入者）が、特定のリソースの状態の変化を通知することを要求することを可能にします。これは、リソースを表す通知によって処理されるリソースに対するSUBSCRIBE要求を生成する加入者によって達成されます。

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:

多くの場合、加入者は、彼らが興味を持っているリソースのリストを持っている。いくつかの集約メカニズムがなければ、これは、彼らが情報が必要なリソースごとにSUBSCRIBEリクエストを生成するために、加入者が必要になります。このような無線ネットワークのような帯域幅が制限された環境のため、個別リソースにサブスクライブすることは問題があります。いくつかの具体的な問題は次のとおりであります：

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をその初期には各リソースの要求と、個々のサブスクリプションのリフレッシュをSUBSCRIBEの形で、かなりのメッセージトラフィックを生成します。

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通知は、長寿命のサブスクリプションの状態を避けるために、低リフレッシュ間隔を主張することがあります。これは、加入者がより速く、それが好きかに能力を持っているだろうよりリフレッシュをSUBSCRIBE生成する必要があるかもしれないことを意味します。

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通知は、加入者が所望するよりも大きな音量でトラフィックを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.

これらの問題を解決するために、この仕様はRFC 3265への拡張を定義する[2]リソースのリストの通知を要求し、搬送を可能にすること。リソースリストは、URIによって識別され、それはゼロ以上のURIのリストを表しています。これらのURIのそれぞれは、加入者が情報を受信したいために、個々のリソースの識別子です。多くの場合、URIは、[1]リソースリストはSIP URIであろう識別するために使用されます。しかしながら、（例えば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.

リソースリストは、加入者のドメイン内に制限されていません。同様に、リスト内のリソースは、リソースリストサーバのドメインにあるように制約されません。

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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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は権威ではないかについてのリソースの状態を知るために、バックエンドサブスクリプションを作成します。バックエンドサブスクリプションの場合、RLSesは、加入者としての役割を果たす。

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：リソースリストサーバー。 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.

仮想サブスクリプション：仮想加入者は、リソースリスト内のリソースへのサブスクリプションを表し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.

このセクションでは、この拡張の動作の代表的な態様の概要を提供します。それは規範的ではありません。

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を対象と単一SUBSCRIBEリクエストを送信します。これは、その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.

リストの通知は、関連/マルチパートタイプのボディが含まれています。マルチパート/関連コンテンツの根元部には、リスト内の各リソースの存在についてのメタ情報を提供する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イベントパッケージを適用することができます。

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).

（彼らはRLSの実装に応じて、SIPサブスクリプションにつながるかもしれないが）これらの仮想サブスクリプションがリテラルSIPサブスクリプションではないことに注意してください。

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（拡張必須）応答コードの処理の規定については、[1] RFC 3261を参照。

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.

オプションタグの使用の意味合いの非規範的な説明は次のとおり。イベントリストの拡張をサポートする任意のクライアントは、すべての「サポート」ヘッダフィールドに「eventlist」のオプションタグが含まれます、リストを処理するために喜んでいるサブスクリプションのメッセージをSUBSCRIBE。サブスクリプションは、リストを表すURIに行われた場合、RLSは、SUBSCRIBEに対する応答の「必要」ヘッダフィールドに「eventlist」を含めて、すべてにそのサブスクリプション内のメッセージを通知します。

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メッセージでUACがUASを処理するために拡張機能を理解することを主張したい場合UACがリクエストにRequireヘッダーフィールドを挿入しなければならないRFC 3261の要件を満たすために、通知によって適用される：「eventlistが必要」の使用要求。 NOTIFYはeventlistオプションを適用せずに使用可能ではありませんので、通知は、それが含まれるように義務付けられています。

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.

SUBSCRIBE要求がある場合には、相互運用性を破壊する以外に目的を果たしていない、その結果、推奨されていないのヘッダフィールドを「必要」の「eventlist」を含みます。

Sending of "Supported: eventlist" in a NOTIFY message is meaningless and silly. Implementations SHOULD NOT include "Supported: eventlist" in any requests except for SUBSCRIBE.

送信「をサポート：eventlist」NOTIFYメッセージでは無意味と愚かです。 SUBSCRIBEを除くすべての要求に：実装は、「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に要求を送信した場合そのため、通知は、典型的には421（拡張必須）応答コードが返されます。 RFC 3261には、[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.

リソースリストサーバの主な利点は、加入者への総合的なメッセージング量を削減することですので、リストへのサブスクリプション期間が合理的に長くすることをお勧めします。デフォルトは、期間が指定されていない場合は、基本的なイベントパッケージから取られています。もちろん、標準的な技術[2]は、この量を増加または減少させるために使用することができます。

4.3. NOTIFY Bodies

4.3. ボディをNOTIFY

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タイプをサポートしなければなりません。これらのタイプは、（使用されているイベントパッケージによって必要とされる任意のタイプを含む）は、クライアントでサポートされている任意の他のタイプに加えて、SUBSCRIBEメッセージで送信された受け入れヘッダに含まれなければなりません。

4.4. RLS Processing of SUBSCRIBE Requests

4.4. SUBSCRIBE要求の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は、そのローカルポリシーごとの認可を行います。多くの場合、各リソースのリストは、特定のユーザ（それを作成し、その中の要素のセットを管理します1）に関連付けられ、そのユーザのみが加入することを許可されます。もちろん、この動作モードは、リソースリストの使用に固有ではなく、RLSは、それが選択した任意の認可ポリシーを使用することができます。

4.5. RLS Generation of NOTIFY Requests

4.5. NOTIFYリクエストの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.

この仕様は、実装者の裁量でNOTIFYリクエストを生成する方法と時期についての選択肢を残します。様々なRLS実装間の差別化の一つは、それらが、レート制限を集約、または通知が生成される方法を最適化する手段です。ベースラインの行動として、RLSは、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.

任意のサブスクリプションが単一のリソースまたはリソースのリストのいずれかのサブスクリプションであることを理解することが重要です。この自然（資源のリストに対して、単一のリソース）は、単一のサブスクリプションの期間中に変更することはできません。特に、これはRLSesは、彼らが以前にRLMIを含むそのサブスクリプションにNOTIFYメッセージを送信した場合は、サブスクリプションのためにRLMIを含まないNOTIFYメッセージを送ってはならないことを意味します。同様に、RLSesは、彼らが以前にそうでないサブスクリプションにNOTIFYメッセージを送信した場合は、サブスクリプションのために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.

リスト表現は、必ずしも二つの理由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.

特定のサブスクリプションの最初のSUBSCRIBEメッセージを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文書を含むべき後続SUBSCRIBEメッセージの結果としてトリガ。 RLSはまた、RLSは、ポリシー制限の対象に状態を、持っている、リスト内のすべてのリソースの状態情報を含むべきです。これは、加入者が自分の状態をリフレッシュすることができ、そして失われた通知から回復します。

4.6. Subscriber Processing of NOTIFY Requests

4.6. NOTIFYリクエストのサブスクライバ処理

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.

マルチパート/関連文書のルートのXML文書の存在は、リスト内の一部またはすべてのリソースのための<リソース>要素が含まれています。各<リソース>要素は一意そのセクションが対応するリソースを識別するURIを含みます。 NOTIFYが到着したとき（トップレベルの<list>要素の「fullState」属性で示されるように）、それは完全または部分的な状態を含むことができます。完全な状態が示されている場合、受信者は、NOTIFY、体内のエンティティと、リストに関連するすべての状態を置き換えます。フル状態は、各識別されたリソースに対するNOTIFY更新情報の受信者が示されていない場合。 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].

全体的なアイデアは、通知の送信元の集中であるので、フォークは、イベントリストへのサブスクリプションではほとんど意味があります。最初のリクエストがフォークされたときにそのため、リストへの加入者は、複数のサブスクリプションをインストールすることはできません。複数の応答が受信される場合、それらはRFC 3265のセクション4.4.9に記載された技術を使用して処理されている[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.

RLSの一つの潜在的な役割は、加入者に代わって、レート制限を実行することです。このように、本明細書は、任意の特定のレート制限を強制しない、むしろ実装の裁量にそれを残します。

5. Using multipart/related to Convey Aggregate State

5.集計状態を伝えるためにマルチパート/関連を使用して

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タイプを使用しています。マルチパート/関連の構文は、[4]「MIMEマルチパート/関連コンテンツタイプ」に定義されています。

5.1. XML Syntax

5.1. XML構文

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"

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：rlmi" のelementFormDefault = "資格" のxmlns = "壷：IETF：のparams： XML：NS：rlmi」のxmlns：XS = "http://www.w3.org/2001/XMLSchema"> <XS：インポート名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "http://www.w3.org/2001/xml.xsd" /> <XS：要素名= "リスト"> <XS：complexTypeの> <XS：シーケンス> <XS：要素REF = "名前" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：要素REF = "リソース" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "URI" タイプ=」 XS：anyURIの」使用= "必須" /> <XS：属性名= "バージョン" タイプ= "XS：unsignedInt型" 使用= "必須" /> <XS：属性名は= "fullState" タイプ= "XS：ブール"属性名= "CID" タイプ= "XS：：文字列" 使用= "オプション" /> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの> </ XS = "必須" /> <XSを使用：要素> <XS：要素名= "リソース"> <XS：complexTypeの> <XS：配列> <XS：要素REF = "名前" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：要素REF = 「インスタンス」分シーケンス> <XS：：属性名= "URI" タイプ= "XS：anyURIの" 使用= "必要" /> <XS：= "0" のmaxOccurs = "無制限" /> </ XS発生anyAttributeはのprocessContents = "緩いです" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "インスタンス"> <XS：complexTypeの> <XS：配列> <XS：任意の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>

processContents = "緩い" /> </ XS：シーケンス> <XS：属性名= "ID" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名= "状態" 使用= "必要" > <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "アクティブ" /> <XS：列挙値= "保留" /> <XS：列挙値= "終了" / > </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "理由" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "CID "タイプ=" XS：文字列」使用= "オプション" /> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "名前"> <XS ：のcomplexType> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性REF = "XML：langの" 使用= "オプション" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>

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のバージョン= "1.0"> <リストのxmlns = "壷：IETF：のparams：XML：NS：rlmi" URI = "SIP：adam-friends@lists.vancouver.example.com" バージョン= "7" fullState = "真の"> <名前のXML：LANG = "EN">バディリスト</名前> <名前のXML：LANG = "FR"> LISTE D'AMIS </名前> <リソースURI =「SIP：バンクーバー@ボブ。 example.com "> <名前>ボブ・スミス</名前> <インスタンスID =" juwigmtboe "状態= "アクティブ" CID = "12345.aaa@vancouver.example.com"/> </リソース> <リソースURI =" SIP：dave@vancouver.example.com "> <名前>デイブ・ジョーンズ</名前> <インスタンスID =" hqzsuxtfyq」状態= "アクティブ" CID = "12345.aab@vancouver.example.com" /> </リソース> <リソースURI = "SIP：jim@vancouver.example.com">

<名前>ジム</名前> <インスタンスID = "oflzxqzuvg" 状態= "終了" 理由= "拒否" /> </リソース> <リソースURI = "SIP：ed@vancouver.example.com"> <名前>エド</名前> <インスタンスID = "grqhzsppxb" 状態= "保留" /> </リソース> </リスト>

5.2. List Attributes

5.2. リスト属性

The <list> element present in a list notification MUST contain three attributes.

リスト通知に存在する<リスト>要素には、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.

最初の必須<リスト>属性がリストに対応するURIを含む「URI」、です。典型的には、これは、SUBSCRIBEリクエストが送信された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 ^ 32-1に0から番号が含まれている「バージョン」、です。このバージョン番号は、サブスクリプション内で送信された最初のNOTIFYメッセージのために0でなければなりません、そしてサブスクリプション内で送信NOTIFY正確に一つの、各後続のために増加しなければなりません。

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.

第三の必須属性が「fullState」です。「fullState」属性は、NOTIFYメッセージは、リスト内のすべてのリソースの情報が含まれているかどうかを示します。それがない場合は、属性の値は、（または「1」）「真」です。それ以外の場合は、「偽」である（または「0」）。最初のサブスクリプションのためのSUBSCRIBEリクエストの受信後に送信される通知しなければならないような第1、フル状態を含まなければならないサブスクリプションに送信される通知します。

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.

最後に、<リスト>要素は、「CID」属性を含むかもしれません。存在する場合、「CID」属性がリストに含まれているリソースの集約状態の情報が含まれているマルチパート/関連ボディ内のセクションを識別します。そのような集約情報の定義は、この文書の範囲外であり、必要に応じて、パッケージごとに定義されます。 CID属性は、マルチパート、体内で対応するセクションのためのContent-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文書がルートであるため、マルチパート/関連文書のトップレベルの部品を参照する必要があります。例えば、セクション5.5を参照してください。

5.3. Resource Attributes

5.3. リソース属性

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となります。この属性が存在しなければなりません。

5.4. Name Attributes

5.4. name属性

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「LANGのxml」を含む、オプションの要素に名前を付けます。「XML：LANG」属性が存在すれば、人間が読める名前の言語を指定します。この属性が存在する場合、それは有効な言語タグを含まなければなりません。言語タグは、RFC 3066で定義されている[6]。言語タグは、ユーザにレンダリングされるべき潜在的にいくつかのname要素のかを決定するにアプリケーションを支援します。

5.5. Instance Attributes

5.5. インスタンスの属性

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].

「状態」属性は、リソースの識別されたインスタンスのサブスクリプションの状態が含まれています。この属性は、「アクティブ」のいずれかの値が含まれている「保留中」、または「終了します」。これらの値の意味は、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属性は、マルチパート、体内で対応するセクションのためのContent-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文書がルートであるため、マルチパート/関連文書のトップレベルの部品を参照する必要があります。

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.

例えば、三つの部分を含むマルチパート/関連文書を検討してください。私たちは、これらの部品A、Bにラベルを付けましょう、とC.パートAは、パートBは、関連/マルチパートタイプで、アプリケーション/ rlmi + XMLを入力して、パートCはタイプapplication / PIDF + xmlです。パートBは、今度は三つの部分を含む文書である：D、E、およびFパートDは、タイプapplication / rlmi + XMLのものであり、部品EおよびFは、タイプ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.

「CIDが」文書Aの属性の任意のは不正であろう部品D、E、又はFを参照すると、部品BまたはCのみを参照しなければなりません。同様に、任意の「CID」は違法であろう任意の他の部分を参照する部品EまたはFのみを参照しなければならない文書Dの属性。また、任意のバックエンドサブスクリプションのサブスクリプション期間は、どのような方法でメタ情報状態に伝播されないことに注意してください。

5.6. Constructing Coherent Resource State

5.6. コヒーレントリソース状態を構築

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.

リソースリストの通知の処理は、それが完全または部分的な状態が含まれているかどうかに依存します。

5.6.1. Processing Full State Notifications

5.6.1. フル状態通知の処理

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.

通知がフルの状態が含まれている場合は、「真」に設定し、<リスト>属性「fullState」で示され、通知は、テーブルを更新するために使用されます。チェックは、最初の<リスト>の「バージョン」属性は、受信したメッセージ内の属性は、ローカルのバージョン番号よりも大きいことを確認するために行われます。ない場合は、受信した文書は、任意のさらなる処理をせずに破棄されます。それ以外の場合は、リソースリストテーブルの内容は、文書の内容からフラッシュし、再作成されます。テーブルに新しい行がそれぞれ「リソース」要素のために作成されます。

5.6.2. Processing Partial State Notifications

5.6.2. 部分状態通知の処理

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.

通知は「偽」に設定<リスト>属性「fullState」で示される部分の状態を、含まれている場合は、チェックが全くリストの通知が失われていないことを確認するために行われます。ローカルのバージョン番号（<リスト>要素の「バージョン」属性）の値は、新しいドキュメントのバージョン番号と比較されます。

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だけ増加され、そして以下に記載するようにドキュメントが処理されます。

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.

ドキュメントに記載されている各リソースに、加入者は、行がそのリソースに対して存在するかどうかをチェックします。このチェックは、行に関連付けられているURIのリソース-URIの値を比較することによって行われます。リソースがテーブルに存在しない場合、行が追加され、その状態はその「リソース」要素からの情報に設定されています。リソースが存在しない場合はイベントパッケージの定義で説明したように、その状態は、その「リソース」要素からの情報に更新されます。行が更新またはその状態が今されるように作成されている場合は、「終了」、そのエントリは、いつでもテーブルから除去することができます。

6. Example

6.例

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の実装では、そのような情報を取得するためのメカニズムをSUBSCRIBE / NOTIFY 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にSUBSCRIBEメッセージを送信することによって、サブスクリプションを開始します。（RLSの我々の接触はもちろん、私たちのドメインでなければならないこと理由はありません）。我々はeventlist拡張をサポートするため、関連するアプリケーション/ 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

一口にSUBSCRIBE：adam-buddies@pres.vancouver.example.com SIP / 2.0経由：SIP / 2.0 / TCPのterminal.vancouver.example.com。ブランチ= z9hG4bKwYb6QREiCLマックス・フォワード：70：<SIP：adam-buddies@pres.vancouver.example.com>から<SIP：adam@vancouver.example.com>;タグ= ie4hbb8tコールID：cdB34qLToCの@ターミナル。 vancouver.example.comのCSeq：322723822連絡先をSUBSCRIBE：<SIP：terminal.vancouver.example.com>イベント：存在が有効期限：7200はサポートされている：eventlistは受け入れ：アプリケーション/ PIDF + XMLを受け入れる：アプリケーション/ rlmi + xmlのは受け入れ：関連/マルチパート受け入れ：マルチパート/受け入れる署名：アプリケーション/ 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.

2.ローカルRLSはSUBSCRIBEトランザクションを完了します。認証と承認は、通常のコールフローでは、この時点で場所を取ることに注意してください。これらの手順は、簡潔にするために省略されています。

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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCP terminal.vancouver.example.com。ブランチ= z9hG4bKwYb6QREiCLへ：<SIP：adam-buddies@pres.vancouver.example.com>;タグ= zpNctbZqから：<SIP：adam@vancouver.example.com>;タグ= ie4hbb8tコールID：cdB34qLToC@terminal.vancouver .example.comとのCSeq：322723822連絡先をSUBSCRIBE：<SIP：pres.vancouver.example.com>は有効期限：7200が必要：eventlistのコンテンツ長：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.

RFC 3265によって必要とされる3 [2]、RLSは、サブスクリプションを受け付けるとすぐにNOTIFY送信します。この例では、ローカル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"

--50UBfW7LSCVLtggUPe5zコンテンツ転送 - エンコード：バイナリコンテンツID：<nXYxAE@pres.vancouver.example.com>のContent-Type：アプリケーション/ 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のバージョン= "1.0" エンコード= "UTF-8"> <リストのxmlns = "壷：IETF：のparams：XML：NS：rlmi" URI =「SIP：adam-friends@pres.vancouver.example.com "バージョン=" 1" fullState = "真"> <名前のXML：LANG = "EN">バディリストCOMで</名前> <名前のXML：LANG = "ド"> LISTEデルFreunde COM </名前> <リソースURI = "SIP：bob@vancouver.example.com" "> <名前>ボブ・スミス</名前> <インスタンスID =" juwigmtboe」状態= "アクティブ" CID = "bUZBsM@pres.vancouver.example.com" /> </リソース> <リソースURI = "SIP：dave@vancouver.example.com"> <名前>デーブ・ジョーンズ</名前> <インスタンスID = "hqzsuxtfyq" 状態= "アクティブ" CID = "ZvSvkz @ PRES。 vancouver.example.com "/> </リソース> <リソースURI =" SIP：ed@dallas.example.net "> <名前>エド・NETでの</名前> </リソース> <リソースURI =" SIP：アダム-friends@stockholm.example.org "> <名前のxml：langは=" EN "> ORG </名前> <名前のXMLでの私の友人：LANG =" ド "> Meine Freunde ORG </名前> </リソース> </リスト>

--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: <bUZBsM@pres.vancouver.example.com> Content-Type: application/pidf+xml;charset="UTF-8"

--50UBfW7LSCVLtggUPe5zコンテンツ転送 - エンコード：バイナリコンテンツID：<bUZBsM@pres.vancouver.example.com>のContent-Type：アプリケーション/ 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>

<？XMLバージョン= "1.0" エンコード= "UTF-8"> <プレゼンスのxmlns =エンティティ= "SIP：bob@vancouver.example.com" "URN：IETF：paramsは：XML：NS PIDF"> <タプルID = "sg89ae"> <状態> <基本>開く</塩基性> </状態> <コンタクト優先度= "1.0"> SIP：bob@vancouver.example.com </接触> </タプル> </プレゼンス>

--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary

--50UBfW7LSCVLtggUPe5zコンテンツ転送エンコード：バイナリ

Content-ID: <ZvSvkz@pres.vancouver.example.com> Content-Type: application/pidf+xml;charset="UTF-8"

コンテンツID：<ZvSvkz@pres.vancouver.example.com>のContent-Type：アプリケーション/ 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>

<？XMLバージョン= "1.0" エンコード= "UTF-8"> <プレゼンスのxmlns =エンティティ= "SIP：dave@vancouver.example.com" "URN：IETF：paramsは：XML：NS PIDF"> <タプルID = "slie74"> <状態>> <基本的には閉じ</塩基性> </状態> </タプル> </プレゼンス>

--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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pres.vancouver.example.com。ブランチ= z9hG4bKMgRenTETmmから：<SIP：adam-buddies@pres.vancouver.example.com>;タグ= zpNctbZqへ：<SIP：adam@vancouver.example.com>;タグ= ie4hbb8tコールID：cdB34qLToC@terminal.vancouver .example.comとのCSeq：<SIP：terminal.vancouver.example.com>のContent-Length：997935768連絡先をNOTIFY 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 SIP」のプレゼンス状態をサブスクライブすることを試みます。そのリクエストのヘッダフィールド：ローカルRLSは、リストのサブスクリプションの通知を受信する方法を知っているので、それは「eventlistサポート」が含まれます。このサブスクリプションと、端末によって送信された1間のリンケージがアプリケーションに任されているが、このメッセージは、加入者（端末）をサポートを知っているすべてのボディタイプのためのヘッダフィールドを「受け入れる」を含むことにより、いくつかの合理的な行動を示しています。ローカル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

ed@dallas.example.net SIP / 2.0経由：SIP SUBSCRIBE SIP / 2.0 / TCP pres.vancouver.example.comを。ブランチ= 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

マックス・フォワード：70：<SIP：ed@dallas.example.net>から<SIP：adam@vancouver.example.com>;タグ= aM5icQu9のCall-ID：Ugwz5ARxNw@pres.vancouver.example.comのCSeq： 870936068連絡先をSUBSCRIBE：<SIP：pres.vancouver.example.com>アイデンティティ：Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8Kアイデンティティ情報：https://vancouver.example.com/certイベント：存在が有効期限：3600サポート：eventlist受け入れ：アプリケーション/ PIDFを+ XMLは受け入れ：アプリケーション/ rlmi + xmlのは受け入れ：マルチパート/関連は受け入れ：アプリケーション/ 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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pres.vancouver.example.com。ブランチ= z9hG4bKMEyGjdG1LHへ：<SIP：ed@dallas.example.net>;タグ= e45TmHThから：<SIP：adam@vancouver.example.com>;タグ= aM5icQu9のCall-ID：Ugwz5ARxNw@pres.vancouver.example.com CSeq：870936068連絡先をSUBSCRIBE：<SIP：dallas.example.net>は有効期限：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で、サーバーが拒否するか、私たちのサブスクリプションを受け入れるための十分な認証情報を持っていないことを前提としています。初期には通知し、それゆえ、「保留」の「サブスクリプション・ステート」が含まれています。おそらく、リソースの承認を受け入れるか拒否するための責任者は、この変更が通知されます。しかし、これらのステップを簡潔にするため、このコールフローに含まれていません。

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

pres.vancouver.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / TCPのpres.dallas.example.netを。ブランチ= z9hG4bKfwpklPxmrWマックス・フォワード：70から：<SIP：ed@dallas.example.net>;タグ= e45TmHThへ：<SIP：adam@vancouver.example.com>;タグ= aM5icQu9のCall-ID：Ugwz5ARxNw PRES @。 vancouver.example.comのCSeq：1002640632連絡先をNOTIFY：<SIP：dallas.example.net>サブスクリ - 状態：保留; = 3600イベントの期限が切れる：存在が必要：eventlistのコンテンツ長：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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCPのpres.dallas.example.net。ブランチ= z9hG4bKfwpklPxmrWから：<SIP：ed@dallas.example.net>;タグ= e45TmHThへ：<SIP：adam@vancouver.example.com>;タグ= aM5icQu9のCall-ID：Ugwz5ARxNw@pres.vancouver.example.com CSeq：1002640632 NOTIFY連絡先：<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

ローカルRLS - stockholm.example.orgで> 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

一口にSUBSCRIBE：adam-friends@stockholm.example.org SIP / 2.0経由：SIP / 2.0 / TCP pres.vancouver.example.com。ブランチ= z9hG4bKFSrAF8CZFLマックス・フォワード：70：<SIP：adam-friends@stockholm.example.org>から<SIP：adam@vancouver.example.com>;タグ= 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

コールID：kBq5XhtZLN@pres.vancouver.example.comのCSeq：980774491連絡先をSUBSCRIBE：<SIP：pres.vancouver.example.com>アイデンティティ：Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8Kアイデンティティ情報：https://vancouver.example.com/certイベント：存在が有効期限：3600サポート：eventlist受け入れ：アプリケーション/ PIDF + xmlのは受け入れ：アプリケーション/ rlmi + xmlの受け入れ：マルチパート/受け入れる関連：アプリケーション/ 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.

stockholm.example.orgで10. RLSはSUBSCRIBEトランザクションを完了します。認証が正常にコールフローでは、この時点で場所を取ることに注意してください。このステップでは、簡潔にするために省略されています。

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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pres.vancouver.example.com。ブランチ= z9hG4bKFSrAF8CZFLへ：<SIP：adam-friends@stockholm.example.org>;タグ= JenZ40P3から：<SIP：adam@vancouver.example.com>;タグ=コールIDをa12eztNf：kBq5XhtZLN@pres.vancouver.example .COMのCSeq：980774491連絡先をSUBSCRIBE：<SIP：stockholm.example.org>は有効期限：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は、[14] 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"

--tuLLl3lDyPZX0GMr2YOoコンテンツ転送 - エンコード：バイナリコンテンツID：<Cvjpeo@stockholm.example.org>のContent-Type：アプリケーション/ 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>

<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <リストのxmlns = "壷：IETF：のparams：XML：NS：rlmi" URI = "SIP：adam-friends@stockholm.example.org" バージョン= "1" fullState = "真"> <名前のXML：LANG = "EN">バディリストCOMで</名前> <名前のXML：LANG = "ド"> LISTEデルFreunde COM </名前> <リソースURI = "SIP：joe@stockholm.example.org"> <名前>ジョー・トーマス</名前> <インスタンスID = "1" 状態= "アクティブ" CID = "mrEakg@stockholm.example.org" /> </リソース> <リソースURI = "SIP：mark@stockholm.example.org"> <名前>マークエドワーズ</名前> <インスタンスID = "1" 状態= "アクティブ" CID = "KKMDmv@stockholm.example.org" / > </リソース> </リスト>

--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <mrEakg@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"

--tuLLl3lDyPZX0GMr2YOoコンテンツ転送 - エンコード：バイナリコンテンツID：<mrEakg@stockholm.example.org>のContent-Type：アプリケーション/ 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>

<？XMLバージョン= "1.0" エンコード= "UTF-8"> <プレゼンスのxmlns =エンティティ= "SIP：joe@stockholm.example.org" "URN：IETF：paramsは：XML：NS PIDF"> <タプルID = "x823a4"> <状態> <基本>開く</塩基性> </状態> <コンタクト優先度= "1.0"> SIP：joe@stockholm.example.org </接触> </タプル> </プレゼンス>

--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <KKMDmv@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"

--tuLLl3lDyPZX0GMr2YOoコンテンツ転送 - エンコード：バイナリコンテンツID：<KKMDmv@stockholm.example.org>のContent-Type：アプリケーション/ 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>

<？XMLバージョン= "1.0" エンコード= "UTF-8"> <プレゼンスのxmlns =エンティティ= "SIP：mark@stockholm.example.org" "URN：IETF：paramsは：XML：NS PIDF"> <タプルID = "z98075"> <状態>> <基本的には閉じ</塩基性> </状態> </タプル> </プレゼンス>

--tuLLl3lDyPZX0GMr2YOo--

--l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: <K9LB7k@stockholm.example.org> Content-Type: application/pkcs7-signature

--l3WMZaaL8NpQWGnQ4mlUコンテンツ転送エンコード：バイナリコンテンツID：<K9LB7k@stockholm.example.org>コンテンツタイプ：アプリケーション/ PKCS7署名

[PKCS #7 signature here]

[ここでPKCS＃7署名]

--l3WMZaaL8NpQWGnQ4mlU--

12. The Local RLS completes the NOTIFY transaction.

12.ローカルRLSは、NOTIFYトランザクションを完了します。

Local RLS -> RLS in stockholm.example.org

ローカルRLS - stockholm.example.orgで> 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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCPのpres.stockholm.example.org。ブランチ= z9hG4bKmGL1nyZfQIから：<SIP：adam-friends@stockholm.example.org>;タグ= JenZ40P3へ：<SIP：adam@vancouver.example.com>;タグ=コールIDをa12eztNf：kBq5XhtZLN@pres.vancouver.example .COMのCSeq：<SIP：pres.vancouver.example.com>のContent-Length：294444656連絡先をNOTIFY 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ではなく、部分的に通知を送信することを決定します。「偽」に「fullState」パラメータを設定することによって示されるようにRLMI文書は、更新されたリソースの情報のみが含まれています。 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"

--TfZxoxgAvLqgj4wRWPDLコンテンツ転送 - エンコード：バイナリコンテンツID：<2BEI83@pres.vancouver.example.com>のContent-Type：アプリケーション/ 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>

<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <リストのxmlns = "壷：IETF：のparams：XML：NS：rlmi" URI =「SIP：adam-friends@pres.vancouver.example.com "バージョン=" 2" fullState = "偽"> <名前のXML：LANG = "EN">バディリストCOMで</名前> <名前のXML：LANG = "ド"> LISTEデルFreunde COM </名前> <リソースURI = "SIP：ed@dallas.example.net"> <名前> NETでエド</名前> <インスタンスID = "sdlkmeopdf" 状態= "保留" /> </リソース> <リソースURI =「SIP： adam-friends@stockholm.example.org "> <名前のxml：langは=" EN "> ORG </名前> <名前のXMLでの私の友人：LANG =" ド "> Meine Freunde ORG </名前> <インスタンスID = "cmpqweitlp" 状態= "アクティブ" CID = "1KQhyE@pres.vancouver.example.com" /> </リソース> </リスト>

   --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">

--tuLLl3lDyPZX0GMr2YOoコンテンツ転送エンコード：バイナリコンテンツID：<Cvjpeo@stockholm.example.org>コンテンツタイプ：アプリケーション/ rlmi + xmlの;のcharset = "UTF-8" <XMLバージョン= "1.0" エンコード= "UTF-8"> <リストのxmlns = "壷：IETF：のparams：XML：NS：rlmi"？URI = "SIP：adam-friends@stockholm.example.org" バージョン= "1" fullState = "真"> <名前のXML：LANG = "EN">バディリストORGでの</名前> <名前のXML：LANG = "ド"> LISTEデルFreunde ORG </名前> <リソースURI =「SIP：joe@stockholm.example。 ORG "> <名前>ジョー・トーマス</名前> <インスタンスID =" 1" の状態= "アクティブ" CID = "mrEakg@stockholm.example.org" /> </リソース> <リソースURI =「SIP：マーク@ stockholm.example.org ">

<name>Mark Edwards</name> <instance id="1" state="active" cid="KKMDmv@stockholm.example.org"/> </resource> </list>

<名前>マークエドワーズ</名前> <インスタンスID = "1" 状態= "アクティブ" CID = "KKMDmv@stockholm.example.org" /> </リソース> </リスト>

--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <mrEakg@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"

--tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <KKMDmv@stockholm.example.org> Content-Type: application/pidf+xml;charset="UTF-8"

--l3WMZaaL8NpQWGnQ4mlU Content-Transfer-Encoding: binary Content-ID: <K9LB7k@stockholm.example.org> Content-Type: application/pkcs7-signature

--l3WMZaaL8NpQWGnQ4mlUコンテンツ転送エンコード：バイナリコンテンツID：<K9LB7k@stockholm.example.org>コンテンツタイプ：アプリケーション/ PKCS7署名

[PKCS #7 signature here]

[ここでPKCS＃7署名]

--l3WMZaaL8NpQWGnQ4mlU--

--TfZxoxgAvLqgj4wRWPDL--

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

SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pres.vancouver.example.com。ブランチ= z9hG4bK4EPlfSFQK1から：<SIP：adam-buddies@pres.vancouver.example.com>;タグ= zpNctbZqへ：<SIP：adam@vancouver.example.com>;タグ= ie4hbb8tコールID：cdB34qLToC@terminal.vancouver .example.comとのCSeq：<SIP：terminal.vancouver.example.com>のContent-Length：997935769連絡先をNOTIFY 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は、認証サービスとして作用する能力を持っています。認証サービスの役割は、「セッション開始プロトコル（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は、加入者を認証し、その認証されたユーザの代わりに行うバックエンドサブスクリプションのすべてにおいて「同一性」ヘッダフィールドを含みます。この「アイデンティティ」ヘッダフィールドは、暗号要求が「差出人」ヘッダフィールドに示されたユーザーに代わって行うことが許可されたと主張しています。

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.

要求を認証する機能は、ネットワークの適切な機能の中心となるので、[7]で定義されるように、リソースリスト内のリソースに関する情報を取得するSIPバックエンドサブスクリプションを使用する任意のRLSは、認証サービスとして動作できなければなりません、ローカル管理ポリシーがそれがそうすることを可能にすることを条件とします。

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実装は、認証サービスとして動作するように構成することができる能力を含まなければなりません。任意の管理者は、このような機能を有効にすることを選択したかどうかは完全に彼ら次第です。もちろん、IDサーバとして作用する能力を欠いているので、それがユーザーとは異なるドメインにあったかのように効果的に機能していることから、次のセクションで説明したように振る舞います設定された任意の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認証されたアイデンティティの拡張子は、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.

一般的なソリューションが開発されるまでは、その代理として、彼らはバックエンドサブスクリプションを作成するには、加入者とは異なるドメインにある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」属性に示されたものになります。直接リソースに加入することは一般的に、より完全な状態情報を受信するためにそれらを認可する場所を、取るために利用者の適切な認証を行うことができます。そのような直接的なサブスクリプションを実行することを選択した実装ではなく、リストのサブスクリプションを介して取得したリソースに関する情報を取得したデータを使用すべきです。

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の実装では、リスト内のリソースに一つだけのバックエンドサブスクリプションを維持し、複数のユーザにそのようなサブスクリプションの結果を提示することによって、ネットワーク負荷を最小化しようと試みることができます。もちろん、そうすることは、リソースのための通知を維持する任意の許可ポリシーを回避します。承認は、多くの場合、単純なバイナリ「許可/不許可」の決定よりもはるかにであることに注意してください。サブスクライブしているユーザーのIDに応じて、リソースの状態 - とさえ競合 - リソースは非常に異なっをレンダリングすることがあります。

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.

これを正しく解決するために非常に難しい問題であることに注意してください。でも、そのようなアクセスが可能と考えられている場合に、この動作モードは推奨されません。

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ボディのいずれかのセクションには、必要に応じて署名および/または暗号化されてもよいということを覚えておいてください。リソースリストサーバは、彼らがどのバックエンドサブスクリプションから受けるいかなる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バックエンドサブスクリプションおよび「アプリケーション/ PKCS7-MIME」コンテンツタイプをサポートするための指示に沿って渡す必要がSUBSCRIBEメッセージ。（加入者のポリシーは署名が必要ですが、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による暗号化と署名の実際の実装が署名および/または暗号化された体を通過できるようにする必要はないことに留意されたいです。

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. 新しいSIPオプションタグ：eventlist

This section defines a new option tag for the registry established by Section 27.1 of RFC 3261[1].

このセクションでは、RFC 3261のセクション27.1 [1]によって確立されたレジストリのための新しいオプションタグを定義します。

Option Tag Name: eventlist

オプションタグ名：eventlist

Description: Extension to allow subscriptions to lists of resources.

説明：リソースのリストにサブスクリプションを許可する拡張。

Published specification: RFC 4662

公開された仕様：RFC 4662

8.2. New MIME type for Resource List Meta-Information

8.2. リソースリストメタ情報のための新しいMIMEタイプ

MIME Media Type Name: application

MIMEメディアタイプ名：アプリケーション

MIME subtype name: rlmi+xml

MIMEサブタイプ名：rlmi + xmlの

Required parameters: None

必須パラメータ：なし

Optional parameters: 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

エンコードの考慮事項：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.

セキュリティの考慮事項：このMIMEタイプの用途に固有のセキュリティに関する注意事項は、RFC 4662 RFC 1874 [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.

相互運用性に関する注意事項：このMIMEボディの使用は、一般的に、相互運用可能であることを意図しています。いいえユニークな考慮事項が確認されていません。

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.

追加情報：マジックナンバー（S）：なし。拡張（複数可）ファイル：なし。 Macintoshのファイルタイプコード（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メール：adam@estacado.net著者/変更コントローラ：このMIMEタイプの仕様はSIMPLEワーキンググループの成果物であるとアダムローチ、ジョナサン・ローゼンバーグ、によって作成されましたそしてベン・キャンベル。 IETFは、その仕様に対する制御を変更しています。

8.3. URN Sub-Namespace

8.3. URNサブ名前空間

URI: urn:ietf:params:xml:ns:rlmi

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.

説明：これは、このようなサブスクリプションは、単一のSIPサブスクリプション内で凝集している場合にサブスクリプションに関する情報を記述するためにRFC 4662によって定義された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メール：adam@estacado.net著者/変更コントローラ：このMIMEタイプの仕様はSIMPLEワーキンググループの成果物であるとアダムローチ、ジョナサン・ローゼンバーグ、そしてベン・キャンベルによって作成されました。 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

！XML：BEGIN <？xmlのバージョン= "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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = UTF-8" /> <タイトル> SIPイベントリソースリストメタ情報</タイトルの名前空間> </ HEAD> <BODY> <H1> SIPイベントリソースリストメタ情報のための名前空間</ H1> <H2>アプリケーション/ rlmi + xmlの</ H2> <P> <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]"> RFC4662 </a>を参照してください。</ P> </ボディ> </ HTML> END

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.

彼らの慎重の口コミこのドキュメントに関するコメントについてもヒシャムKhartabil、ポールKyzivat、キース糖剤、およびロバート・スパークスに感謝します。

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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[2]ローチ、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[4]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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]ピーターソン、J.とC.ジェニングスを、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、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.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。

[9] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.

[9]バーガー、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]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、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.、 "/セキュア多目的インターネットメール拡張（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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。

[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[15]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。

Authors' Addresses

著者のアドレス

Adam Roach Estacado Systems US

アダムローチEstacadoシステムズ米国

EMail: adam@estacado.net

メールアドレス：adam@estacado.net

Ben Campbell Estacado Systems US

ベン・キャンベルEstacadoシステムズ米国

EMail: ben@estacado.net

メールアドレス：ben@estacado.net

Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US

ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、ニュージャージー州07054から2711米

EMail: jdrosen@cisco.com

メールアドレス：jdrosen@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。