Network Working Group G. Camarillo
Request for Comments: 5362 Ericsson
Category: Standards Track October 2008
The Session Initiation Protocol (SIP) Pending Additions Event Package
セッション開始プロトコル（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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list.
この文書では、SIP保留中の追加イベントパッケージを定義します。このイベントパッケージは、リソースリストに追加するエントリの同意関連の状態についてユーザエージェントに知らせるためにSIPリレーで使用されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of Operation ...........................................3
4. XML Schema Definition ...........................................3
5. Pending Additions Event Package Definition ......................5
5.1. Event Package Name .........................................5
5.1.1. Event Package Parameters ............................5
5.1.2. SUBSCRIBE Bodies ....................................5
5.1.3. Subscription Duration ...............................5
5.1.4. NOTIFY Bodies .......................................5
5.1.5. Notifier Processing of SUBSCRIBE Requests ...........6
5.1.6. Notifier Generation of NOTIFY Requests ..............6
5.1.7. Subscriber Processing of NOTIFY Requests ............6
5.1.8. Handling of Forked Requests .........................7
5.1.9. Rate of Notifications ...............................7
5.1.10. State Agents .......................................7
5.1.11. Example ............................................7
6. Partial Notifications ...........................................8
6.1. Generation of Partial Notifications ........................8
6.2. Processing of Partial Notifications ........................9
6.3. XML Schema for Partial Notifications .......................9
6.4. Examples ..................................................11
7. IANA Considerations ............................................11
7.1. SIP Event Package Registration ............................11
7.2. URN Sub-Namespace Registration: consent-status ............12
7.3. XML Schema Registration: consent-status ...................12
7.4. XML Schema Registration: resource-lists ...................13
7.5. MIME Type Registration:
application/resource-lists-diff+xml .......................13
8. Security Considerations ........................................14
9. Acknowledgments ................................................14
10. Normative References ..........................................14
The framework for consent-based communications in SIP [RFC5360] identifies the need for users manipulating the translation logic at a relay (e.g., adding a new recipient) to be informed about the consent-related status of the recipients of a given translation. That is, the user manipulating the translation logic needs to know which recipients have given the relay permission to send them SIP requests.
SIP [RFC5360]に同意ベースの通信のためのフレームワークは、リレーに変換ロジックを操作するユーザーのための必要性を識別し（例えば、新しい受信者を追加する）指定された翻訳の受信者の同意に関連する状態について通知することができます。これは、変換ロジックを操作するユーザーは、受信者が彼らにSIPリクエストを送信するための中継許可を与えているかを知る必要があり、です。
This document defines a SIP event package whereby user agents can subscribe to the consent-related state of the resources that are being added to a resource list that defines a translation.
この文書では、ユーザエージェントが翻訳を定義するリソースリストに追加されているリソースの同意に関連した状態に加入することができるSIPイベントパッケージを定義します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs (i.e., recipient URIs), and delivers the request to those URIs.
リレー：任意のSIPサーバ、それはプロキシ、B2BUA（バックツーバックユーザエージェント）を、または要求を受けたいくつかのハイブリッド、あること、一つ以上のネクストホップのURI（すなわち、受信者のURI）にその要求URIを変換、およびそれらのURIにリクエストを提供します。
A user agent subscribes to a relay using the Pending Additions event package. NOTIFY requests within this event package can carry an XML document in the "application/resource-lists+xml" format [RFC4826] or in the "application/resource-lists-diff+xml" format, which is based on XML patch operations [RFC5261].
ユーザーエージェントは、保留中の追加イベントパッケージを使用してリレーにサブスクライブします。 「アプリケーション/リソース・リスト+ XML」形式[RFC4826]またはXMLパッチの操作に基づいて、「アプリケーション/リソース・リスト・デフ+ XML」フォーマットでXML文書を運ぶことができ、このイベントパッケージ内に要求をNOTIFY [ RFC5261]。
A document in the "application/resource-lists+xml" format provides the user agent with the whole list of resources being added to a resource list along with the consent-related status of those resources. A document in the "application/resource-lists-diff+xml" format provides the user agent with the changes the list of resources being added has experimented with since the last notification sent to the user agent.
「アプリケーション/リソース・リスト+ xmlの」中の文書フォーマットは、それらのリソースの同意に関連した状況と一緒にリソースリストに追加されたリソースのリスト全体でユーザーエージェントを提供します。 「アプリケーション/リソース・リスト・デフ+ xml」でフォーマットが追加されているリソースのリストは、ユーザエージェントに送信された最後の通知以降で実験した変更でユーザーエージェントを提供してドキュメント。
This section defines the <consent-status> element, which provides consent-related information about a resource to be added to a relay's translation logic.
このセクションでは、リレーの変換ロジックに追加されるリソースに関する同意関連情報を提供し、<同意ステータス>要素を定義します。
A consent-status document is an XML document that MUST be well-formed and SHOULD be valid. Consent-status documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying consent-status documents. The namespace URI for elements defined for this purpose is a URN, using the namespace identifier 'ietf'. This URN is:
同意ステータス文書は整形式でなければなりませんし、有効である必要があり、XML文書です。同意ステータス文書は、XML 1.0に基づいていなければならないとUTF-8を使用してエンコードされなければなりません。この仕様は同意ステータス文書を識別するためのXML名前空間を使用しています。この目的のために定義された要素の名前空間URIは、名前空間識別子「IETF」を使用して、URNです。このURNは以下のとおりです。
urn:ietf:params:xml:ns:consent-status
URN：IETF：のparams：XML：NS：同意ステータス
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:consent-status" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ietf:params:xml:ns:consent-status"> <xs:element name="consent-status"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="pending"/> <xs:enumeration value="waiting"/> <xs:enumeration value="error"/> <xs:enumeration value="denied"/> <xs:enumeration value="granted"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:schema>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：同意-状態" のelementFormDefault = "資格" attributeFormDefault = "非修飾" のxmlns： XS = "http://www.w3.org/2001/XMLSchema" のxmlns：TNS = "壷：IETF：のparams：XML：NS：同意-状態"> <XS：要素名= "同意-状態"> < XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "保留" /> <XS：列挙値= "待機" /> <XS：列挙値= "エラー" /> < XS：列挙値= "拒否" /> <XS：列挙値= "許可された" /> </ XS：制限> </ XS：単純> </ XS：要素> </ XS：スキーマ>
The <consent-status> element can take on the following values:
<同意ステータス>要素は、以下の値を取ることができます。
Pending: the relay has received a request to add a resource to its translation logic and will ask for permission to do so.
保留中：リレーはその翻訳ロジックにリソースを追加すると、そうする許可を求めます要求を受信しました。
Waiting: the relay has requested permission to add the resource to its translation logic but has not gotten any answer from the resource yet.
待機中：リレーはその翻訳ロジックにリソースを追加する権限を要求しましたが、まだリソースから任意の答えを得ていません。
Error: the relay has requested permission to add the resource to its translation logic and has received an error response (e.g., a SIP error response to the MESSAGE request sent to request permission). That is, the permission document requesting permission could not be delivered to the resource.
エラー：リレーはその翻訳ロジックにリソースを追加する権限を要求していると、エラー応答を受信している（例えば、許可を要求するために送信されたメッセージの要求に対するSIPエラー応答）。それは許可を要求許可文書がリソースに配信することができませんでした、です。
Denied: the resource has denied the relay permission to add the resource to the relay's translation logic.
拒否されました：リソースは、リレーの変換ロジックにリソースを追加するための中継権を否定しています。
Granted: the resource has granted the relay permission to add the resource to the relay's translation logic.
確かに：リソースは、リレーの変換ロジックにリソースを追加するための中継許可を与えています。
Section 5.1.11 contains an example of an "application/resource-lists+xml" document that carries consent-related state information using <consent-status> elements.
セクション5.1.11は、<同意ステータス>要素を使用して同意に関連する状態情報を運ぶ「アプリケーション/リソース・リスト+ xml」で文書の例が含まれています。
This section provides the details for defining a SIP [RFC3261] event notification package, as specified by [RFC3265]. Support for this section (i.e., Section 5) is REQUIRED for implementations of this specification. Support for partial notifications is optional, but if a subscriber signals support for partial notifications, Section 6 MUST be implemented.
このセクションでは、[RFC3265]で指定されるように、SIP [RFC3261]イベント通知パッケージを定義するための詳細を提供します。このセクション（すなわち、セクション5）のサポートは、この仕様の実装のために必要とされます。部分的通知のサポートはオプションであるが、加入者信号が部分的通知をサポートしている場合、セクション6を実装する必要があります。
The name of this event package is "consent-pending-additions". This package name is carried in the Event and Allow-Events header, as defined in [RFC3265].
このイベントパッケージの名前は、「同意-保留の追加」です。このパッケージ名は、イベントに運ばれ、[RFC3265]で定義されるように、ヘッダイベントが許可されています。
This package does not define any event package parameters.
このパッケージには、任意のイベントパッケージのパラメータを定義しません。
A SUBSCRIBE for Pending Additions events MAY contain a body. This body would serve the purpose of filtering the subscription. Filter documents are not specified in this document and, at the time of writing, they are expected to be the subject of future standardization activity.
保留中の追加イベントは、本体を含むかもしれためSUBSCRIBE。このボディは、サブスクリプションをフィルタリングする目的を果たすでしょう。フィルタの文書は、この文書で指定されていないと、執筆の時点で、彼らは将来の標準化活動の対象となることが期待されています。
A SUBSCRIBE for the Pending Additions event package MAY be sent without a body. This implies that the default session policy filtering policy has been requested. The default policy is that notifications are generated every time there is any change in the state of a resource in the list.
保留中の追加イベントパッケージに加入体なしで送信されるかもしれません。これがデフォルトのセッションポリシーフィルタリングポリシーが要求されていることを意味します。デフォルトのポリシーでは、通知は、リスト内のリソースの状態に変更があるたびに生成されていることです。
The default expiration time for a subscription is one hour (3600 seconds).
サブスクリプションのデフォルトの有効期限は1時間（3600秒）です。
In this event package, the body of the notifications contains a resource list document. This document describes the resources being added as recipients to a translation operation. All subscribers and notifiers MUST support the "application/resource-lists+xml" data format [RFC4826] and its extension to carry consent-related state information, which is specified in Section 4. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/resource-lists+xml". If the header field is present, it MUST include "application/resource-lists+xml", and MAY include any other types capable of representing consent-related state.
このイベントパッケージでは、通知の本体は、リソースリストドキュメントが含まれています。この文書では、翻訳作業に受信者として追加されているリソースについて説明します。すべてのサブスクライバとノーティファイアはSUBSCRIBEリクエストが受け入れヘッダーフィールドを含むかもしれセクション4で指定された同意に関連する状態情報を運ぶために[RFC4826]「アプリケーション/リソース・リスト+ XML」のデータ形式をサポートし、その拡張しなければなりません。このようなヘッダフィールドが存在しない場合、それは「アプリケーション/リソース・リスト+ XML」のデフォルト値を有しています。ヘッダフィールドが存在する場合、それは「+ XMLアプリケーション/リソース・リスト」を含まなければなりません、と同意に関連する状態を表すことができる任意の他のタイプを含むかもしれません。
Additionally, all subscribers and notifiers SHOULD support the "application/resource-lists-diff+xml" format. Section 6 discusses the usage of the Pending Additions event package with this format.
また、すべての加入者及び届出者は、「アプリケーション/リソース・リスト・デフ+ XML」フォーマットをサポートする必要があります。第6節は、この形式を持つ保留中の追加イベントパッケージの使用方法について説明します。
The state of the resources to be added to a relay's translation logic can reveal sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. Authorization policy is at the discretion of the administrator.
リレーの変換ロジックに追加するリソースの状態は、機密情報を明らかにすることができます。したがって、すべてのサブスクリプションは、認証され、その後、承認前に承認されるべきです。認可ポリシーは、管理者の裁量です。
A notifier for the Pending Additions event package SHOULD include the <consent-status> element, which is defined in Section 4. The <consent-status> element MUST be positioned as an instance of the <any> element within the <entry> element.
保留中の追加イベントパッケージの通知は、<同意ステータス>要素は、<entry>要素内の<任意>要素のインスタンスとして配置されなければならない第4項に定義されている<同意ステータス>要素を含むべきです。
Notifications SHOULD be generated for the Pending Additions package whenever there is a change in the consent-related state of a resource. When a resource moves to the error, denied, or granted states, and once a NOTIFY request is sent, the resource is removed from further notifications.
リソースの同意に関連した状態に変化があるたびに通知が保留中の追加パッケージのために生成する必要があります。リソースがエラーに移動すると、拒否された、または状態を付与し、NOTIFYリクエストが送信された後、リソースがさらに通知から削除されます。
As stated in Section 3, a document in the "application/resource-lists+xml" format provides the subscriber with the whole list of resources being added to a resource list along with the consent-related status of those resources. On receiving a NOTIFY request with such a document, the subscriber SHOULD update its local information about the resources being added to the resource list with the information in the document. NOTIFY requests contain full state. The subscriber does not need to perform any type of information aggregation. Section 6 discusses the use of the Pending Additions event package with partial notifications.
第3節で述べたように、「アプリケーション/リソース・リスト+ xmlの」中の文書フォーマットは、それらのリソースの同意に関連した状況と一緒にリソースリストに追加されたリソースのリスト全体で加入者に提供します。そのような文書とNOTIFYリクエストを受信すると、加入者は、文書内の情報をリソースリストに追加されるリソースに関するローカル情報を更新する必要があります。リクエストがフルの状態が含まれているNOTIFY。加入者は、情報の集約のいずれかのタイプを実行する必要はありません。第6節は、部分的な通知で保留中の追加イベントパッケージの使用について説明します。
The state of a given resource list is normally handled by a server and stored in a repository. Therefore, there is usually a single place where the resource-list state is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to pending additions information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of [RFC3265].
所与のリソースリストの状態は、通常、サーバーによって処理され、リポジトリに格納されます。したがって、リソース・リストの状態が常駐して、単一の場所が通常あります。これは、この情報のためにサブスクリプションが容易このリポジトリへのアクセスを単一の要素によって処理されることを意味します。フォークへの追加情報を保留にサブスクリプションのための説得力の必要性は、それゆえ、ありません。その結果、加入者は、単一のサブスクリプション要求の結果として、複数のダイアログを作成してはいけません。唯一つのダイアログが確立されることを保証するために必要な処理は、[RFC3265]のセクション4.4.9に記載されています。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server does not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
輻輳制御の理由から、通知の割合が過大にならないことが重要です。その結果、サーバはより速く回5秒以上の速度で単一の加入者のための通知を生成しないことが推奨されます。
State agents have no role in the handling of this package.
状態エージェントは、このパッケージの取り扱いに何の役割を持っていません。
The following is an example of an "application/resource-lists+xml" document that carries consent-related state information using <consent-status> elements:
下記の<同意ステータス>要素を使用して同意に関連する状態情報を運ぶ「アプリケーション/リソース・リスト+ XML」のドキュメントの一例です。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cs="urn:ietf:params:xml:ns:consent-status"> <list> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>pending</cs:consent-status> </entry> <entry uri="sip:joe@example.com"> <display-name>Joe Smith</display-name> <cs:consent-status>pending</cs:consent-status> </entry> <entry uri="sip:nancy@example.com"> <display-name>Nancy Gross</display-name> <cs:consent-status>granted</cs:consent-status> </entry> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CS = "壷：IETF：のparams：XML ：NS：同意-状態 "> <リスト> <エントリURI =" SIP：bill@example.com "> <表示名>ビル・ドウ</表示名> <CS：同意ステータス>保留</ CS：同意ステータス> </ entry>の<エントリーのURI = "SIP：joe@example.com"> <表示名>ジョー・スミス</表示名> <CS：同意ステータス>保留</ CS：同意ステータス> </ entry>の<エントリーのURI = "SIP：nancy@example.com"> <表示名>ナンシーグロス</表示名> <CS：同意-状態> </ CS付与：同意-状態> </エントリ> </リスト> </資源リスト>
The lists of resources reported by this event package may contain many resources. When the "application/resource-lists+xml" format is used and there is a change in the consent-related status of a resource, the server generates a notification with the whole list. Generating large notifications to report small changes does not meet the efficiency requirements of some bandwidth-constrained environments. The partial notifications mechanism specified in this section is a more efficient way to report changes in the status of resources.
このイベントパッケージによって報告されたリソースのリストは、多くのリソースが含まれていてもよいです。 「アプリケーション/リソース・リスト+ xml」でフォーマットを使用して、リソースの同意に関連した状態に変更があると、サーバーは、リスト全体で通知を生成します。いくつかの帯域幅に制約のある環境での効率要件を満たしていない小さな変更を報告するために大規模な通知を生成します。このセクションで指定された部分の通知メカニズムは、リソースの状態の変化を報告するために、より効率的な方法です。
Subscribers signal support for partial notifications by including the "application/resource-lists-diff+xml" format in the Accept header field of the SUBSCRIBE requests they generate. If a client subscribing to the Pending Additions event package generates an Accept header field that includes the MIME type "application/resource-lists-diff+xml", the server has the option of returning documents in this format (instead of in the "application/resource-lists+xml" format).
加入者は、彼らが発生するSUBSCRIBEリクエストのAcceptヘッダーフィールドに「アプリケーション/リソース・リスト・デフ+ XML」フォーマットを含むことにより、部分的に通知のサポートを知らせます。保留中の追加イベントパッケージに加入するクライアントは、MIMEタイプ「アプリケーション/リソース・リスト・デフ+ XML」が含まれるAcceptヘッダーフィールドを生成した場合、サーバーは、この形式で文書を返す（代わりに「アプリケーションでのオプションがあります/リソース・リスト+ xmlの」形式）。
Once a subscription is accepted and installed, the server MUST deliver full state in its first notification. To report full state, the server uses the regular format for resource lists. Consequently, the server MUST set the Content-Type header field to the value 'application/resource-lists+xml'.
サブスクリプションが受け入れられ、インストールされると、サーバはその最初の通知で満杯状態を提供しなければなりません。完全な状態を報告するには、サーバーはリソースリストのための定期的なフォーマットを使用しています。その結果、サーバは「+ xmlのアプリケーション/リソース・リスト」値にContent-Typeヘッダフィールドを設定しなければなりません。
In order to deliver a partial notification, the server MUST set the Content-Type header field to the value 'application/resource-lists-diff+xml'. When the server generates a partial notification, the server SHOULD only include the information that has changed since the previous notification. It is up to the server's local policy to determine what is considered as a change to the previous state.
部分的な通知を提供するために、サーバは、値「アプリケーション/リソース・リスト・デフ+ XML」にContent-Typeヘッダフィールドを設定しなければなりません。サーバは部分的通知を生成するとき、サーバは、前の通知以降に変更された情報を含むべきです。これは、以前の状態への変化と考えられているかを決定するために、サーバのローカルポリシー次第です。
The server MUST construct partial notifications according to the following logic: all information that has been added to the document is listed inside <add> elements, all information that has been removed from the document is listed inside <remove> elements, and all information that has been changed is listed under <replace> elements.
サーバは、次のロジックに従って、部分的通知を構築しなければならない：内部記載されている文書に追加されたすべての情報を、内部記載されている文書から除去されたすべての情報要素を<追加>要素<削除>、およびすべての情報、その<置き換え>要素の下に表示されて変更されました。
The server MUST NOT send a new NOTIFY request with a partial notification until it has received a final response from the subscriber for the previous one or the previous NOTIFY request has timed out.
それがタイムアウトした前の1またはNOTIFY前の要求のための加入者からの最終的な応答を受信するまで、サーバーは、部分的な通知で新しいNOTIFYリクエストを送ってはいけません。
When the server receives a SUBSCRIBE request (refresh or termination) within the associated subscription, it SHOULD send a NOTIFY request containing the full document using the 'application/resource-lists+xml' content type.
サーバーは、関連するサブスクリプション内SUBSCRIBEリクエスト（リフレッシュまたは終了）を受信すると、それは '+ xmlのアプリケーション/リソース・リストのコンテンツタイプを使用して、完全なドキュメントを含むNOTIFYリクエストを送るべきです。
If the server has used a content type other than 'application/resource-lists+xml' in notifications within the existing subscription and changes to deliver partial notifications, the server MUST deliver full state using the 'application/resource-lists+xml' content type before generating its first partial notification.
サーバーは、既存のサブスクリプションと部分的通知を配信するために、変更内の通知で「アプリケーション/リソース・リストは+ xmlの」以外のコンテンツタイプを使用している場合、サーバは、「アプリケーション/リソース・リスト+ xmlの」コンテンツを使用して完全な状態を提供しなければなりませんその第1の部分の通知を生成する前に入力します。
When a subscriber receives the first notification containing full state in a 'application/resource-lists+xml' MIME body, the subscriber MUST store the received full document as its local copy.
加入者が「+ xmlのアプリケーション/リソース・リスト」MIME本体に完全な状態を含む第一の通知を受信すると、加入者は、ローカルコピーとして受信完全ドキュメントを格納しなければなりません。
When the subscriber receives a subsequent notification, the subscriber MUST modify its locally stored information according to the following logic:
加入者がその後の通知を受信すると、加入者は、以下の論理に従って、そのローカルに格納された情報を変更する必要があります。
o If the notification carries an %'application/resource-lists+xml' document, the subscriber MUST replace its local copy of the document with the document received in notification.
通知は％「アプリケーション/リソース・リスト+ xmlの」文書を運ぶ場合は、O、加入者は通知で受信した文書を、文書のローカルコピーを交換する必要があります。
o If the notification carries an 'application/resource-lists-diff+xml' document, the subscriber MUST apply the changes indicated in the received 'application/resource-lists-diff+xml' document to its local copy of the full document.
通知は「アプリケーション/リソース・リスト・デフ+ XML」のドキュメントを搬送する場合は、O、加入者は、完全なドキュメントのローカルコピーを受け取った「アプリケーション/リソース・リスト・デフ+ XML」のドキュメントに示されている変更を適用しなければなりません。
If a subscriber encounters a processing error while processing an 'application/resource-lists-diff+xml' encoded document, the subscriber SHOULD renew its subscription. A subscriber can fall back to normal operations by not including the 'application/resource-lists-diff+xml' format in a new SUBSCRIBE request.
「アプリケーション/リソース・リスト・デフ+ xmlの」エンコードされた文書の処理中に加入者が処理エラーが発生した場合、加入者は、その契約を更新すべきです。加入者は、新たなSUBSCRIBEリクエストの「アプリケーション/リソース・リスト・デフ+ xmlの」形式を含めないことにより、通常の操作にフォールバックすることができます。
If the server changes the content type used in notifications within the existing subscription, the subscriber MUST discard all the previously received information and process the new content as specified for that content type.
サーバーは、既存のサブスクリプション内の通知に使用されるコンテンツの種類を変更した場合、加入者はすべて、以前に受信した情報を破棄し、そのコンテンツタイプに指定され、新たなコンテンツを処理しなければなりません。
This is the XML schema for the "application/resource-lists-diff+xml" data format. The "urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in [RFC5261].
これは、「アプリケーション/リソース・リスト・デフ+ xmlの」データ・フォーマットのXMLスキーマです。 "URN：IETF：paramsは：XML：スキーマ：XMLパッチOPS" スキーマは[RFC5261]で定義されています。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists" xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns = "壷：IETF：のparams：XML：NS ：リソース・リスト」のxmlns：XS = " "http://www.w3.org/2001/XMLSchema" のelementFormDefault =" 資格>
<!-- include patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- partial updates --> <xs:element name="resource-lists-diff"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice> <xs:element name="add"> <xs:complexType mixed="true"> <xs:complexContent> <xs:extension base="add"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="remove"> <xs:complexType> <xs:complexContent> <xs:extension base="remove"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="replace"> <xs:complexType mixed="true"> <xs:complexContent> <xs:extension base="replace"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax"/> </xs:choice> </xs:sequence> <xs:anyAttribute processContents="lax"/> </xs:element> </xs:schema>
<！ - 部分的な更新 - > <XS：要素名= "リソース・リスト・デフ"> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素名=」 "：complexTypeの混合=> <XS" 真LAX "/> </ XS：拡張> </ XS：complexContentを "> <XS：complexContentを> <XS：：拡張ベース=" "anyAttributeはのprocessContents => <XS" を追加> </ XS：complexTypeの> </ XS：要素> <XS：要素名=> <XS "削除" のcomplexType> <XS：complexContentを> <XS：拡張ベース= "削除"> <XS：anyAttributeはのprocessContents =」 LAX "/> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS：要素名=" 置き換えます " "> <XS complexTypeの混合=" 真> <XS ：complexContentを> <XS：増設ベース= "交換"> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS ：任意の名前空間= "##他" のprocessContents = "緩い" /> </ XS：選択> </ XS：シーケンス> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：要素> </ XS：スキーマ>
Section 5.1.11 contains an example of an 'application/resource-lists+xml' document, which carries full state. The following is an 'application/resource-lists-diff+xml' partial update document:
セクション5.1.11は、完全な状態を運ぶ「アプリケーション/リソース・リスト+ xmlの」文書の例が含まれています。 「アプリケーション/リソース・リスト・デフ+ xmlの」部分更新文書には、次のとおりです。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cs="urn:ietf:params:xml:ns:consent-status">
<？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <リソース・リスト・デフのxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CS = "壷：IETF：のparams ：XML：NS：同意-状態 ">
<replace sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()" >granted</replace>
<置き換えSEL = "* /リスト/エントリ[@ URI = '一口：bill@example.com'] / CS：同意ステータス/テキスト（）">許可された</交換してください>
</resource-lists-diff>
</リソース・リスト-diffを>
The following is the resulting 'application/resource-lists+xml' document after applying the partial update:
以下は、部分更新を適用した後に、ドキュメント結果「+ xmlのアプリケーション/リソース・リスト」です。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cs="urn:ietf:params:xml:ns:consent-status"> <list> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>granted</cs:consent-status> </entry> <entry uri="sip:joe@example.com"> <display-name>Joe Smith</display-name> <cs:consent-status>pending</cs:consent-status> </entry> <entry uri="sip:nancy@example.com"> <display-name>Nancy Gross</display-name> <cs:consent-status>granted</cs:consent-status> </entry> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CS = "壷：IETF：のparams：XML ：NS：同意-状態 "> <リスト> <エントリーのURI =" SIP：bill@example.com "> <表示名>ビル・ドウ</表示名> <CS：同意ステータス>付与された</ CS：同意ステータス> </ entry>の<エントリーのURI = "SIP：joe@example.com"> <表示名>ジョー・スミス</表示名> <CS：同意ステータス>保留</ CS：同意ステータス> </ entry>の<エントリーのURI = "SIP：nancy@example.com"> <表示名>ナンシーグロス</表示名> <CS：同意-状態> </ CS付与：同意-状態> </エントリ> </リスト> </資源リスト>
There are five IANA considerations associated with this specification.
この仕様に関連付けられている5つのIANAの考慮事項があります。
This specification registers a SIP event package per the procedures in [RFC3265].
この仕様は、[RFC3265]の手順ごとにSIPイベントパッケージを登録します。
Package name: consent-pending-additions
パッケージ名：同意-保留-追加
Type: package
タイプ：パッケージ
Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
連絡先：ゴンサロ・カマリロ<Gonzalo.Camarillo@ericsson.com>
Published Specification: RFC 5362.
公開された仕様：RFC 5362。
This section registers a new XML namespace per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順ごとに新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:consent-status
URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：同意ステータス
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
登録者連絡先：IETF SIPPINGワーキンググループ<sipping@ietf.org>、ゴンサロ・カマリロ<Gonzalo.Camarillo@ericsson.com>
XML:
XML：
<?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=iso-8859-1"/> <title>Pending Additions Extension Namespace</title> </head> <body> <h1>Namespace for Consent-related Status Information Extension</h1> <h2>urn:ietf:params:xml:ns:consent-status</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc5362.txt">RFC 5362 </a>.</p> </body> </html>
！<？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> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = ISO-8859同意関連のステータス情報の拡張のために-1" /> <タイトル>保留中の追加拡張名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS ：同意ステータス</ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5362.txt"> RFC 5362 </a>のを参照してください。</ P> </ボディ> </ HTML>
This section registers an XML schema per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順ごとにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:consent-status
URI：URN：IETF：のparams：XML：スキーマ：同意ステータス
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
登録者連絡先：IETF SIPPINGワーキンググループ<sipping@ietf.org>、ゴンサロ・カマリロ<Gonzalo.Camarillo@ericsson.com>
The XML for this schema can be found in Section 4.
このスキーマのためのXMLは、第4節で見つけることができます。
This section registers an XML schema per the procedures in [RFC3688]. This XML schema is an extension to the XML schema (whose ID is resource-list) defined in [RFC4826]. The IANA has added a row in the XML schema registry with the following values:
このセクションでは、[RFC3688]の手順ごとにXMLスキーマを登録します。このXMLスキーマは、（IDリソースリストである）[RFC4826]で定義されたXMLスキーマの拡張です。 IANAは、次の値を持つXMLスキーマレジストリ内の行を追加しました。
ID: resource-lists-diff URI: urn:ietf:params:xml:schema:resource-lists-diff Filename: resource-lists-diff Reference [RFC5362]
ID：リソース・リスト-diffのURI：URN：IETF：のparams：XML：スキーマ：リソース・リスト-diffのファイル名：リソース・リスト-diffのリファレンス[RFC5362]
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
登録者連絡先：IETF SIPPINGワーキンググループ<sipping@ietf.org>、ゴンサロ・カマリロ<Gonzalo.Camarillo@ericsson.com>
The XML for this schema can be found in Section 6.3.
このスキーマのためのXMLは、セクション6.3に記載されています。
This section registers the 'application/resource-lists-diff+xml' MIME type.
このセクションでは、「アプリケーション/リソース・リスト・デフ+ xmlの」MIMEタイプを登録します。
MIME media type name: application MIME subtype name: resource-lists-diff+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in [RFC3023]. Encoding considerations: Same as encoding considerations of application/xml as specified in [RFC3023]. Security considerations: See Section 10 of [RFC3023] and Section 7 of [RFC4826].
MIMEメディアタイプ名：application MIMEサブタイプ名：リソース・リスト・デフ+ xml必須パラメータ：なしオプションのパラメータ：[RFC3023]で指定されるように、application / xmlのcharsetパラメータと同じです。符号化の考慮事項：[RFC3023]で指定されたアプリケーション/ XMLの考察をコードするものと同じ。セキュリティの考慮事項：[RFC3023]のセクション10と[RFC4826]のセクション7を参照してください。
Interoperability considerations: none Published specification: RFC 5362 Applications that use this media type: This document type has been defined to support partial notifications in subscriptions to resource lists.
相互運用性に関する注意事項：なし公開された仕様：RFC 5362このメディアタイプを使用するアプリケーション：このドキュメントタイプは、リストのリソースへのサブスクリプションには、部分的通知をサポートするために定義されています。
Additional Information:
追加情報：
Magic number: none File extension: .rld Macintosh file type code: "TEXT" Personal and email address for further information: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Intended usage: COMMON Author/Change controller: The IETF
マジックナンバー：なしファイルの拡張子：.rld Macintoshのファイルタイプコード：詳細については、「TEXT」の個人と電子メールアドレス：ゴンサロ・カマリロ<Gonzalo.Camarillo@ericsson.com>意図している用法：COMMON著者/変更コントローラ：IETF
"A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)" [RFC5360] discusses security-related issues that are related to this specification.
[RFC5360「セッション開始プロトコル（SIP）に同意ベースの通信のためのフレームワーク」は、本明細書に関連するセキュリティ関連の問題を論じています。
Subscriptions to the Pending Additions event package can reveal sensitive information. For this reason, it is RECOMMENDED that relays use strong means for authentication and information confidentiality. Additionally, attackers may attempt to modify the contents of the notifications sent by a relay to its subscribers. Consequently, it is RECOMMENDED that relays use a strong means for information integrity protection.
保留中の追加イベントパッケージへのサブスクリプションは、機密情報を明らかにすることができます。このため、リレーは、認証情報の機密性のための強力な手段を使用することをお勧めします。また、攻撃者はその加入者へのリレーによって送信される通知の内容を変更しようとすることができます。したがって、リレーが情報の完全性保護のための強力な手段を使用することをお勧めします。
It is RECOMMENDED that relays authenticate subscribers using the normal SIP authentication mechanisms, such as Digest, as defined in [RFC3261].
リレーが[RFC3261]で定義されるように、このようなダイジェストなどの通常のSIPの認証メカニズムを使用して加入者を認証することが推奨されます。
The mechanism used for conveying information to subscribers SHOULD ensure the integrity and confidentially of the information. In order to achieve these, an end-to-end SIP encryption mechanism, such as S/MIME, as described in [RFC3261], SHOULD be used.
加入者に情報を伝えるために使用されるメカニズムは、情報の完全性と機密性を確保すべきです。これらを達成するために、[RFC3261]に記載されているようなS / MIMEなどのエンドツーエンドのSIP暗号化機構は、使用すべきです。
If strong end-to-end security means (such as above) is not available, it is RECOMMENDED that hop-by-hop security based on TLS and SIPS URIs, as described in [RFC3261], is used.
（上記のような）強力なエンドツーエンドのセキュリティ手段が利用可能でない場合、それはホップバイホップセキュリティTLSとSIPS URIのに基づいていることをお勧めしますが、[RFC3261]に記載されているように、使用されています。
Jonathan Rosenberg provided useful ideas on this document. Ben Campbell and Mary Barnes performed a thorough review of this document. Jari Urpalainen helped improve the partial notifications mechanism.
ジョナサンローゼンバーグは、この文書に便利なアイデアを提供しました。ベン・キャンベルとメアリー・バーンズは、このドキュメントの徹底的な見直しを行いました。ヤリUrpalainenは、部分的な通知メカニズムを改善されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261] Urpalainen、J.、 "拡張マークアップ言語（XML）パッチOperations Frameworkの利用XMLパス言語（XPath）セレクタ"、RFC 5261、2008年9月。
[RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
[RFC5360]ローゼンバーグ、J.、カマリロ、G.、およびD.ウィリス、RFC 5360、2008年11月 "セッション開始プロトコル（SIP）に同意ベースの通信のためのフレームワーク"。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。