[要約] RFC 5362は、SIPの追加イベントパッケージである「Pending Additions」に関するものです。このRFCの目的は、SIPセッションの追加が保留中であることを通知するためのイベントパッケージを定義することです。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
リレー：プロキシ、B2BUA（連続したユーザーエージェント）、またはリクエストを受信するハイブリッドのSIPサーバーは、リクエスト-URIを1つ以上の次のホップURI（つまり、レシピエントURIS）に変換します。、そしてそれらのurisにリクエストを届けます。
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パッチ操作[RFC5261]に基づく「アプリケーション/リソースリストディフXML」形式でXMLドキュメントを伝えることができます。。
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.
「Application/Resource-Lists XML」形式のドキュメントは、ユーザーエージェントに、リソースリストに追加されるリソースのリスト全体と、それらのリソースの同意関連のステータスを提供します。「Application/Resource-Lists-Diff 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.
このセクションでは、リレーの翻訳ロジックに追加されるリソースに関する同意関連の情報を提供する<COUND-STATUS>要素を定義します。
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
<?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>
The <consent-status> element can take on the following values:
<COUNTS-STATUS>要素は、次の値を引き受けることができます。
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には、<COUNTS-STATUS>要素を使用して同意関連の状態情報を伝える「アプリケーション/リソースリスト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]で定義されているように、イベントとAllow-Ieventsヘッダーに掲載されています。
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.
保留中の追加イベントのための購読には、ボディが含まれている場合があります。この本体は、サブスクリプションをフィルタリングする目的に役立ちます。フィルタードキュメントはこのドキュメントでは指定されておらず、執筆時点では、将来の標準化アクティビティの対象となることが期待されています。
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.
このイベントパッケージでは、通知の本文にはリソースリストドキュメントが含まれています。このドキュメントでは、翻訳操作の受信者として追加されているリソースについて説明しています。すべてのサブスクライバーと通知者は、「アプリケーション/リソースリストXML」データ形式[RFC4826]と、セクション4で指定されている同意関連の状態情報を伝えるための拡張機能をサポートする必要があります。購読要求には、受け入れヘッダーフィールドが含まれる場合があります。そのようなヘッダーフィールドが存在しない場合、「アプリケーション/リソースリスト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.
さらに、すべてのサブスクライバーと通知者は、「Application/Resource-Lists-Diff 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.
保留中追加のイベントパッケージの紹介者には、セクション4で定義されている<COUND-STATUS>要素を含める必要があります。<COUNTS-STATUS>要素は、<Entry>要素内の<Any>要素のインスタンスのインスタンスとして配置する必要があります。。
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.
リソースの同意関連状態に変更がある場合は、保留中の追加パッケージに通知を生成する必要があります。リソースがエラーに移動したり、拒否されたり、許可された状態に移行し、通知要求が送信されると、リソースはさらなる通知から削除されます。
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」形式のドキュメントは、サブスクライバーに、リソースリストに追加されるリソースのリスト全体とともに、それらのリソースの同意関連のステータスを提供します。このようなドキュメントで通知要求を受信すると、サブスクライバーは、ドキュメント内の情報を使用してリソースリストに追加されているリソースに関するローカル情報を更新する必要があります。通知リクエストには完全な状態が含まれています。サブスクライバーは、いかなる種類の情報集約を実行する必要もありません。セクション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秒ごとに1回よりも速いレートで単一のサブスクライバーの通知を生成しないことをお勧めします。
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:
以下は、<COUNTS-STATUS>要素を使用して同意関連の状態情報を伝える「アプリケーション/リソースリスト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>
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.
このイベントパッケージで報告されているリソースのリストには、多くのリソースが含まれている場合があります。「Application/Resource-Lists 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).
加入者は、生成するサブスクライブリクエストのAcceptヘッダーフィールドに「アプリケーション/リソースリストディフXML」形式を含めることにより、部分通知のサポートを信号します。保留中の追加の追加パッケージをサブスクライブするクライアントが、MIMEタイプの「アプリケーション/リソースリストディフXML」を含む受け入れヘッダーフィールドを生成する場合、サーバーには「アプリケーション/」の代わりにこの形式でドキュメントを返すオプションがあります。リソースリスト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」に設定する必要があります。
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.
部分的な通知を配信するには、サーバーはコンテンツタイプのヘッダーフィールドを値「Application/Resource-Lists-Diff XML」に設定する必要があります。サーバーが部分的な通知を生成する場合、サーバーは以前の通知以降に変更された情報のみを含める必要があります。以前の状態の変更と見なされるものを決定するのは、サーバーのローカルポリシー次第です。
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.
サーバーは、次のロジックに従って部分通知を構築する必要があります。ドキュメントに追加されたすべての情報は、<add>要素内にリストされています。ドキュメントから削除されたすべての情報は、<削除>要素内にリストされています。変更されたものは、<plateg>要素の下にリストされています。
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.
サーバーは、以前のものまたは以前の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.
サーバーが関連するサブスクリプション内でサブスクライブリクエスト（更新または終了）を受信した場合、「アプリケーション/リソースリスト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」コンテンツタイプを使用して完全な状態を提供する必要があります。最初の部分通知を生成します。
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.
サブスクライバーが「Application/Resource-Lists 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.
o 通知に％ 'Application/Resource-Lists XML'ドキュメントがある場合、サブスクライバーはドキュメントのローカルコピーを通知で受信したドキュメントに置き換える必要があります。
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.
o 通知に「アプリケーション/リソースリストディフXML」ドキュメントがある場合、サブスクライバーは、受信した「アプリケーション/リソースリストディフ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.
サブスクライバーが「Application/Resource-Lists-Diff XML」エンコードドキュメントを処理中に処理エラーに遭遇する場合、サブスクライバーはサブスクリプションを更新する必要があります。サブスクライバーは、新しいサブスクライブリクエストに「Application/Resource-Lists-Diff 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].
これは、「Application/Resource-Lists-Diff XML」データ形式のXMLスキーマです。「urn：ietf：params：xml：schema：xml-patch-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">
<!-- 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>
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」ドキュメントの例が含まれています。以下は、「Application/Resource-Lists-Diff 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">
<replace
sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()"
>granted</replace>
</resource-lists-diff>
</resource-lists-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>
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>
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
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <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>
This section registers an XML schema per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順ごとにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:consent-status
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <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スキーマは、[RFC4826]で定義されているXMLスキーマ（そのIDがリソースリスト）の拡張です。IANAは、XMLスキーマレジストリに次の値で行を追加しました。
ID: resource-lists-diff
URI: urn:ietf:params:xml:schema:resource-lists-diff
Filename: resource-lists-diff
Reference [RFC5362]
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <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.
このセクションでは、 'Application/Resource-Lists-Diff 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メディアタイプ名：アプリケーションMIMEサブタイプ名：Resource-Lists-Diff XML必須パラメーター：なしオプションパラメーター：[RFC3023]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。考慮事項のエンコード：[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
"A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)" [RFC5360] discusses security-related issues that are related to this specification.
「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションのフレームワーク」[RFC5360]は、この仕様に関連するセキュリティ関連の問題について説明します。
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.
強力なエンドツーエンドのセキュリティ手段（上記など）が利用できない場合は、[RFC3261]に記載されているように、TLSおよびSIPS URIに基づくホップバイホップセキュリティを使用することをお勧めします。
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.
Jonathan Rosenbergは、この文書に有用なアイデアを提供しました。ベン・キャンベルとメアリー・バーンズは、この文書の徹底的なレビューを行いました。Jari Urpalainenは、部分通知メカニズムの改善に役立ちました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] Rosenberg、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 PATH言語（XPATH）セレクターを使用した拡張可能なマークアップ言語（XML）パッチ操作フレームワーク」、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] Rosenberg、J.、Camarillo、G。、およびD. Willis、「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションのフレームワーク」、RFC 5360、2008年10月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。