Network Working Group G. Camarillo
Request for Comments: 5363 Ericsson
Category: Standards Track A.B. Roach
Tekelec
October 2008
Network Working Group G. Camarillo
Request for Comments: 5363 Ericsson
Category: Standards Track A.B. Roach
Tekelec
October 2008
Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
会话启动协议（SIP）URI列表服务的框架和安全注意事项
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 describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services.
本文档描述了对SIPURI列表服务的需求，并提供了对其调用的要求。此外，它还为SIPURI列表服务定义了一个框架，其中包括适用于这些服务的安全注意事项。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Requirements ....................................................2
3.1. Requirements for URI-List Services Using
Request-Contained Lists ....................................3
3.2. General Requirements for URI-List Services .................3
4. Framework .......................................................3
4.1. Carrying URI Lists in SIP ..................................3
4.2. Processing of URI Lists ....................................4
4.3. Results ....................................................5
5. Security Considerations .........................................5
5.1. List Integrity and Confidentiality .........................5
5.2. Amplification Attacks ......................................5
5.3. General Issues .............................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Requirements ....................................................2
3.1. Requirements for URI-List Services Using
Request-Contained Lists ....................................3
3.2. General Requirements for URI-List Services .................3
4. Framework .......................................................3
4.1. Carrying URI Lists in SIP ..................................3
4.2. Processing of URI Lists ....................................4
4.3. Results ....................................................5
5. Security Considerations .........................................5
5.1. List Integrity and Confidentiality .........................5
5.2. Amplification Attacks ......................................5
5.3. General Issues .............................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Some applications require that, at a given moment, a SIP [RFC3261] UA (User Agent) performs a similar transaction with a number of remote UAs. For example, an instant messaging application that needs to send a particular message (e.g., "Hello folks") to n receivers needs to send n MESSAGE requests; one to each receiver.
一些应用程序要求，在给定时刻，SIP[RFC3261]UA（用户代理）与多个远程UAs执行类似的事务。例如，需要向n个接收者发送特定消息（例如，“Hello People”）的即时消息应用程序需要发送n个消息请求；每个接收器一个。
When the transaction that needs to be repeated consists of a large request, or when the number of recipients is high, or both, the access network of the UA needs to carry a considerable amount of traffic. Completing all the transactions on a low-bandwidth access would require a long time. This is unacceptable for a number of applications.
当需要重复的事务由大请求组成时，或者当接收者的数量很高时，或者两者兼而有之时，UA的接入网络需要承载相当大的流量。在低带宽访问上完成所有事务需要很长时间。这对于许多应用来说是不可接受的。
A solution to this problem consists of introducing URI-list services in the network. The task of a SIP URI-list service is to receive a request that contains or references a URI list (i.e., a list of one or more URIs) and send a number of similar requests to the destinations in this list. Once the requests are sent, the URI-list service typically informs the UA about their status. Effectively, the URI-list service behaves as a B2BUA (Back-to-Back-User-Agent).
这个问题的解决方案包括在网络中引入URI列表服务。SIP URI列表服务的任务是接收包含或引用URI列表（即，一个或多个URI的列表）的请求，并向该列表中的目的地发送大量类似的请求。一旦发送请求，URI列表服务通常会通知UA它们的状态。实际上，URI列表服务表现为B2BUA（背对背用户代理）。
A given URI-list service can take as an input a URI list contained in the SIP request sent by the client or an external URI list (e.g., the Request-URI is a SIP URI that is associated with a URI list at the server). External URI lists are typically set up using out-of-band mechanisms (e.g., XML Configuration Access Protocol (XCAP) [RFC4825]). An example of a URI-list service for SUBSCRIBE requests that uses stored URI lists is described in [RFC4662].
给定URI列表服务可以将客户端发送的SIP请求中包含的URI列表或外部URI列表（例如，请求URI是与服务器上的URI列表关联的SIP URI）作为输入。外部URI列表通常使用带外机制（例如，XML配置访问协议（XCAP）[RFC4825]）设置。[RFC4662]中描述了用于使用存储的URI列表的订阅请求的URI列表服务的示例。
The remainder of this document provides requirements and a framework for URI-list services using request-contained URI lists, external URI lists, or both.
本文档的其余部分提供了使用包含请求的URI列表、外部URI列表或两者的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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Section 3.1 discusses requirements that only apply to URI-list services that use request-contained lists, and Section 3.2 discusses requirements that also apply to services using external lists.
第3.1节讨论了仅适用于使用包含请求的列表的URI列表服务的要求，第3.2节讨论了也适用于使用外部列表的服务的要求。
REQ 1: The URI-list service invocation mechanism MUST allow the invoker to provide a list of destination URIs to the URI-list service.
REQ 1:URI列表服务调用机制必须允许调用程序向URI列表服务提供目标URI的列表。
REQ 2: The invocation mechanism SHOULD NOT require more than one transaction.
REQ 2：调用机制不应该需要多个事务。
GEN 1: A URI-list service MAY include services beyond sending requests to the URIs in the URI list. That is, URI-list services can be modeled as application servers. For example, a URI-list service handling INVITE requests may behave as a conference server and perform media mixing for all the participants.
GEN 1:URI列表服务可能包括向URI列表中的URI发送请求以外的服务。也就是说，URI列表服务可以建模为应用程序服务器。例如，处理INVITE请求的URI列表服务可以充当会议服务器，并为所有参与者执行媒体混合。
GEN 2: The interpretation of the meaning of the URI list sent by the invoker MUST be at the discretion of the application to which the list is sent.
GEN 2：调用方发送的URI列表含义的解释必须由发送列表的应用程序自行决定。
GEN 3: It MUST be possible for the invoker to find out about the result of the operations performed by the URI-list service with the URI list. An invoker may, for instance, be interested in the status of the transactions initiated by the URI-list service.
GEN 3：调用程序必须能够找到URI列表服务使用URI列表执行的操作的结果。例如，调用方可能对URI列表服务启动的事务的状态感兴趣。
GEN 4: URI-list services MUST NOT send requests to any destination without authenticating the invoker.
GEN 4:URI列表服务必须在未验证调用程序的情况下向任何目标发送请求。
This framework is not restricted to application servers that only provide request fan-out services. Per GEN 1, this framework also deals with application servers that provide a particular service that includes a request fan-out (e.g., a conference server that INVITEs several participants that are chosen by a user agent).
此框架不限于仅提供请求扇出服务的应用程序服务器。根据GEN 1，该框架还处理提供特定服务（包括请求扇出）的应用程序服务器（例如，邀请由用户代理选择的多个参与者的会议服务器）。
The requirements related to URI-list services that use request-contained lists identify the need for a mechanism to provide a SIP URI-list service with a URI list in a single transaction. We define a new disposition type [RFC2183] for the Content-Disposition header field: recipient-list. Both requests and responses MAY carry
与使用包含请求的列表的URI列表服务相关的需求确定了在单个事务中提供具有URI列表的SIP URI列表服务的机制的需求。我们为内容处置头字段定义了一个新的处置类型[RFC2183]：收件人列表。请求和响应都可能包含
recipient-list bodies. Bodies whose disposition type is recipient-list carry a list of URIs that contains the final recipients of the requests to be generated by a URI-list service.
收件人名单机构。处置类型为recipient list的主体包含URI列表，其中包含URI列表服务生成的请求的最终收件人。
The default format for recipient-list bodies is service specific. So, URI-list services specifications MUST specify a default format for recipient-list bodies used within a particular service. In any case, clients SHOULD NOT include any particular URI more than once in a given URI list.
收件人列表正文的默认格式是特定于服务的。所以，URI列表服务规范必须为特定服务中使用的收件人列表体指定默认格式。在任何情况下，客户端都不应该在给定的URI列表中多次包含任何特定的URI。
A UA server receiving a request with more than one recipient-list body parts (e.g., each body part using a different URI-list format) MUST behave as if it had received a single URI list that contains all the URIs present in the different body parts.
UA服务器接收具有多个收件人列表主体部分（例如，使用不同URI列表格式的每个主体部分）的请求时，其行为必须如同接收到包含不同主体部分中存在的所有URI的单个URI列表一样。
A UA server receiving a recipient-list URI list that contains a URI more than once MUST behave as if that URI appeared in the URI list only once. The UA server uses the comparison rules specific to the URI scheme of each of the URIs in the URI list to determine if there is any URI that appears more than once. Additionally, Section 4 of "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364] discusses cases where duplicated URI entries are tagged with different values of the 'copyControl' attribute. Naturally, URI-list services using the 'copyControl' attribute defined in [RFC5364] need to follow the recommendations in [RFC5364] with respect to avoiding sending duplicated requests.
接收多次包含URI的收件人列表URI列表的UA服务器必须表现为该URI仅出现在URI列表中一次。UA服务器使用特定于URI列表中每个URI的URI方案的比较规则来确定是否有任何URI多次出现。此外，“用于在资源列表中表示复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]的第4节讨论了重复的URI条目使用“复制控制”属性的不同值进行标记的情况。当然，使用[RFC5364]中定义的“copyControl”属性的URI列表服务需要遵循[RFC5364]中关于避免发送重复请求的建议。
The way a UA server interprets a URI list that it has received is service specific, as described in Section 4.2.
UA服务器解释其收到的URI列表的方式是特定于服务的，如第4.2节所述。
According to GEN 1 and GEN 2, URI-list services can behave as application servers. That is, taking a URI list as an input, they can provide arbitrary services. So, the interpretation of the URI list by the server depends on the service to be provided. For example, for a conference server, the URIs in the list may identify the initial set of participants. On the other hand, for a server dealing with MESSAGEs, the URIs in the list may identify the recipients of an instant message.
根据GEN 1和GEN 2，URI列表服务可以充当应用程序服务器。也就是说，将URI列表作为输入，它们可以提供任意服务。因此，服务器对URI列表的解释取决于要提供的服务。例如，对于会议服务器，列表中的uri可以标识参与者的初始集合。另一方面，对于处理消息的服务器，列表中的uri可以识别即时消息的接收者。
At the SIP level, this implies that the behavior of application servers receiving requests with URI lists SHOULD be specified on a per-service basis. Examples of such specifications are [RFC5366] for INVITE, [RFC5365] for MESSAGE, and [RFC5367] for SUBSCRIBE.
在SIP级别，这意味着接收具有URI列表的请求的应用程序服务器的行为应该按服务指定。此类规范的示例有[RFC5366]用于邀请，[RFC5365]用于消息，[RFC5367]用于订阅。
According to GEN 3, user agents should have a way to obtain information about the operations performed by the application server. Since these operations are service specific, the way user agents are kept informed is also service specific. For example, a user agent establishing an ad hoc conference with an INVITE with a URI list may discover which participants were successfully brought into the conference by using the conference package [RFC4575].
根据GEN 3，用户代理应该能够获得有关应用服务器执行的操作的信息。由于这些操作是特定于服务的，因此通知用户代理的方式也是特定于服务的。例如，使用具有URI列表的INVITE建立临时会议的用户代理可以通过使用会议包[RFC4575]来发现哪些参与者成功地加入了会议。
Security plays an important role in the implementation of any URI-list service. In fact, it is the most important common area across all types of URI-list services.
安全性在任何URI列表服务的实现中都扮演着重要角色。事实上，它是所有类型的URI列表服务中最重要的公共区域。
By definition, a URI-list service takes one request in and sends a potentially large number of them out. Attackers may attempt to use URI-list services as traffic amplifiers to launch DoS (denial-of-service) attacks. This section provides guidelines to avoid these attacks.
根据定义，URI列表服务接收一个请求，并发送可能大量的请求。攻击者可能试图使用URI列表服务作为流量放大器来发起DoS（拒绝服务）攻击。本节提供了避免这些攻击的指南。
Attackers may attempt to modify URI lists sent from clients to servers. This would cause a different behavior at the server than expected by the client (e.g., requests being sent to different recipients than the ones specified by the client). To prevent this attack, clients SHOULD integrity protect URI lists using end-to-end mechanisms such as S/MIME or, if not available, hop-by-hop mechanisms such as TLS. Both S/MIME and TLS can also provide URI-list confidentiality if needed.
攻击者可能试图修改从客户端发送到服务器的URI列表。这将导致服务器上的行为与客户端预期的不同（例如，将请求发送到不同的收件人，而不是客户端指定的收件人）。为了防止这种攻击，客户端应该使用端到端机制（如S/MIME）或（如果不可用）逐跳机制（如TLS）来保护URI列表的完整性。如果需要，S/MIME和TLS还可以提供URI列表机密性。
URI-list services take a request in and send a potentially large number of them out. Given that URI-list services are typically implemented on top of powerful servers with high-bandwidth access links, we should be careful to keep attackers from using them as amplification tools to launch DoS attacks.
URI列表服务接收一个请求并发送可能大量的请求。鉴于URI列表服务通常是在具有高带宽访问链接的强大服务器上实现的，我们应该小心防止攻击者将其用作发起DoS攻击的放大工具。
Attackers may attempt to send a URI list containing URIs whose host parts route to the victims of the DoS attack. These victims do not need to be SIP nodes; they can be non-SIP endpoints or even routers. If this attack is successful, the result is that an attacker can flood a set of nodes, or a single node, with traffic without needing to generate a high volume of traffic itself.
攻击者可能试图发送一个URI列表，其中包含主机部分路由到DoS攻击受害者的URI。这些受害者不需要是SIP节点；它们可以是非SIP端点，甚至是路由器。如果此攻击成功，其结果是攻击者可以向一组节点或单个节点发送大量流量，而无需自行生成大量流量。
In any case, note that this problem is not specific to SIP URI-list services; it also appears in scenarios that relate to multihoming where a server needs to contact a set of IP addresses provided by a client.
在任何情况下，请注意，此问题并不特定于SIPURI列表服务；它还出现在与多主机相关的场景中，其中服务器需要联系客户机提供的一组IP地址。
There are several measures that need to be taken to prevent this type of attack. The first one is keeping unauthorized users from using URI-list services. So, URI-list services MUST NOT perform any request explosion for an unauthorized user. URI-list services MUST authenticate users and check whether they are authorized to request the service before performing any request fan-out.
需要采取一些措施来防止这种类型的攻击。第一个是阻止未经授权的用户使用URI列表服务。所以，URI列表服务不能为未经授权的用户执行任何请求爆炸。URI列表服务必须对用户进行身份验证，并在执行任何请求扇出之前检查他们是否有权请求服务。
Note that the risk of this attack also exists when a client uses stored URI lists. Application servers MUST use authentication and authorization mechanisms with equivalent security properties when dealing with stored and request-contained URI lists.
请注意，当客户端使用存储的URI列表时，也存在此攻击的风险。在处理存储的和包含请求的URI列表时，应用程序服务器必须使用具有等效安全属性的身份验证和授权机制。
Even though the previous rule keeps unauthorized users from using URI-list services, authorized users may still launch attacks using these services. To prevent these attacks, we introduce the concept of opt-in lists. That is, URI-list services should not allow a client to place a user (identified by his or her URI) in a URI list unless the user has previously agreed to be placed in such a URI list. So, URI-list services MUST NOT send a request to a destination that has not agreed to receive requests from the URI-list service beforehand. Users can agree to receive requests from a URI-list service in several ways, such as filling a web page, sending an email, signing a contract, or using "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)" [RFC5360], whose requirements are discussed in [RFC4453]. Additionally, users MUST be able to further describe the requests they are willing to receive. For example, a user may only want to receive requests from a particular URI-list service on behalf of a particular user. Effectively, these rules make URI lists that used by URI-list services into opt-in lists.
尽管前面的规则禁止未经授权的用户使用URI列表服务，但授权用户仍可能使用这些服务发起攻击。为了防止这些攻击，我们引入了选择加入列表的概念。也就是说，URI列表服务不应允许客户端将用户（由其URI标识）放置在URI列表中，除非该用户先前已同意放置在这样的URI列表中。因此，URI列表服务不能向事先未同意接收来自URI列表服务的请求的目的地发送请求。用户可以通过多种方式同意接收来自URI列表服务的请求，例如填写网页、发送电子邮件、签署合同或使用“会话启动协议（SIP）中基于同意的通信框架”[RFC5360]，其要求在[RFC4453]中讨论。此外，用户必须能够进一步描述他们愿意接收的请求。例如，用户可能只希望代表特定用户接收来自特定URI列表服务的请求。有效地，这些规则将URI列表服务使用的URI列表制作成opt-in列表。
When a URI-list service receives a request with a URI list from a client, the URI-list service checks whether all the destinations have agreed beforehand to receive requests from the service on behalf of this client. If the URI list has permission to send requests to all of the targets in the request, it does so. If not, it does not send any request at all.
当URI列表服务从客户端接收到带有URI列表的请求时，URI列表服务检查所有目的地是否事先同意代表该客户端接收来自服务的请求。如果URI列表具有向请求中的所有目标发送请求的权限，则它会这样做。如果没有，它根本不会发送任何请求。
The Framework for Consent-Based Communications in SIP [RFC5360] specifies a means for the URI-list service to inform the client that some permissions were missing and how to request them.
SIP[RFC5360]中基于同意的通信框架指定了URI列表服务通知客户端缺少某些权限以及如何请求这些权限的方法。
Note that the mechanism used to obtain permissions should not create opportunities to launch DoS amplification attacks. These attacks would be possible if, for instance, the URI-list service automatically contacted the full set of targets for which it did not have permissions in order to request permissions. The URI-list service would be receiving one SIP request and sending out a number of authorization request messages. The Framework for Consent-Based Communications in SIP [RFC5360] avoids this type of attack by having the client generate roughly the same amount of traffic towards the URI-list service as the service generates towards the destinations.
请注意，用于获取权限的机制不应创造发起DoS攻击的机会。例如，如果URI列表服务自动联系它没有权限的完整目标集以请求权限，则可能发生这些攻击。URI列表服务将接收一个SIP请求并发送多个授权请求消息。SIP[RFC5360]中基于同意的通信框架通过让客户端向URI列表服务生成的通信量与服务向目的地生成的通信量大致相同，从而避免了此类攻击。
In order to have an interoperable way to meet the requirements related to opt-in lists described in this section, URI-list services MUST implement and SHOULD use "A Framework for Consent-Based Communications in SIP" [RFC5360].
为了有一种可互操作的方式来满足本节中描述的与选择加入列表相关的要求，URI列表服务必须实现并应使用“SIP中基于同意的通信框架”[RFC5360]。
URI-list services MAY have policies that limit the number of URIs in the lists they accept, as a very long list could be used in a denial-of-service attack to place a large burden on the URI-list service to send a large number of SIP requests.
URI列表服务可能具有限制其接受的列表中URI数量的策略，因为很长的列表可用于拒绝服务攻击，从而给URI列表服务带来发送大量SIP请求的巨大负担。
A URI-list service generates a set of requests from a URI list. Section 19.1.5 of [RFC3261] provides recommendations that need to be taken into consideration when forming a request from a URI. Naturally, those recommendations apply to all SIP URI-list services.
URI列表服务从URI列表生成一组请求。[RFC3261]第19.1.5节提供了在从URI形成请求时需要考虑的建议。当然，这些建议适用于所有SIPURI列表服务。
The general requirement GEN 4, which states that URI-list services need to authenticate their clients, and the previous rules apply to URI-list services in general. In addition, specifications dealing with individual methods MUST describe the security issues that relate to each particular method.
一般要求GEN 4，其中规定URI列表服务需要对其客户端进行身份验证，前面的规则一般适用于URI列表服务。此外，处理单个方法的规范必须描述与每个特定方法相关的安全问题。
This document defines a new Content-Disposition header field disposition type (recipient-list) in Section 4.1. This value has been registered in the IANA registry for Mail Content Disposition Values and Parameters with the following description:
本文档在第4.1节中定义了新的内容处置标题字段处置类型（收件人列表）。此值已在IANA注册表中注册，用于邮件内容处置值和参数，描述如下：
recipient-list The body includes a list of URIs to which URI-list services are to be applied.
收件人列表正文包括要应用URI列表服务的URI列表。
Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n MESSAGE requests. Jon Peterson, Dean Willis, and Jonathan Rosenberg provided useful comments.
Duncan Mills和Miguel A.Garcia Martin支持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月。
[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月。
[RFC5360] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
[RFC5360]Rosenberg，J.，Camarillo，G.，Ed.，和D.Willis，“会话启动协议（SIP）中基于同意的通信框架”，RFC 5360，2008年10月。
[RFC4453] Rosenberg, J., Camarillo, G., and D. Willis, "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 4453, April 2006.
[RFC4453]Rosenberg，J.，Camarillo，G.，和D.Willis，“会话启动协议（SIP）中基于同意的通信要求”，RFC 4453，2006年4月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC4662] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.B.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[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月。
[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月。
[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月。
[RFC5367] Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008.
[RFC5367]Camarillo，G.，Roach，A.B.和O.Levin，“会话启动协议（SIP）中包含资源列表的请求订阅”，RFC 5367，2008年10月。
Authors' Addresses
作者地址
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
Adam Roach Tekelec 17210 Campbell Rd Ste 250 Dallas, TX 75252 USA
美国德克萨斯州达拉斯市坎贝尔大道250号，邮编75252
EMail: Adam.Roach@tekelec.com
EMail: Adam.Roach@tekelec.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.