Network Working Group M. Garcia-Martin
Request for Comments: 5365 G. Camarillo
Category: Standards Track Ericsson
October 2008
Network Working Group M. Garcia-Martin
Request for Comments: 5365 G. Camarillo
Category: Standards Track Ericsson
October 2008
Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
会话启动协议（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 specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.
本文档指定了一种机制，该机制允许SIP用户代理客户端（UAC）通过使用SIP URI列表（统一资源标识符列表）服务向一组目的地发送SIP消息请求。UAC向消息URI列表服务发送包括有效负载和URI列表的SIP消息请求，消息URI列表服务向列表中包括的每个URI发送包括有效负载的消息请求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List Document . . . . . . . . . . . . . . . . . . . . . . 5
5. Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Procedures at the User Agent Client . . . . . . . . . . . . . 6
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7
7.1. Determining the Intended Recipient . . . . . . . . . . . . 8
7.2. Creating an Outgoing MESSAGE Request . . . . . . . . . . . 8
7.3. Composing Bodies in the Outgoing MESSAGE Request . . . . . 10
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List Document . . . . . . . . . . . . . . . . . . . . . . 5
5. Option-Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Procedures at the User Agent Client . . . . . . . . . . . . . 6
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7
7.1. Determining the Intended Recipient . . . . . . . . . . . . 8
7.2. Creating an Outgoing MESSAGE Request . . . . . . . . . . . 8
7.3. Composing Bodies in the Outgoing MESSAGE Request . . . . . 10
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
RFC 3261 (SIP) [RFC3261] is extended by RFC 3248 [RFC3428] to carry instant messages in MESSAGE requests. SIP-based messaging, as described in RFC 3428 [RFC3428], does not provide a mechanism to send the same request to multiple recipients or replying to all recipients of a SIP MESSAGE request. This memo addresses these functions.
RFC 3261（SIP）[RFC3261]由RFC 3248[RFC3428]扩展，以在消息请求中承载即时消息。如RFC 3428[RFC3428]中所述，基于SIP的消息传递不提供向多个收件人发送相同请求或回复SIP消息请求的所有收件人的机制。本备忘录阐述了这些功能。
A first requirement can be expressed as:
第一个要求可以表示为：
REQ-1: It must be possible for a user to send an instant message request to an ad hoc group, where the identities of the recipients are carried in the message itself.
REQ-1：用户必须能够向特设组发送即时消息请求，其中收件人的身份包含在消息本身中。
One possibility to fulfill the above requirement is to establish a session of instant messages with an instant messaging conference server, and exchange the messages, for example, using MSRP (Message Session Relay Protocol) [RFC4975]. While this option seems to be reasonable in many cases, in other situations the sending user just wants to send a small pager-mode instant message to an ad hoc group without the burden of setting up a session. This document focuses on sending a pager-mode instant message to a number of intended recipients.
满足上述要求的一种可能性是与即时消息会议服务器建立即时消息会话，并例如使用MSRP（消息会话中继协议）[RFC4975]交换消息。虽然此选项在许多情况下似乎是合理的，但在其他情况下，发送用户只想向特设组发送一条小型寻呼机模式的即时消息，而无需设置会话。本文档重点介绍如何向多个目标收件人发送寻呼机模式即时消息。
To meet the requirement with a pager-mode instant message, we allow SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363]. A SIP MESSAGE URI-list service, which is a specialized application service, receives the request and sends a MESSAGE request including the received payload to each of the URIs in the list. Each of these MESSAGE requests contains a copy of the body included in the original MESSAGE request.
为了满足寻呼机模式即时消息的要求，我们允许SIP消息请求携带收件人列表主体，即主体部分中的URI列表，其内容配置（RFC 2183）[RFC2183]为“收件人列表”，如RFC 5363[RFC5363]中所述。SIP消息URI列表服务是专门的应用程序服务，它接收请求并向列表中的每个URI发送包括接收的有效负载的消息请求。每个消息请求都包含原始消息请求中包含的正文的副本。
A second requirement addresses the "Reply-To-All" functionality:
第二项要求涉及“回复所有人”功能：
REQ-2: It MUST be possible for the recipient of a group instant message to send a message to all other participants that received the same group instant message (i.e., Reply-To-All).
REQ-2：群组即时消息的接收者必须能够向收到相同群组即时消息的所有其他参与者发送消息（即回复所有参与者）。
To meet this requirement, we provide a mechanism whereby the MESSAGE URI-list service also includes a URI list in body parts whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. The 'recipient-list-history' body is sent along with the instant message payload in each of the instant messages sent to the recipients.
为了满足这一要求，我们提供了一种机制，根据该机制，消息URI列表服务还包括一个URI列表，其主体部分的内容处置（RFC 2183）[RFC2183]为“收件人列表历史”，如RFC 5364[RFC5364]中所述。“收件人列表历史记录”正文与发送给收件人的每个即时消息中的即时消息负载一起发送。
The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE URI-list service needs to be configured with the SIP URI of the service that provides the functionality. Discovering and provisioning of this URI to the UAC is outside the scope of this document.
向消息URI列表服务发送消息请求的用户代理客户端（UAC）需要使用提供该功能的服务的SIPURI进行配置。发现此URI并将其提供给UAC超出了本文档的范围。
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]中的描述进行解释，并指出合规实施的要求级别。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
本文件重复使用RFC 3261[RFC3261]中定义的以下术语：
o Address-of-Record (AOR)
o 记录地址（AOR）
o User Agent (UA)
o 用户代理（UA）
o User Agent Client (UAC)
o 用户代理客户端（UAC）
o User Agent Server (UAS)
o 用户代理服务器（UAS）
This document defines the following new terms:
本文件定义了以下新术语：
MESSAGE URI-list service: A specialized URI-list service that receives a MESSAGE request with a URI list and sends a similar MESSAGE request to each URI in the list. In this context, similar indicates that some SIP header fields can change, but the MESSAGE URI-list service will not change the instant message payload. MESSAGE URI-list services behave effectively as specialized B2BUAs (Back-to-Back-User-Agents). A server providing MESSAGE URI-list services can also offer URI-list services for other methods, although this functionality is outside the scope of this document. In this document, we only discuss MESSAGE URI-list services.
消息URI列表服务：一种专门的URI列表服务，它接收带有URI列表的消息请求，并向列表中的每个URI发送类似的消息请求。在此上下文中，similor表示某些SIP头字段可以更改，但消息URI列表服务不会更改即时消息有效负载。消息URI列表服务有效地表现为专门的B2BUA（背靠背用户代理）。提供消息URI列表服务的服务器也可以为其他方法提供URI列表服务，尽管此功能不在本文档的范围内。在本文档中，我们只讨论消息URI列表服务。
Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates and addresses to a MESSAGE URI-list service. Besides the regular instant message payload, an incoming MESSAGE request contains a URI list.
传入消息请求：UAC创建的SIP消息请求，并向消息URI列表服务寻址。除了常规即时消息负载外，传入消息请求还包含一个URI列表。
Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-list service creates and addresses to a UAS (User Agent Server). It contains the regular instant message payload.
传出消息请求：消息URI列表服务创建的SIP消息请求，并向UAS（用户代理服务器）发送地址。它包含常规即时消息有效负载。
Intended recipient: The intended final recipient of the request to be generated by MESSAGE URI-list service.
预期收件人：由消息URI列表服务生成的请求的预期最终收件人。
Reply-To-All: The ability of an intended recipient to receive a MESSAGE request that includes the payload and the list of recipients, and compose and send a MESSAGE request to the sender and the rest of the recipients. The replying entity can use a MESSAGE URI-list service if one is at its disposal or can create a sequence of regular single-recipient MESSAGE requests to each SIP AOR.
全部回复：预期收件人接收包含有效负载和收件人列表的消息请求，并编写并向发件人和其他收件人发送消息请求的能力。应答实体可以使用消息URI列表服务（如果消息URI列表服务由其支配），或者可以为每个SIP AOR创建一系列常规的单个收件人消息请求。
A UAC creates a MESSAGE request that contains a multipart body including a list of URIs (intended recipients) and an instant message. The list of URIs is formatted according to the resource list document format specified in RFC 4826 [RFC4826] and extended with the attributes defined in RFC 5364 [RFC5364]. The UAC sends this MESSAGE request to the MESSAGE URI-list service. On reception of this incoming MESSAGE request, the MESSAGE URI-list service creates a MESSAGE request per intended recipient (listed in the URI list) and copies the instant message payload to each of those MESSAGES. The MESSAGE URI-list service also manipulates the XML resource list according to the procedures indicated in RFC 5364 [RFC5364], and attaches the result to each of the MESSAGE requests, along with the instant message payload. Then the MESSAGE URI-list service sends each of the created outgoing MESSAGE request to the respective receiver.
UAC创建一个包含多部分正文的消息请求，其中包括URI（预期收件人）列表和即时消息。URI列表根据RFC 4826[RFC4826]中指定的资源列表文档格式进行格式化，并使用RFC 5364[RFC5364]中定义的属性进行扩展。UAC将此消息请求发送到消息URI列表服务。在接收到此传入消息请求时，消息URI列表服务为每个预期收件人（在URI列表中列出）创建一个消息请求，并将即时消息有效负载复制到这些消息中的每一条。消息URI列表服务还根据RFC 5364[RFC5364]中指示的过程操作XML资源列表，并将结果与即时消息有效负载一起附加到每个消息请求。然后，消息URI列表服务将创建的每个传出消息请求发送到相应的接收方。
The MESSAGE URI-list mechanism allows a sender to specify multiple targets for a MESSAGE request by including an XML resource list document according to RFC 4826 [RFC4826] in the body of the MESSAGE request extended with the attributes defined in RFC 5364 [RFC5364]. This resource list, whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as specified in RFC 5363 [RFC5363], includes the URIs of the targets. Each target URI may also be marked to indicate in what role the URI-list service will place the target (e.g., "to", "cc", or "bcc"), and whether the target URI is expected to be anonymized or not, according to the procedures described in RFC 5364 [RFC5364]. When the MESSAGE URI-list server expands the MESSAGE request to each recipient, it includes (along with the instant message payload) a new URI list (based on the received one), whose Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', as specified in RFC 5364 [RFC5364]. This new URI list includes the list of non-anonymous "to" and "cc" targets, allowing recipients both to get knowledge of other recipients and to reply to them.
消息URI列表机制允许发送方根据RFC 4826[RFC4826]在消息请求主体中包含XML资源列表文档，并使用RFC 5364[RFC5364]中定义的属性进行扩展，从而为消息请求指定多个目标。如RFC 5363[RFC5363]所述，此资源列表的内容处置（RFC 2183）[RFC2183]为“收件人列表”，包括目标的URI。根据RFC 5364[RFC5364]中描述的过程，还可以标记每个目标URI，以指示URI列表服务将目标置于什么角色（例如，“to”、“cc”或“bcc”），以及目标URI是否预期匿名化。当消息URI列表服务器将消息请求扩展到每个收件人时，它包括（连同即时消息有效负载）一个新的URI列表（基于接收到的URI列表），其内容处置（RFC 2183）[RFC2183]是“收件人列表历史”，如RFC 5364[RFC5364]中所述。这个新的URI列表包括非匿名的“收件人”和“抄送”目标列表，允许收件人了解其他收件人并回复他们。
As described in RFC 5363 [RFC5363], specifications of individual URI-list services, like the MESSAGE URI-list service described here, need to specify a default format for 'recipient-list' bodies used within the particular service.
如RFC 5363[RFC5363]中所述，各个URI列表服务的规范（如此处所述的消息URI列表服务）需要为特定服务中使用的“收件人列表”主体指定默认格式。
The default format for 'recipient-list' bodies for MESSAGE URI-list services is the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. UACs and MESSAGE URI-list services handling 'recipient-list' bodies MUST support both of these formats and MAY support other formats.
消息URI列表服务的“收件人列表”主体的默认格式是RFC 4826[RFC4826]中指定的资源列表文档，该文档使用复制控制属性[RFC5364]进行扩展。处理“收件人列表”主体的UACs和邮件URI列表服务必须支持这两种格式，并且可能支持其他格式。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the recipient will get the MESSAGE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent that the MESSAGE URI-list server discloses the target URI in a URI list.
如RFC 5364[RFC5364]中所述，每个URI都可以使用设置为“to”、“cc”或“bcc”的“copyControl”属性进行标记，以指示收件人将在其中获取消息请求的角色。此外，可以使用“匿名化”属性标记URI，以防止消息URI列表服务器在URI列表中公开目标URI。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of intended recipients. The default format for 'recipient-list-history' bodies for MESSAGE URI-list services is also the resource list document specified in RFC 4826 [RFC4826] extended with the copy control attributes [RFC5364]. MESSAGE URI-list services MUST support both of these formats; UASs MAY support these formats. MESSAGE URI-list servers and UASs MAY support other formats.
此外，RFC 5364[RFC5364]定义了一个“收件人列表历史记录”正文，其中包含预期收件人的列表。消息URI列表服务的“收件人列表历史记录”正文的默认格式也是RFC 4826[RFC4826]中指定的资源列表文档，并使用复制控制属性[RFC5364]进行扩展。消息URI列表服务必须支持这两种格式；UAS可能支持这些格式。消息URI列表服务器和UAS可能支持其他格式。
The resource list document specified in RFC 4826 [RFC4826] provides a number of features that are not needed by the MESSAGE URI-list service defined in this document. The MESSAGE URI-list service needs to transfer a simple flat list of URIs between a UAC and the MESSAGE URI-list server and between the MESSAGE URI-list server and the UAS. The service does not need hierarchical lists or the ability to include entries by reference relative to the Extensible Configuration Access Protocol (XCAP) [RFC4825] root URI. Therefore, the MESSAGE URI-list service specified herein only uses flat resource lists documents that do not contain relative references.
RFC 4826[RFC4826]中指定的资源列表文档提供了许多本文档中定义的消息URI列表服务不需要的功能。消息URI列表服务需要在UAC和消息URI列表服务器之间以及消息URI列表服务器和UAS之间传输简单的URI平面列表。该服务不需要分层列表，也不需要通过引用包含与可扩展配置访问协议（XCAP）[RFC4825]根URI相关的条目。因此，本文指定的消息URI列表服务仅使用不包含相对引用的平面资源列表文档。
This document defines the 'recipient-list-message' option-tag for use in the Require and Supported SIP header fields.
本文档定义了“收件人列表消息”选项标记，用于“需要”和“支持的SIP头”字段。
This option-tag is used to ensure that a server can process the 'recipient-list' body used in a MESSAGE request. It also provides a mechanism to discover the capability of the server in responses to OPTIONS requests.
此选项标记用于确保服务器可以处理邮件请求中使用的“收件人列表”正文。它还提供了一种机制来发现服务器响应选项请求的能力。
Section 6 provides normative procedures for the usage of this option tag.
第6节提供了使用该选项标签的规范程序。
A UAC that wants to create a multiple-recipient MESSAGE request creates a MESSAGE request that MUST be formatted according to RFC 3428 [RFC3428] Section 4. The UAC populates the Request-URI with the SIP or SIPS URI of the MESSAGE URI-list service. In addition to the regular instant message body, the UAC adds a recipient-list body whose Content-Disposition type is 'recipient-list', specified in RFC 5363 [RFC5363]. This body contains a URI list with the recipients of the MESSAGE. Target URIs in this body MAY also be tagged with the 'copyControl' and 'anonymize' attributes specified in RFC 5364 [RFC5364]. The UAC MUST also include the 'recipient-list-message' option-tag, defined in Section 5, in a Require header field.
想要创建多个收件人消息请求的UAC创建的消息请求必须根据RFC 3428[RFC3428]第4节进行格式化。UAC使用消息URI列表服务的SIP或SIPS URI填充请求URI。除常规即时消息正文外，UAC还添加了一个收件人列表正文，其内容处置类型为“收件人列表”，在RFC 5363[RFC5363]中指定。此正文包含消息收件人的URI列表。此正文中的目标URI也可以使用RFC 5364[RFC5364]中指定的“copyControl”和“anonymize”属性进行标记。UAC还必须在Require头字段中包含第5节中定义的“收件人列表消息”选项标记。
UACs generating MESSAGE requests that carry recipient-list bodies, as described in previous sections, MUST include this option-tag in a Require header field. UAs that are able to receive and process MESSAGEs with a recipient-list body, as described in previous sections, SHOULD include this option-tag in a Supported header field when responding to OPTIONS requests.
如前几节所述，生成包含收件人列表正文的邮件请求的UAC必须在Require标头字段中包含此选项标记。如前几节所述，能够使用收件人列表正文接收和处理邮件的UAs在响应选项请求时，应在受支持的标题字段中包含此选项标记。
Multiple-recipient MESSAGE requests contain a multipart body that contains the body carrying the list and the actual instant message payload. In some cases, the MESSAGE request can contain bodies other than the text and the list bodies (e.g., when the request is protected with S/MIME as per RFC 3851 [RFC3851]).
多个收件人消息请求包含一个多部分正文，其中包含承载列表和实际即时消息负载的正文。在某些情况下，消息请求可以包含文本和列表正文以外的正文（例如，根据RFC 3851[RFC3851]使用S/MIME保护请求时）。
Typically, the MESSAGE URI-list service will copy all the significant header fields in the outgoing MESSAGE request. However, there might be cases where the SIP UA wants the MESSAGE URI-list service to add a particular header field with a particular value, even if the header field wasn't present in the MESSAGE request sent by the UAC. In this case, the UAC MAY use the "?" mechanism described in Section 19.1.1 of RFC 3261 [RFC3261] to encode extra information in any URI in the
通常，消息URI列表服务将复制传出消息请求中的所有重要头字段。然而，在某些情况下，SIP UA可能希望消息URI列表服务添加具有特定值的特定头字段，即使该头字段在UAC发送的消息请求中不存在。在这种情况下，UAC可以使用RFC 3261[RFC3261]第19.1.1节中所述的“？”机制来编码系统中任何URI中的额外信息
list. However, the UAC MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, since the body is present in the MESSAGE request itself.
列表但是，UAC不得使用特殊的“主体”hname（参见RFC 3261[RFC3261]第19.1.1节）对主体进行编码，因为主体存在于消息请求本身中。
The following is an example of a URI that uses the "?" mechanism:
以下是使用“？”机制的URI示例：
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
The previous URI requests the MESSAGE URI-list service to add the following header field to a MESSAGE request to be sent to bob@example.com:
前面的URI请求消息URI列表服务将以下头字段添加到要发送到的消息请求中bob@example.com:
Accept-Contact: *;mobility="mobile"
Accept-Contact: *;mobility="mobile"
The resource list document format specified in RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple MESSAGE URI-list service defined in this document. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC 4826[RFC4826]中指定的资源列表文档格式提供了一些功能，例如分层列表和通过引用包含相对于XCAP根URI的条目的能力。但是，本文档中定义的多消息URI列表服务不需要这些功能。因此，当使用默认资源列表文档时，UAs应该使用平面列表（即，没有层次列表），并且不应该使用<entry ref>元素。
On reception of a MESSAGE request containing a URI list, the MESSAGE URI-list service answers to the UAC with a 202 (Accepted) response.
在接收到包含URI列表的消息请求时，消息URI列表服务以202（已接受）响应向UAC应答。
Note that the status code in the response to the MESSAGE does not provide any information about whether or not the MESSAGEs generated by the URI-list service were successfully delivered to the URIs in the list. That is, a 202 (Accepted) response means that the MESSAGE URI-list service has received the MESSAGE and that it will try to send a similar MESSAGE to the URIs in the list. Designing a mechanism to inform a client about the delivery status of an instant message is outside the scope of this document.
请注意，消息响应中的状态代码不提供任何有关URI列表服务生成的消息是否已成功传递到列表中的URI的信息。也就是说，202（已接受）响应意味着消息URI列表服务已经接收到消息，并且它将尝试向列表中的URI发送类似的消息。设计一种机制来通知客户即时消息的传递状态超出了本文档的范围。
Since the MESSAGE URI-list service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a MESSAGE URI-list server receiving a URI list with more information than what has just been described MAY discard all the extra information.
由于消息URI列表服务不使用分层列表，也不使用通过引用XCAP根URI包含条目的列表，因此接收到比刚才描述的信息更多的URI列表的消息URI列表服务器可能会丢弃所有额外信息。
If a MESSAGE request contains a Request-URI containing a URI that uses the "?" mechanism (see Section 19.1.1 of RFC 3261 [RFC3261]) and such URI contains the special "body" hname to include an additional body, the MESSAGE URI-list server MAY discard the contents of the "body" parameter.
如果消息请求包含一个请求URI，该URI包含一个使用“？”机制的URI（参见RFC 3261[RFC3261]第19.1.1节），并且该URI包含特殊的“正文”hname以包含一个附加正文，则消息URI列表服务器可以丢弃“正文”参数的内容。
On reception of a MESSAGE request containing a URI list, a MESSAGE URI-list service determines the list of intended recipients by inspecting the URI list contained in the body.
在接收到包含URI列表的消息请求时，消息URI列表服务通过检查正文中包含的URI列表来确定预期收件人的列表。
Section 4.1 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, MESSAGE URI-list services MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending duplicated requests to the same recipient.
RFC 5363[RFC5363]的第4.1节讨论了在URI列表中发现重复URI的情况。为了避免重复请求，消息URI列表服务必须考虑RFC 5363[RFC5363]中指定的操作，以避免向同一收件人发送重复请求。
Since the MESSAGE URI-list service behaves as a UAC for outgoing MESSAGE requests, for each of the intended recipients, the MESSAGE URI-list service creates a new MESSAGE request according to the procedures described in Section 4 of RFC 3428 [RFC3428]. Additionally, Section 5.3 of RFC 5363 [RFC5363] provides additional general guidance in creating outgoing requests. This document also specifies the following procedures:
由于消息URI列表服务充当传出消息请求的UAC，因此对于每个预期收件人，消息URI列表服务根据RFC 3428[RFC3428]第4节中描述的程序创建新的消息请求。此外，RFC 5363[RFC5363]第5.3节提供了创建传出请求的额外一般指导。本文件还规定了以下程序：
o A MESSAGE URI-list service MUST include a From header field whose value is the same as the From header field included in the incoming MESSAGE request, subject to the privacy requirements (see RFC 3323 [RFC3323] and RFC 3325 [RFC3325]) expressed in the incoming MESSAGE request.
o 消息URI列表服务必须包括一个From标头字段，该字段的值与传入消息请求中包含的From标头字段的值相同，并符合传入消息请求中表示的隐私要求（请参阅RFC 3323[RFC3323]和RFC 3325[RFC3325]）。
Note that this does not apply to the "tag" parameter.
请注意，这不适用于“tag”参数。
Failure to copy the From header field of the sender results in unacceptable security and privacy failures. Note also that this requirement does not intend to contradict requirements for additional services running on the same physical node. Specifically, a privacy service (see RFC 3323 [RFC3323]) can be co-located with the MESSAGE URI-list service, in which case, the privacy service has precedence over the MESSAGE URI-list service.
未能复制发件人的“发件人”标头字段将导致不可接受的安全和隐私失败。还请注意，此要求无意与在同一物理节点上运行的其他服务的要求相矛盾。具体地说，隐私服务（参见RFC 3323[rfc323]）可以与消息URI列表服务共存，在这种情况下，隐私服务优先于消息URI列表服务。
o A MESSAGE URI-list service SHOULD generate a new To header field value set to the intended recipient's URI. According to the procedures of RFC 3261 [RFC3261] Section 8.1.1.1, this value is also expected to be equal to the Request-URI of the outgoing MESSAGE request.
o 消息URI列表服务应生成一个新的To头字段值，该值设置为预期收件人的URI。根据RFC 3261[RFC3261]第8.1.1.1节的程序，该值也应等于传出消息请求的请求URI。
The MESSAGE URI-list service behaves as a User Agent Client; thus, the To header field should be populated with the recipient's URI.
消息URI列表服务充当用户代理客户端；因此，To header字段应该填充收件人的URI。
o A MESSAGE URI-list service SHOULD create a new Call-ID header field value.
o 消息URI列表服务应该创建一个新的调用ID头字段值。
A Call-ID header field might contain addressing information that the sender wants to remain private. Since there is no need to keep the same Call-ID on both sides of the MESSAGE URI-list service, and since the MESSAGE URI-list service behaves as a User Agent Client, it is recommended to create a new Call-ID header field value according to the regular SIP procedures.
Call ID标头字段可能包含发件人希望保持私有的地址信息。由于无需在消息URI列表服务的两侧保留相同的呼叫ID，并且由于消息URI列表服务的行为类似于用户代理客户端，因此建议根据常规SIP过程创建新的呼叫ID头字段值。
o If a P-Asserted-Identity header field was present in the incoming MESSAGE request and the request was received from a trusted source, as specified in RFC 3325 [RFC3325], and the first hop of the outgoing MESSAGE request is also trusted, a MESSAGE URI-list service MUST include a P-Asserted-Identity header field in the outgoing MESSAGE request with the same received value. However, if the first hop of the outgoing MESSAGE request is not trusted and the incoming MESSAGE request included a Privacy header field with a value different than 'none', the MESSAGE URI-list service MUST NOT include a P-Asserted-Identity header field in the outgoing MESSAGE request.
o 如果传入消息请求中存在P-Asserted-Identity报头字段，并且按照RFC 3325[RFC3325]中的规定，该请求是从可信源接收的，并且传出消息请求的第一个跃点也是可信的，消息URI列表服务必须在传出消息请求中包含具有相同接收值的P-Asserted-Identity头字段。但是，如果传出消息请求的第一个跃点不受信任，并且传入消息请求包含值不同于“无”的隐私标头字段，则消息URI列表服务不得在传出消息请求中包含P-Asserted-Identity标头字段。
o If a MESSAGE URI-list service is able to assert the identity of a user (e.g., using HTTP Digest authentication scheme as per RFC 2617 [RFC2617], S/MIME as per RFC 3851 [RFC3851], etc.) and the service implements a mechanism where it can map that authentication scheme to a user's SIP or SIPS URI, and subject to the privacy requirements expressed in the incoming MESSAGE request (see RFC 3323 [RFC3323]), the MESSAGE URI-list service MAY insert a P-Asserted-Identity header with the value of the user's asserted URI.
o 如果消息URI列表服务能够断言用户的身份（例如，根据RFC 2617[RFC2617]使用HTTP摘要认证方案，根据RFC 3851[RFC3851]使用S/MIME等），并且该服务实现了一种机制，其中该服务可以将该认证方案映射到用户的SIP或SIPS URI，并且根据传入消息请求中表示的隐私要求（参见RFC 3323[rfc323]），消息URI列表服务可以插入具有用户的断言URI的值的P断言标识报头。
o If the incoming MESSAGE request contains an Authorization or Proxy-Authorization header field whose realm is set to the MESSAGE URI-list server's realm, then the MESSAGE URI-list service SHOULD NOT copy it to the outgoing MESSAGE request; otherwise (i.e., if the Authorization or Proxy-Authorization header field of incoming MESSAGE request contains a different realm), the MESSAGE URI-list service MUST copy the value to the respective header field of the outgoing MESSAGE request.
o 如果传入消息请求包含一个授权或代理授权头字段，其领域设置为消息URI列表服务器的领域，则消息URI列表服务不应将其复制到传出消息请求；否则（即，如果传入消息请求的Authorization或Proxy Authorization头字段包含不同的域），消息URI列表服务必须将该值复制到传出消息请求的相应头字段。
o A MESSAGE URI-list service SHOULD create a separate count for the CSeq header field [RFC3261] of the outgoing MESSAGE request.
o 消息URI列表服务应该为传出消息请求的CSeq头字段[RFC3261]创建单独的计数。
o A MESSAGE URI-list service SHOULD initialize the value of the Max-Forward header field of the outgoing MESSAGE request.
o 消息URI列表服务应该初始化传出消息请求的最大转发头字段的值。
o A MESSAGE URI-list service MUST include its own value in the Via header field.
o 消息URI列表服务必须在Via标头字段中包含自己的值。
When creating the body of each of the outgoing MESSAGE requests, the MESSAGE URI-list service keeps the relevant bodies of the incoming MESSAGE request and copies them to the outgoing MESSAGE request. The following guidelines constitute exceptions to the general body handling:
在创建每个传出消息请求的主体时，消息URI列表服务保留传入消息请求的相关主体，并将它们复制到传出消息请求。以下指南构成一般机构处理的例外情况：
o A MESSAGE request received at a MESSAGE URI-list service can contain one or more security bodies (e.g., S/MIME, RFC 3851 [RFC3851]) encrypted with the public key of the MESSAGE URI-list service. These bodies are deemed to be read by the URI-list service rather than the recipient of the outgoing MESSAGE request (which will not be able to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT copy any security body (such as an S/MIME as per RFC 3851 [RFC3851] encrypted body) addressed to the MESSAGE URI-list service to the outgoing MESSAGE request. This includes bodies encrypted with the public key of the URI-list service.
o 在消息URI列表服务处接收的消息请求可以包含用消息URI列表服务的公钥加密的一个或多个安全实体（例如，S/MIME、RFC 3851[RFC3851]）。这些主体被认为是由URI列表服务读取的，而不是传出消息请求的接收者（该接收者将无法解密它们）。因此，消息URI列表服务不得将发往消息URI列表服务的任何安全主体（如根据RFC 3851[RFC3851]加密主体的S/MIME）复制到传出消息请求。这包括使用URI列表服务的公钥加密的实体。
o The incoming MESSAGE request typically contains a recipient-list body or reference, as indicated in RFC 5363 [RFC5363] with the actual list of recipients. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", the URI-list service SHOULD include a URI list in each of the outgoing MESSAGE requests. This list SHOULD be formatted according to the resource list document format specified in RFC 4826 [RFC4826] and the copyControl extension specified in RFC 5364 [RFC5364]. The MESSAGE URI-list service MUST follow the procedures specified in RFC 5364 [RFC5364] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes.
o 传入消息请求通常包含收件人列表正文或引用，如RFC 5363[RFC5363]中所示，其中包含实际的收件人列表。如果此URI列表包含标记为“copyControl”属性并设置为“to”或“cc”值的资源，则URI列表服务应在每个传出消息请求中包含URI列表。该列表的格式应符合RFC 4826[RFC4826]中规定的资源列表文档格式和RFC 5364[RFC5364]中规定的copyControl扩展。消息URI列表服务必须遵循RFC 5364[RFC5364]中指定的有关处理“匿名化”、“计数”和“复制控制”属性的过程。
o If the MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it MUST include a Content-Disposition header field as per RFC 2183 [RFC2183] with the value set to 'recipient-list-history' and a "handling" parameter as per RFC 3204 [RFC3204] set to "optional".
o 如果消息URI列表服务包括传出消息请求中的URI列表，则它必须包括符合RFC 2183[RFC2183]的内容处置头字段，其值设置为“收件人列表历史记录”，以及符合RFC 3204[RFC3204]的“处理”参数设置为“可选”。
o If a MESSAGE URI-list service includes a URI list in an outgoing MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to encrypt the URI list with the public key of the receiver.
o 如果消息URI列表服务在传出消息请求中包含URI列表，则应使用S/MIME（RFC 3851）[RFC3851]使用接收方的公钥加密URI列表。
o The MESSAGE URI-list service SHOULD copy all the remaining message bodies (e.g., text messages, images, etc.) of the incoming MESSAGE request to the outgoing MESSAGE request.
o 消息URI列表服务应将传入消息请求的所有剩余消息体（例如，文本消息、图像等）复制到传出消息请求。
o If there is only one body left, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper in the outgoing MESSAGE request.
o 如果只剩下一个正文，消息URI列表服务必须删除传出消息请求中的多部分/混合包装器。
The rest of the MESSAGE request corresponding to a given URI in the URI list MUST be created following the rules in Section 19.1.5, "Forming Requests from a URI", of RFC 3261 [RFC3261]. In particular, Section 19.1.5 of RFC 3261 [RFC3261] states:
必须按照RFC 3261[RFC3261]第19.1.5节“形成来自URI的请求”中的规则创建与URI列表中给定URI相对应的其余消息请求。具体而言，RFC 3261[RFC3261]第19.1.5节规定：
"An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis."
实现应将URI中存在的任何标头或正文部分视为希望将其包含在消息中，并选择基于每个组件来满足请求
SIP allows to append a "method" parameter to a URI. Therefore, it is legitimate that the 'uri' attribute of the <entry> element in the XML resource list contains a "method" parameter. MESSAGE URI-list services MUST generate only MESSAGE requests, regardless of the "method" parameter that the URIs in the list indicate. Effectively, MESSAGE URI-list services MUST ignore the "method" parameter in each of the URIs present in the URI list.
SIP允许将“方法”参数附加到URI。因此，XML资源列表中<entry>元素的“uri”属性包含“method”参数是合法的。消息URI列表服务必须仅生成消息请求，而不考虑列表中URI指示的“方法”参数。实际上，消息URI列表服务必须忽略URI列表中每个URI中的“method”参数。
A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the MESSAGE URI-list service behaves as specified in RFC 3428 [RFC3428] Section 7.
从消息URI列表服务接收消息请求的UAS（在本规范中，也称为预期接收方UAS）的行为符合RFC 3428[RFC3428]第7节的规定。
If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field as per RFC 2183 [RFC2183] set to 'recipient-list-history', then the UAS will be able to determine the SIP Address-of-Record (AOR) of the other intended recipients of the MESSAGE request. This allows the user to create a reply request (e.g., MESSAGE, INVITE) to the sender and the rest of the recipients included in the URI list.
如果UAS支持此规范，并且消息请求包含一个主体，其内容处置头字段根据RFC 2183[RFC2183]设置为“收件人列表历史记录”，则UAS将能够确定消息请求的其他预期收件人的SIP记录地址（AOR）。这允许用户向发送者和URI列表中包含的其他接收者创建回复请求（例如，消息、邀请）。
Figure 1 shows an example of operation. A SIP UAC issuer sends a MESSAGE request. The MESSAGE URI-list service answers with a 202 (Accepted) response and sends a MESSAGE request to each of the intended recipients.
图1显示了一个操作示例。SIP UAC颁发者发送消息请求。消息URI列表服务使用202（已接受）响应进行应答，并向每个预期收件人发送消息请求。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 MESSAGE | | | |
| ---------------->| | | |
| F2 202 Accepted | | | |
|<---------------- | F3 MESSAGE | | |
| | ------------->| | |
| | F4 MESSAGE | | |
| | ------------------------>| |
| | F5 MESSAGE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 MESSAGE | | | |
| ---------------->| | | |
| F2 202 Accepted | | | |
|<---------------- | F3 MESSAGE | | |
| | ------------->| | |
| | F4 MESSAGE | | |
| | ------------------------>| |
| | F5 MESSAGE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 1: Example of operation
图1：操作示例
The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed body that is composed of two bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml body containing the list of recipients.
消息请求F1（如图2所示）包含一个多部分/混合体，它由两个体组成：一个包含即时消息有效负载的文本/普通体和一个包含收件人列表的应用程序/资源列表+xml体。
MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: MESSAGE URI-list service <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: MESSAGE URI-list service <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
--boundary1
Content-Type: text/plain
--boundary1
Content-Type: text/plain
Hello World!
你好，世界！
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1内容类型：应用程序/资源列表+xml内容处置：收件人列表
<?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>
--boundary1--
<?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>
--boundary1--
Figure 2: MESSAGE request received at the MESSAGE URI-list server
图2：在消息URI列表服务器上接收到的消息请求
The MESSAGE requests F3, F4, and F5 are similar in nature. All those
MESSAGE requests contain a multipart/mixed body that is composed of
two other bodies: a text/plain body containing the instant message
payload and an application/resource-lists+xml containing the list of
recipients. Unlike the text/plain body, the application/
resource-lists+xml bodies of MESSAGE requests F3, F4, and F5 are not
equal to the application/resource-lists+xml body included in the
The MESSAGE requests F3, F4, and F5 are similar in nature. All those
MESSAGE requests contain a multipart/mixed body that is composed of
two other bodies: a text/plain body containing the instant message
payload and an application/resource-lists+xml containing the list of
recipients. Unlike the text/plain body, the application/
resource-lists+xml bodies of MESSAGE requests F3, F4, and F5 are not
equal to the application/resource-lists+xml body included in the
incoming MESSAGE request F1. This is because the URI-list service has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute; besides, the content disposition of these bodies is different. Figure 3 shows an example of the MESSAGE request F3.
传入消息请求F1。这是因为URI列表服务已匿名化了那些标记为“匿名化”属性的URI，并删除了那些标记为“bcc”‘copyControl’属性的URI；此外，这些机构的内容配置也不同。图3显示了消息请求F3的示例。
MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
--boundary1
Content-Type: text/plain
--boundary1
Content-Type: text/plain
Hello World!
你好，世界！
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?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>
--boundary1--
<?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>
--boundary1--
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
图3：消息URI列表服务器发送的消息请求
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Implementations of MESSAGE URI-list services 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列表服务相关的问题。消息URI列表服务的实现必须遵循RFC 5363[RFC5363]中的安全相关规则。这些规则包括选择加入列表和客户端的强制身份验证和授权。
If the contents of the instant message needs to be kept private, the User Agent Client SHOULD use S/MIME as per RFC 3851 [RFC3851] to prevent a third party from viewing this information. In this case, the user agent client SHOULD encrypt the instant message body with a content encryption key. Then, for each receiver in the list, the UAC SHOULD encrypt the content encryption key with the public key of the receiver, and attach it to the MESSAGE request.
如果即时消息的内容需要保密，则用户代理客户端应根据RFC 3851[RFC3851]使用S/MIME，以防止第三方查看此信息。在这种情况下，用户代理客户端应使用内容加密密钥加密即时消息正文。然后，对于列表中的每个接收方，UAC应该使用接收方的公钥加密内容加密密钥，并将其附加到消息请求。
This document defines the SIP option tag 'recipient-list-message'
此文档定义SIP选项标记“收件人列表消息”
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-message | The body contains a list of | [RFC5365] |
| | URIs that indicates the | |
| | recipients of the SIP | |
| | MESSAGE request | |
+------------------------+------------------------------+-----------+
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-message | The body contains a list of | [RFC5365] |
| | URIs that indicates the | |
| | recipients of the SIP | |
| | MESSAGE request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-message' Option-Tag in SIP
表1:SIP中“收件人列表消息”选项标记的注册
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, and Keith Drage provided helpful comments.
Duncan Mills支持1到n条消息的想法。本·坎贝尔、保罗·基齐瓦特、卡伦·詹宁斯、乔纳森·罗森博格、迪安·威利斯和基思·德拉格提供了有益的评论。
[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月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[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月。
[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月。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008.
[RFC5364]Garcia Martin，M.和G.Camarillo，“用于在资源列表中表示复制控制属性的可扩展标记语言（XML）格式扩展”，RFC 5364，2008年10月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
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.