Network Working Group G. Camarillo
Request for Comments: 5362 Ericsson
Category: Standards Track October 2008
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
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
中继：接收请求、将其请求URI转换为一个或多个下一跳URI（即接收方URI）并将请求传递给这些URI的任何SIP服务器，无论是代理服务器、B2BUA（背对背用户代理）还是某种混合服务器。
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].
用户代理使用挂起的添加事件包订阅中继。此事件包中的NOTIFY请求可以携带“应用程序/资源列表+XML”格式[RFC4826]或“应用程序/资源列表差异+XML”格式的XML文档，该格式基于XML修补程序操作[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”格式的文档为用户代理提供了添加到资源列表中的整个资源列表以及这些资源的同意相关状态。“应用程序/资源列表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.
本节定义了<consent 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是一个URN，使用名称空间标识符“ietf”。这个骨灰盒是：
urn:ietf:params:xml:ns:consent-status
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>
<?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:
<consent 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节包含一个“应用程序/资源列表+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.
订阅挂起的添加事件可能包含正文。该机构将用于筛选订阅。本文件未规定过滤文件，在编写本文件时，这些文件预计将成为未来标准化活动的主题。
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).
订阅的默认过期时间为一小时（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
在此事件包中，通知正文包含一个资源列表文档。本文档描述了作为收件人添加到翻译操作中的资源。所有订阅者和通知者都必须支持“应用程序/资源列表+xml”数据
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.
格式[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.
此外，所有订阅者和通知者都应该支持“应用程序/资源列表diff+xml”格式。第6节讨论了使用此格式的Pending Additions事件包的用法。
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节中定义的<同意状态>元素。<consent 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].
给定资源列表的状态通常由服务器处理并存储在存储库中。因此，资源列表状态通常位于单个位置。这意味着该信息的订阅可以由访问该存储库的单个元素轻松处理。因此，没有迫切需要订阅fork的待定添加信息。因此，订阅者不能因为一个订阅请求而创建多个对话框。[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" 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.
此事件包报告的资源列表可能包含许多资源。当使用“应用程序/资源列表+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).
订阅者通过在其生成的订阅请求的接受头字段中包含“应用程序/资源列表diff+xml”格式来表示对部分通知的支持。如果订阅Pending Additions事件包的客户端生成一个包含MIME类型“application/resource List diff+xml”的Accept标头字段，则服务器可以选择以这种格式（而不是“application/resource List+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.
为了传递部分通知，服务器必须将Content-Type头字段设置为值“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>元素中，从文档中删除的所有信息都列在<remove>元素中，所有已更改的信息都列在<replace>元素下。
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.
服务器在收到订户对上一个通知请求的最终响应或上一个通知请求超时之前，不得发送带有部分通知的新通知请求。
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”内容类型发送包含完整文档的通知请求。
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.
当订阅服务器在“应用程序/资源列表+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 List+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 如果通知包含“应用程序/资源列表diff+xml”文档，则订阅者必须将收到的“应用程序/资源列表diff+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.
如果订阅服务器在处理“应用程序/资源列表diff+xml”编码文档时遇到处理错误，则订阅服务器应续订。订阅者可以通过在新的订阅请求中不包含“应用程序/资源列表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].
这是“应用程序/资源列表diff+XML”数据格式的XML模式。[RFC5261]中定义了“urn:ietf:params:xml:schema:xml patch ops”模式。
<?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" 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"/>
<!-- 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>
<!-- 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”文档的示例，该文档包含完整状态。以下是“应用程序/资源列表差异+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 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>
<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>
<?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.
本规范涉及五个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>
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
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>
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>
<?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
URI: urn:ietf:params:xml:schema:consent-status
Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
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]
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>
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.
本节注册“应用程序/资源列表差异+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子类型名称：资源列表diff+xml强制参数：无可选参数：与[RFC3023]中指定的字符集参数application/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
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.
用于向订户传递信息的机制应确保信息的完整性和保密性。为了实现这些，应使用端到端SIP加密机制，如[RFC3261]中所述的S/MIME。
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.
乔纳森·罗森博格就这份文件提供了有用的想法。本·坎贝尔和玛丽·巴恩斯对该文件进行了全面审查。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媒体类型”，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：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，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路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 52612008年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
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.