Network Working Group M. Garcia-Martin
Request for Comments: 5364 G. Camarillo
Category: Standards Track Ericsson
October 2008
Network Working Group M. Garcia-Martin
Request for Comments: 5364 G. Camarillo
Category: Standards Track Ericsson
October 2008
Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
可扩展标记语言（XML）格式扩展，用于表示资源列表中的复制控制属性
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
摘要
In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems.
在某些类型的多媒体通信中，会话发起协议（SIP）请求被分发到一组SIP用户代理（UAs）。发送方向服务器发送一个SIP请求，服务器进一步将请求分发给组。此SIP请求包含一个统一资源标识符（URI）列表，用于标识SIP请求的收件人。此URI列表表示为资源列表XML文档。此规范定义了XML资源列表格式的XML扩展，允许请求的发送方使用与现有电子邮件系统的复制控制级别类似的复制控制级别来限定收件人。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Extension to the Resource List Data Format . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Extension to the Resource List Data Format . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
RFC 5363 [RFC5363] describes a generic framework for carrying Uniform Resource Identifier (URI) lists in SIP [RFC3261] messages. Specifically, the document provides a common framework for specific implementations of URI-list services, such as conferences initiated with INVITE requests [RFC5366] or Multiple-recipient MESSAGE requests [RFC5365].
RFC 5363[RFC5363]描述了在SIP[RFC3261]消息中承载统一资源标识符（URI）列表的通用框架。具体而言，该文档为URI列表服务的特定实现提供了一个通用框架，例如使用INVITE请求[RFC5366]或多个收件人消息请求[RFC5365]发起的会议。
Common to all URI-list services is the presence of a SIP request that contains a collection of resources, typically expressed as an XML resource list [RFC4826]. SIP requests carrying resource lists can appear either in requests received by the URI-list server, indicating the list of intended recipients, or in each of the requests that the URI-list server sends to recipients, indicating the list of recipients of the same SIP request.
所有URI列表服务的共同点是存在包含资源集合的SIP请求，通常表示为XML资源列表[RFC4826]。承载资源列表的SIP请求可以出现在URI列表服务器接收的请求中，表示预期收件人的列表，也可以出现在URI列表服务器发送给收件人的每个请求中，表示相同SIP请求的收件人列表。
Although the XML resource list [RFC4826] provides a powerful mechanism for describing a list of resources, there is a need for a copy control attribute to determine whether a resource is receiving a SIP request as a primary recipient, a carbon copy, or a blind carbon copy. This is similar to common email systems, where the sender can categorize each recipient as a "to", "cc", or "bcc" recipient.
尽管XML资源列表[RFC4826]提供了描述资源列表的强大机制，但仍需要复制控制属性来确定资源是作为主要接收者接收SIP请求、复制副本还是盲复制副本。这类似于普通电子邮件系统，发件人可以将每个收件人分类为“收件人”、“抄送”或“密件抄送”收件人。
This document addresses this problem by providing an extension to the XML resource list [RFC4826] that enables the sender to supply a copy control attribute that labels each recipient as a "to", "cc", or "bcc" recipient. This attribute indicates whether the recipient is receiving a primary copy of the SIP request, a carbon copy, or a blind carbon copy. Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs.
本文档通过提供XML资源列表[RFC4826]的扩展来解决此问题，该扩展使发送方能够提供一个复制控制属性，将每个收件人标记为“收件人”、“抄送”或“密件抄送”收件人。此属性指示收件人是接收SIP请求的主副本、复写副本还是盲复写副本。此外，我们为发送方提供了在URI列表中指示一个或多个资源应匿名化的功能，以便某些接收方的URI不会透露给其他接收方。相反，这些URI将替换为匿名URI。
The remainder of this document is organized as follows: Section 2 introduces the terminology used throughout this specification. Section 3 gives an overview of operation. Section 4 formally defines an extension to URI lists. The XML schema definition is provided in Section 5. Section 6 shows examples of the URI lists with the extensions defined in this document. Section 7 discusses the implications of carrying URI lists in SIP messages.
本文件的其余部分组织如下：第2节介绍了本规范中使用的术语。第3节概述了操作。第4节正式定义了URI列表的扩展。XML模式定义在第5节中提供。第6节显示了具有本文档中定义的扩展的URI列表的示例。第7节讨论了在SIP消息中携带URI列表的含义。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
URI-list service: SIP application service that receives a SIP request containing a URI list and sends a similar SIP request to each URI in the list.
URI列表服务：接收包含URI列表的SIP请求并向列表中的每个URI发送类似SIP请求的SIP应用程序服务。
Intended recipient: The intended final recipient of the request to be generated by URI-list service.
预期收件人：URI列表服务生成的请求的预期最终收件人。
Copy control: An attribute assigned by the sender to a URI in an XML resource list. Its purpose is to indicate to the recipient whether he is getting a primary, carbon, or blind carbon copy of the SIP request.
复制控制：发送方分配给XML资源列表中URI的属性。其目的是向接收者指示他是否获得SIP请求的主副本、复写副本或盲复写副本。
Recipient list or recipient XML resource list: An XML resource list containing the list of intended recipients. The sender sets this list in the SIP request he sends to the URI-list server.
收件人列表或收件人XML资源列表：包含预期收件人列表的XML资源列表。发送方在发送给URI列表服务器的SIP请求中设置此列表。
Recipient-history list or recipient-history XML resource list: An XML resource list containing the visible list of recipients (i.e., those non-anonymous non-bcc). The URI-list server creates this list, based on the recipient list, and includes it in each of the SIP requests it sends to each recipient.
收件人历史记录列表或收件人历史记录XML资源列表：包含可见收件人列表（即非匿名非密件抄送）的XML资源列表。URI列表服务器基于收件人列表创建此列表，并将其包含在发送给每个收件人的每个SIP请求中。
Figure 1 depicts a general overview of the operation of a URI-list server. A SIP User Agent Client (UAC) issuer sends a SIP request (F1) to a URI-list server containing a recipient list. The URI-list server generates a SIP request to each recipient, according to the specific SIP method. Each of these SIP requests contains a recipient-history list that indicates the visible list of recipients of the SIP request.
图1描述了URI列表服务器操作的一般概述。SIP用户代理客户端（UAC）颁发者向包含收件人列表的URI列表服务器发送SIP请求（F1）。URI列表服务器根据特定的SIP方法向每个收件人生成SIP请求。每个SIP请求都包含一个收件人历史记录列表，该列表指示SIP请求的可见收件人列表。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2 2xx response | | | |
|<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4 SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5 SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6 200 OK | | |
| |<--------------- | | |
| | F7 200 OK | | |
| |<-------------------------- | |
| | F8 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2 2xx response | | | |
|<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4 SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5 SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6 200 OK | | |
| |<--------------- | | |
| | F7 200 OK | | |
| |<-------------------------- | |
| | F8 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
图1：操作示例
The URI-list mechanism allows a sender to specify multiple targets for a SIP request by including a recipient XML resource list [RFC4826] in the body of the SIP request. This recipient list includes the target URIs of the SIP request (the actual procedures are method specific and outside the scope of this document). Each target URI may also be marked with a copy control attribute to indicate the copy level in which the recipient is receiving the SIP request. This is achieved by the sender qualifying each URI in the URI list with a 'copyControl' attribute. The available values of the 'copyControl' attribute include "to", "cc", and "bcc" (analogous to email). This is discussed in greater detail in Section 4. When the URI-list server expands the request to each recipient, the URI-list server includes a recipient-history XML resource list built upon the recipient list received from the sender. The recipient-history XML resource list replaces the recipient list in the SIP requests generated by the URI-list server towards each recipient. The URI-list server copies from the recipient list those targets that are
URI列表机制允许发送方通过在SIP请求主体中包含接收方XML资源列表[RFC4826]，为SIP请求指定多个目标。此收件人列表包括SIP请求的目标URI（实际过程是特定于方法的，不在本文档的范围内）。每个目标URI还可以用复制控制属性标记，以指示接收方接收SIP请求的复制级别。这是通过发送方使用“copyControl”属性限定URI列表中的每个URI来实现的。“copyControl”属性的可用值包括“收件人”、“抄送”和“密件抄送”（类似于电子邮件）。第4节将对此进行更详细的讨论。当URI列表服务器将请求扩展到每个收件人时，URI列表服务器包括一个收件人历史XML资源列表，该列表基于从发件人接收的收件人列表构建。收件人历史记录XML资源列表替换URI列表服务器向每个收件人生成的SIP请求中的收件人列表。URI列表服务器从收件人列表中复制以下目标：
marked with the "to" and "cc" copy control level, and pastes them in the recipient-history list. The URI-list server explicitly excludes from the recipient-history list those URIs marked with a "bcc" copy control, although it is able to preserve the address of a "bcc" tagged URI when it matches the URI of the recipient of the SIP request (this is described later in Section 4). When a recipient receives the SIP request containing the recipient-history XML resource list, he is able to determine which other visible recipients are getting a copy of the SIP request, and whether they are marked with the "to" or "cc" copy control level. Later, if needed, the recipient can generate a reply to those visible recipients.
标记为“收件人”和“抄送”复制控制级别，并将其粘贴到收件人历史记录列表中。URI列表服务器从收件人历史记录列表中明确排除那些标记有“bcc”复制控件的URI，尽管它能够在“bcc”标记的URI与SIP请求的收件人的URI匹配时保留其地址（这将在第4节稍后描述）。当接收者接收到包含接收者历史XML资源列表的SIP请求时，他能够确定哪些其他可见接收者正在获取SIP请求的副本，以及它们是否标记为“to”或“cc”复制控制级别。之后，如果需要，收件人可以生成对这些可见收件人的回复。
In addition to the 'copyControl' attribute for a URI in an XML resource list, we define a second boolean attribute called 'anonymize'. The sender of a SIP request can mark a URI in a recipient XML resource list with the 'anonymize' attribute to indicate the URI-list server that the URI marked with that attribute is to be replaced with an anonymous URI in the recipient-history XML resource list. This provides knowledge to the recipients of a SIP request of the number of additional visible recipients whose URIs have not been disclosed.
除了XML资源列表中URI的“copyControl”属性外，我们还定义了第二个名为“anonymize”的布尔属性。SIP请求的发送方可以使用“匿名化”属性标记接收方XML资源列表中的URI，以指示URI列表服务器，该服务器将使用接收方历史XML资源列表中的匿名URI替换使用该属性标记的URI。这为SIP请求的接收者提供了尚未公开其uri的其他可见接收者的数量的知识。
There are cases when the sender marks several URIs with the 'anonymize' attribute. The URI-list server can group the anonymized URIs in a single anonymized URI within its copy control level, and provide a count of the number of anonymized URIs. To support this scenario, we define a new 'count' attribute to a URI in the recipient-history XML resource list. It is expected that the 'count' attribute is only used with anonymous URIs, although syntactically it is possible to add a 'count' attribute to any URI in any XML resource list.
在某些情况下，发件人会使用“匿名化”属性标记多个URI。URI列表服务器可以在其复制控制级别内将匿名URI分组到单个匿名URI中，并提供匿名URI的数量计数。为了支持这种情况，我们在接收方历史XML资源列表中为URI定义了一个新的“count”属性。“count”属性预期仅用于匿名URI，尽管从语法上讲，可以向任何XML资源列表中的任何URI添加“count”属性。
Initially, it may be thought that the 'anonymize' attribute overlaps with the "bcc" value of the 'copyControl' attribute. However, there are differences between them. If the sender qualifies a URI with a 'copyControl' attribute of "bcc" in the recipient XML resource list, the URI-list server will typically remove that URI from the recipient-history XML resource list (unless the URI-list server decides to preserve a "bcc" marked URI when that URI is itself the recipient of the SIP request). Recipients of the SIP request will not notice that one or more extra "bcc" URIs also received the request. However, if the sender qualifies a URI with the 'anonymize' attribute in the recipient XML resource list, the URI-list server will replace the URI with an anonymous one in the recipient-history list. Recipients of the SIP request will notice that there have been one or more additional recipients of the same request, but their URIs are not disclosed.
最初，可能认为“匿名化”属性与“copyControl”属性的“bcc”值重叠。然而，它们之间存在差异。如果发送方在接收方XML资源列表中使用“bcc”的“copyControl”属性限定URI，则URI列表服务器通常会从接收方历史XML资源列表中删除该URI（除非当该URI本身是SIP请求的接收方时，URI列表服务器决定保留标记为“bcc”的URI）。SIP请求的接收者不会注意到一个或多个额外的“bcc”URI也收到了该请求。但是，如果发送方在接收方XML资源列表中使用“匿名化”属性限定URI，则URI列表服务器将用接收方历史记录列表中的匿名URI替换该URI。SIP请求的接收者会注意到有一个或多个相同请求的附加接收者，但是他们的URI没有公开。
This document defines an extension to the XML resource list data format [RFC4826] that allows the sender to indicate a copy control attribute that qualifies a recipient with a copy control level. We define a new 'copyControl' attribute to the <entry> element of the resource list document format [RFC4826]. The 'copyControl' attribute has similar semantics to the type of destination address in email systems. It can take the values "to", "cc", and "bcc". A "to" value of the 'copyControl' attribute indicates that the resource is considered a primary recipient of the SIP request. A "cc" value indicates that the resource receives a carbon copy of the SIP request. A "bcc" value indicates that the resource receives a blind carbon copy of the SIP request (i.e., this URI is not disclosed to other recipients of the SIP request). The default 'copyControl' value is "bcc". That is, the absence of a 'copyControl' attribute MUST be treated as if the 'copyControl' was set to "bcc".
本文档定义了XML资源列表数据格式[RFC4826]的扩展，该扩展允许发送方指示复制控制属性，该属性使接收方具有复制控制级别。我们为资源列表文档格式[RFC4826]的<entry>元素定义了一个新的“copyControl”属性。“copyControl”属性的语义与电子邮件系统中的目标地址类型相似。它可以接受值“to”、“cc”和“bcc”。“copyControl”属性的“to”值表示资源被视为SIP请求的主要收件人。“cc”值表示资源收到SIP请求的副本。“bcc”值指示资源接收SIP请求的盲拷贝（即，该URI未公开给SIP请求的其他接收者）。默认的“copyControl”值为“bcc”。也就是说，如果没有“copyControl”属性，则必须将其视为“copyControl”设置为“bcc”。
When creating a recipient-history list, URI-list servers use "bcc" 'copyControl' attributes to route SIP requests. In addition, URI-list servers behave similarly to email systems [RFC2822] with respect to the treatment of these URIs marked with a "bcc" copy control, because they have two ways of treating "bcc" marked URIs. URI-list servers MUST treat these "bcc" marked URIs in either of the following two ways:
创建收件人历史记录列表时，URI列表服务器使用“bcc”‘copyControl’属性来路由SIP请求。此外，URI列表服务器在处理这些标有“bcc”复制控件的URI方面的行为类似于电子邮件系统[RFC2822]，因为它们有两种处理标有“bcc”的URI的方法。URI列表服务器必须以以下两种方式之一处理这些带有“bcc”标记的URI：
o URI-list servers MUST remove all URIs marked with a "bcc" copy control in recipient-history lists. This mechanism allows URI-list servers to send the same recipient-history list to each recipient of the SIP request. However, recipients who are tagged with "bcc" values are not explicitly informed about it.
o URI列表服务器必须删除收件人历史记录列表中标记有“bcc”复制控件的所有URI。此机制允许URI列表服务器向SIP请求的每个收件人发送相同的收件人历史记录列表。但是，使用“密件抄送”值标记的收件人不会被明确告知。
o URI-list servers MUST preserve with a "bcc" copy control in the recipient-history list the URI that identifies the recipient (if any) and MUST remove the remaining URIs marked with a "bcc" copy control. Consequently, each recipient receives a different recipient-history list. However, recipients who have been marked with a "bcc" copy control are explicitly informed about it.
o URI列表服务器必须在收件人历史记录列表中使用“bcc”复制控件保留标识收件人（如果有）的URI，并且必须删除标记有“bcc”复制控件的剩余URI。因此，每个收件人都会收到不同的收件人历史记录列表。但是，已被标记为“密件抄送”副本控件的收件人会被明确告知。
Implementations that are able to receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in the recipient-history list or if it is included but tagged with a "bcc" copy control, then implementations SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients of the SIP request.
能够接收收件人历史记录列表的实现必须注意列表的内容。如果收件人的URI未包含在收件人历史记录列表中，或者包含但标记有“bcc”复制控件，则实现应防止用户回复SIP请求的所有收件人。这将允许非盲接收者注意到SIP请求的盲接收者的存在。
A new 'anonymize' attribute can be included in a <entry> element of the resource list document format [RFC4826]. If set to a "true" value, it provides an indication to the URI-list server for not disclosing the URI itself in a URI list sent to the recipient, but instead to anonymize the URI (i.e., making it bogus in the recipient-history XML resource list). URI-list servers can use URIs tagged with the 'anonymize' attribute for routing SIP requests, but MUST convert them to the SIP URI "sip:anonymous@anonymous.invalid" in recipient-history lists. The default value of the 'anonymize' attribute is "false".
资源列表文档格式[RFC4826]的<entry>元素中可以包含一个新的“匿名化”属性。如果设置为“true”值，它将向URI列表服务器提供一个指示，指示其不在发送给接收方的URI列表中披露URI本身，而是匿名化URI（即，使其在接收方历史XML资源列表中伪造）。URI列表服务器可以使用带有“匿名化”属性的URI来路由SIP请求，但必须将其转换为SIP URI“SIP:anonymous@anonymous.invalid“在收件人历史记录列表中。“匿名化”属性的默认值为“false”。
There are occasions where the URI-list server encounters the same URI entry duplicated in a resource list, where duplicated URI entries are tagged with the same or different values of the 'copyControl' attribute. There are no reasonable usages that justify duplicated URIs in resource lists; thus, this is considered an error. URI-list servers should not send duplicated copies of the same SIP request to the same intended recipient. In case the URI-list server encounters the same URI entry duplicated in a resource list, it should send at most a single copy of the request to that intended recipient. For each set of duplicated URI entries, the URI-list server MUST select the highest precedence value of the 'copyControl' attribute for the same intended recipient. The order of precedence of the values of the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-list server has selected a value for the 'copyControl' attribute of an intended recipient, the URI-list server can continue processing the request.
有时，URI列表服务器遇到资源列表中重复的相同URI条目，重复的URI条目被标记为具有相同或不同的“copyControl”属性值。没有合理的用法来证明资源列表中重复的URI是合理的；因此，这被认为是一个错误。URI列表服务器不应将相同SIP请求的重复副本发送给相同的预期收件人。如果URI列表服务器遇到资源列表中重复的同一URI条目，它最多应将请求的一个副本发送给预期的收件人。对于每组重复的URI条目，URI列表服务器必须为同一预期收件人选择“copyControl”属性的最高优先级值。“copyControl”属性值的优先顺序为：“to”、“cc”和“bcc”。一旦URI列表服务器为预期收件人的“copyControl”属性选择了一个值，URI列表服务器就可以继续处理该请求。
Processing of URIs tagged with a 'copyControl' attribute set to a "bcc" value has higher precedence over the 'anonymize' attribute. Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list server MUST remove that URI from the recipient-history list, and the 'anonymize' attribute will be ignored. Therefore, the 'anonymize' attribute is only useful for those URIs tagged with a 'copyControl' of "to" or "cc".
处理标记为“copyControl”属性设置为“bcc”值的URI的优先级高于“anonymize”属性。因此，如果URI的“copyControl”设置为“bcc”，则URI列表服务器必须从收件人历史记录列表中删除该URI，并且“匿名化”属性将被忽略。因此，“匿名化”属性仅适用于标记为“to”或“cc”的“copyControl”的URI。
A new 'count' attribute can be also included in an <entry> element of the resource list document format [RFC4826]. It provides the number of equal URIs. Typically, recipient lists created by UACs will not have equal (or duplicate) URI entries; thus, it is not expected to contain URIs tagged with 'count' attributes. However, recipient-history lists can contain duplicated anonymized URIs; therefore, it is expected that recipient-history lists will contain 'count' attributes. The default value of the 'count' attribute is "1".
资源列表文档格式[RFC4826]的<entry>元素中还可以包含一个新的“count”属性。它提供相等URI的数量。通常，UACs创建的收件人列表不会有相同（或重复）的URI条目；因此，它不应该包含带有“count”属性的URI。但是，收件人历史记录列表可以包含重复的匿名URI；因此，预期收件人历史记录列表将包含“计数”属性。“计数”属性的默认值为“1”。
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be included as modifiers of any of the child elements included in the <list> element of a resource list (e.g., attribute of the <entry> or <external> elements).
“copyControl”、“anonymize”和“count”属性应作为包含在资源列表的<list>元素中的任何子元素（例如<entry>或<external>元素的属性）的修饰符包含在内。
Section 5 describes the format of the 'copyControl', 'anonymize', and 'count' attributes. Implementations according to this specification MUST support this XML schema.
第5节描述了“copyControl”、“匿名化”和“计数”属性的格式。根据此规范的实现必须支持此XML模式。
Implementations that receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in recipient-history list or if it is included but tagged with a "bcc" copy control, then they SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients in the original SIP request.
接收收件人历史记录列表的实现必须注意列表的内容。如果收件人的URI未包含在收件人历史记录列表中，或者包含但标记有“bcc”复制控件，则应防止用户回复SIP请求的所有收件人。这将允许非盲接收者注意到原始SIP请求中存在盲接收者。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>
</xs:schema>
Figure 2: XML schema of the extension to the resource list format
图2:ResourceList格式扩展的XML模式
This section shows two examples of URI lists that can be included in SIP requests. The first example in Figure 3 shows a recipient list that the UAC sends to the URI-list server. This corresponds to a list that will be included in the flow F2 in Figure 1. The recipient list contains a flat list according to the resource list data format specified in RFC 4826 [RFC4826]. Each resource indicates the copy control of a resource with a 'copyControl' attribute. Some of the resources are also marked with the 'anonymize' attribute. This provides an indication to the URI-list service for not disclosing their URIs in a recipient-history list. The last two <entry> elements are marked with a 'copyControl' attribute of "bcc". This provides an indication to the URI-list server for removing these URIs in the recipient-history list.
本节显示了可以包含在SIP请求中的URI列表的两个示例。图3中的第一个示例显示了UAC发送到URI列表服务器的收件人列表。这对应于将包含在图1中的流F2中的列表。根据RFC 4826[RFC4826]中指定的资源列表数据格式，收件人列表包含一个平面列表。每个资源都表示具有“copyControl”属性的资源的复制控制。一些资源也被标记为“匿名化”属性。这为URI列表服务提供了一个指示，指示其不在收件人历史记录列表中公开其URI。最后两个<entry>元素标记为“bcc”的“copyControl”属性。这为URI列表服务器提供了删除收件人历史记录列表中这些URI的指示。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
Figure 3: Recipient list sent from the UAC to the URI-list server
图3：从UAC发送到URI列表服务器的收件人列表
Upon receipt of the SIP request containing the recipient list of Figure 3, the URI-list server creates a SIP request to each of the URIs listed in the recipient list (so, in our example, it creates 7 SIP requests). The URI-list server processes the recipient list and creates a recipient-history list that is included in each of the
在收到包含图3的接收者列表的SIP请求后，URI列表服务器向接收者列表中列出的每个URI创建一个SIP请求（因此，在我们的示例中，它创建7个SIP请求）。URI列表服务器处理收件人列表并创建一个收件人历史记录列表，该列表包含在每个
outgoing SIP requests. The process is as follows: the URI-list server creates a new recipient-history list, based on the recipient list, but with changes. First, it copies all the URIs (<entry> elements) marked with the "to" or "cc" 'copyControl' attributes, which do not contain an 'anonymize' attribute (or when the 'anonymize' attribute is set to "false"). Then all the URIs marked with a 'copyControl' attribute set to "to" and 'anonymize' attribute set to "true" are replaced with the SIP anonymous URI "sip:anonymous@anonymous.invalid". In this entry, the URI-list server also adds the original value of the 'copyControl' attribute ("to" in our example), and it adds a 'count' attribute containing the number of anonymous entries in this group ("2" in our example). Then the URI-list server does the same operation to the URIs tagged with the 'copyControl' attribute set to "cc" and 'anonymize' attribute set to "true", adding also the 'count' attribute containing the number of anonymous attributes in this group ("1" in the example). Last, the URI-list server removes all URIs marked with the "bcc" 'copyControl' attribute. The resulting recipient-history list is shown in Figure 4.
传出的SIP请求。过程如下：URI列表服务器基于收件人列表创建一个新的收件人历史记录列表，但要进行更改。首先，它复制所有标有“to”或“cc”的“copyControl”属性的URI（<entry>元素），这些属性不包含“anonymize”属性（或者当“anonymize”属性设置为“false”时）。然后，所有标记为“copyControl”属性设置为“to”且“anonymize”属性设置为“true”的URI将替换为SIP匿名URI“SIP:anonymous@anonymous.invalid". 在这个条目中，URI列表服务器还添加了“copyControl”属性的原始值（在我们的示例中为“to”），并添加了一个“count”属性，其中包含该组中匿名条目的数量（在我们的示例中为“2”）。然后，URI列表服务器对标记为“copyControl”属性设置为“cc”和“anonymize”属性设置为“true”的URI执行相同的操作，同时添加包含此组中匿名属性数量的“count”属性（示例中为“1”）。最后，URI列表服务器删除所有标有“bcc”‘copyControl’属性的URI。生成的收件人历史记录列表如图4所示。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
Figure 4: Recipient-history list sent from the URI-list server to each recipient
图4：从URI列表服务器发送给每个收件人的收件人历史记录列表
A SIP UAC (User Agent Client) that composes a SIP request can include a URI list with the extensions specified in this document to indicate the list of intended recipients. On doing so, as specified in RFC 5363 [RFC5363], the UAC adds a Content-Disposition [RFC2183] header field set to the value 'recipient-list'. Typically UACs send these 'recipient-list' bodies to URI-list services (this corresponds to flow F1 in Figure 1). A body whose Content-Disposition type is 'recipient-list' contains a URI list that includes the intended recipients of the SIP request, something known throughout this
组成SIP请求的SIP UAC（用户代理客户端）可以包括一个URI列表，该列表具有本文档中指定的扩展名，以指示预期收件人的列表。执行此操作时，如RFC 5363[RFC5363]中所述，UAC将内容处置[RFC2183]头字段添加到值“收件人列表”中。通常，UAC将这些“收件人列表”主体发送到URI列表服务（这对应于图1中的流F1）。内容处置类型为“收件人列表”的主体包含一个URI列表，其中包含SIP请求的预期收件人，这在本文中是已知的
document as a recipient list. The <entry> element in the URI list MAY also include a 'copyControl' and 'anonymize' attributes, as specified in Section 4.
文档作为收件人列表。URI列表中的<entry>元素还可以包括“copyControl”和“anonymize”属性，如第4节所述。
To be able to inform intended recipients of who else is receiving a copy of the SIP request, we define a new mail disposition type to be included in a Content-Disposition [RFC2183] header field of a SIP request. The value of this new disposition type is 'recipient-list-history' and its purpose is to indicate a list of recipients that a SIP request was sent to, something known throughout this document as a recipient-history list. A body whose Content-Disposition type is 'recipient-list-history' contains a URI list with the visible (including anonymized) recipients of the SIP request. The <entry> element in the URI list MAY also include a 'copyControl' and 'count' attributes, as specified in Section 4.
为了能够通知预期收件人还有谁正在接收SIP请求的副本，我们定义了一个新的邮件处理类型，该类型将包含在SIP请求的内容处理[RFC2183]头字段中。此新处置类型的值为“收件人列表历史记录”，其目的是指示向其发送SIP请求的收件人列表，在本文档中称为收件人历史记录列表。内容处置类型为“收件人列表历史记录”的主体包含一个URI列表，其中包含SIP请求的可见（包括匿名）收件人。URI列表中的<entry>元素还可以包括“copyControl”和“count”属性，如第4节所述。
On sending a SIP request that contains a recipient-history list, if the intended recipient does not support this specification, the SIP request should not fail. In order to ensure successful receipt of the SIP requests that include 'recipient-list-history' bodies, User Agents (such as URI-list servers) that build SIP requests with the Content-Disposition header field set to 'recipient-list-history' SHOULD add a "handling" parameter [RFC3204] set to "optional". Otherwise, the SIP request could fail and never be received by the intended recipient.
发送包含收件人历史记录列表的SIP请求时，如果目标收件人不支持此规范，则SIP请求不应失败。为了确保成功接收包含“收件人列表历史记录”主体的SIP请求，构建内容处置头字段设置为“收件人列表历史记录”的SIP请求的用户代理（如URI列表服务器）应将“处理”参数[RFC3204]添加为“可选”。否则，SIP请求可能会失败，并且不会被预期的接收者接收到。
Even though "Message Body Handling in SIP" [SIP_BODY] mandates support for multipart bodies, legacy recipients may not support them. In such a case, if the request sent by the relay to the recipient needs to contain another body (e.g., a MESSAGE request carrying a message in its body), the relay will not be able to use this extension because the recipient would not be able to process a multipart body with the original body plus the 'recipient-list-history' body.
即使“SIP中的消息正文处理”[SIP_Body]要求支持多部分正文，传统收件人可能不支持它们。在这种情况下，如果中继发送给收件人的请求需要包含另一个正文（例如，正文中包含消息的消息请求），则中继将无法使用此扩展，因为收件人将无法处理包含原始正文和“收件人列表历史”正文的多部分正文。
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of this specification MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
RFC 5363[RFC5363]讨论与SIP URI列表服务相关的问题。本规范的实现必须遵循RFC 5363[RFC5363]中的安全相关规则。这些规则包括选择加入列表和客户端的强制身份验证和授权。
User Agent Clients SHOULD NOT hand SIP requests containing URI-list services to unauthenticated and untrusted parties. This is to avoid man-in-the-middle attacks or acquiring URI lists for performing spam attacks.
用户代理客户端不应将包含URI列表服务的SIP请求转交给未经验证和不受信任的方。这是为了避免中间人攻击或获取URI列表以执行垃圾邮件攻击。
URI lists may contain private information, such as SIP URIs. It is therefore not desirable that these URI lists are known by third parties. Eavesdroppers are able to watch URI lists contained in SIP requests unless the SIP message is sent over a secured channel, by using any of the available SIP mechanisms, such as Transport Layer Security (TLS) [RFC4346], or unless the URI-list body itself is encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED that URI-list bodies are encrypted with S/MIME [RFC3851] or that the SIP request is encrypted with TLS [RFC4346] or any other suitable encryption mechanism.
URI列表可能包含私有信息，例如SIPURI。因此，不希望第三方知道这些URI列表。窃听者能够监视SIP请求中包含的URI列表，除非SIP消息通过安全通道发送，通过使用任何可用的SIP机制，例如传输层安全性（TLS）[RFC4346]，或者除非URI列表体本身使用例如S/MIME[RFC3851]进行加密。因此，建议使用S/MIME[RFC3851]对URI列表体进行加密，或者使用TLS[RFC4346]或任何其他合适的加密机制对SIP请求进行加密。
Note that this URI list does not indicate the actual participants in the session. It indicates only the URIs invited and that might accept the request. It does not assert that these parties actually exist, that they are reachable at the given URI, or that they have accepted the invitation. No inferences about billing should be made from this information. It is subject to spoofing by loading the list with falsified content.
请注意，此URI列表并不表示会话中的实际参与者。它只表示受邀请的URI，并且可能接受请求。它并不断言这些参与方确实存在，它们在给定的URI上是可访问的，或者它们已经接受了邀请。不应从该信息中推断账单。它会通过加载带有伪造内容的列表进行欺骗。
Issuers of SIP request use the "bcc" copy control attribute described in Section 4 to facilitate sending SIP requests to recipients without revealing the URIs of one or more of the other recipients. Mishandling this use of "bcc" copy control has implications for confidential information that might be revealed, which could eventually lead to security problems through knowledge of even the existence of a particular URI. For example, if using the first method described in Section 4, where the "bcc" tagged URIs are removed from the recipient-history list, blind recipients have no explicit indication that they have been sent a blind copy of the SIP request, except insofar as their URI does not appear in the recipient-history list. Because of this, one of the blind URIs could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. When the second method from Section 4 is used, the blind recipient's address appears in the recipient-history list of a separate copy of the list. If the "bcc" tagged URI sent contains all of the "bcc" tagged URIs, all of the "bcc" recipients will be seen by each "bcc" recipient. Even if a separate message is sent to each "bcc" recipient with only the individual's URI, implementations still need to be careful to process replies to the message as per Section 4 so as not to accidentally reveal the blind recipient to other recipients.
SIP请求的发出者使用第4节中描述的“bcc”复制控制属性，以便于向接收者发送SIP请求，而不暴露一个或多个其他接收者的URI。错误处理这种使用“密件抄送”复制控制会对可能泄露的机密信息产生影响，这可能最终导致安全问题，即使知道特定URI的存在。例如，如果使用第4节中描述的第一种方法，其中“bcc”标记的URI从收件人历史记录列表中删除，则盲收件人没有明确指示他们已被发送SIP请求的盲副本，除非他们的URI未出现在收件人历史记录列表中。因此，其中一个盲URI可能会向所有显示的收件人发送回复，并意外地显示邮件已发送给盲收件人。当使用第4节中的第二种方法时，盲收件人的地址将显示在该列表的单独副本的收件人历史记录列表中。如果发送的带“密件抄送”标记的URI包含所有带“密件抄送”标记的URI，则每个“密件抄送”收件人将看到所有“密件抄送”收件人。即使向每个“密件抄送”收件人发送一封单独的邮件，并且只包含该收件人的URI，实现过程仍需小心处理第4节中对该邮件的回复，以免意外地将盲收件人透露给其他收件人。
IANA has made registrations according to the following subsections: a new disposition type, a new XML namespace, and a new XML schema.
IANA已经根据以下小节进行了注册：一个新的处置类型、一个新的XML名称空间和一个新的XML模式。
Section 7 defines a new 'recipient-list-history' value of the Mail Content Disposition Values registry. This value has been registered in the IANA registry of Mail Content Disposition Values with the following registration data:
第7节定义邮件内容处置值注册表的新“收件人列表历史记录”值。此值已使用以下注册数据在IANA邮件内容处置值注册表中注册：
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFC5364] |
| | URIs that indicates the | |
| | recipients of the request | |
+------------------------+------------------------------+-----------+
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFC5364] |
| | URIs that indicates the | |
| | recipients of the request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Disposition Value
表1：“收件人列表历史记录”邮件内容处置值的注册
This section registers a new XML namespace in the IANA XML registry, as per the guidelines in RFC 3688 [RFC3688].
本节根据RFC 3688[RFC3688]中的指南，在IANA XML注册表中注册一个新的XML命名空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
注册人联系人：IETF啜饮工作组(sipping@ietf.org)，米格尔·加西亚·马丁。garcia@ericsson.com).
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
RFC5364</a>.</p>
</body>
</html>
END
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
RFC5364</a>.</p>
</body>
</html>
END
This section registers a new XML schema in the IANA XML registry per the procedures in RFC 3688 [RFC3688].
本节按照RFC 3688[RFC3688]中的过程在IANA XML注册表中注册一个新的XML模式。
URI: urn:ietf:params:xml:schema:copycontrol
URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF SIPPING working group (sipping@ietf.org), Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
注册人联系人：IETF啜饮工作组(sipping@ietf.org)，米格尔·加西亚·马丁。garcia@ericsson.com).
The XML for this schema can be found as the sole content of Section 5.
此模式的XML可以作为第5节的唯一内容找到。
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris Newman for reviewing this document and providing helpful comments.
感谢迪安·威利斯、贾里·乌帕莱宁、佩卡·库雷、佐藤阿特苏希、布赖恩·罗森、玛丽·巴恩斯、詹姆斯·波尔克、布赖恩·E·卡彭特和克里斯·纽曼审阅本文件并提供有用的意见。
[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月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204]Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.，和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]Camarillo，G.和A.B.Roach，“会话启动协议（SIP）URI列表服务的框架和安全注意事项”，RFC 5363，2008年10月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366]Camarillo，G.和A.Johnston，“使用会话启动协议（SIP）中包含的请求列表建立会议”，RFC 5366，2008年10月。
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", RFC 5365, October 2008.
[RFC5365]Garcia Martin，M.和G.Camarillo，“会话启动协议（SIP）中的多收件人消息请求”，RFC 5365，2008年10月。
[SIP_BODY] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", Work in Progress, August 2008.
[SIP_BODY]Camarillo，G.，“会话启动协议（SIP）中的消息体处理”，正在进行的工作，2008年8月。
Authors' Addresses
作者地址
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
Miguel A.Garcia Martin Ericsson Via de los Poblados 13马德里28033西班牙
EMail: miguel.a.garcia@ericsson.com
EMail: miguel.a.garcia@ericsson.com
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.