Network Working Group A. B. Roach
Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
Network Working Group A. B. Roach
Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
用于资源列表的会话启动协议（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.
本文档提供了会话启动协议（SIP）特定事件通知机制的扩展，用于订阅同类资源列表。订阅者可以订阅整个列表，然后在列表中任何资源的状态更改时接收通知，而不是单独发送每个资源的订阅。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Operation of List Subscriptions .................................5
4.1. Negotiation of Support for Resource Lists ..................6
4.2. Subscription Duration ......................................7
4.3. NOTIFY Bodies ..............................................7
4.4. RLS Processing of SUBSCRIBE Requests .......................7
4.5. RLS Generation of NOTIFY Requests ..........................7
4.6. Subscriber Processing of NOTIFY Requests ...................9
4.7. Handling of Forked Requests ...............................10
4.8. Rate of Notifications .....................................10
5. Using multipart/related to Convey Aggregate State ..............10
5.1. XML Syntax ................................................11
5.2. List Attributes ...........................................13
5.3. Resource Attributes .......................................14
5.4. Name Attributes ...........................................14
5.5. Instance Attributes .......................................14
5.6. Constructing Coherent Resource State ......................16
5.6.1. Processing Full State Notifications ................17
5.6.2. Processing Partial State Notifications .............17
6. Example ........................................................18
7. Security Considerations ........................................31
7.1. Authentication ............................................31
7.1.1. RLS and Subscriber in the Same Domain ..............31
7.1.2. RLS and Subscriber in Different Domains ............32
7.2. Risks of Improper Aggregation .............................33
7.3. Signing and Sealing .......................................33
7.4. Infinite Loops ............................................34
8. IANA Considerations ............................................34
8.1. New SIP Option Tag: eventlist .............................34
8.2. New MIME type for Resource List Meta-Information ..........34
8.3. URN Sub-Namespace .........................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Operation of List Subscriptions .................................5
4.1. Negotiation of Support for Resource Lists ..................6
4.2. Subscription Duration ......................................7
4.3. NOTIFY Bodies ..............................................7
4.4. RLS Processing of SUBSCRIBE Requests .......................7
4.5. RLS Generation of NOTIFY Requests ..........................7
4.6. Subscriber Processing of NOTIFY Requests ...................9
4.7. Handling of Forked Requests ...............................10
4.8. Rate of Notifications .....................................10
5. Using multipart/related to Convey Aggregate State ..............10
5.1. XML Syntax ................................................11
5.2. List Attributes ...........................................13
5.3. Resource Attributes .......................................14
5.4. Name Attributes ...........................................14
5.5. Instance Attributes .......................................14
5.6. Constructing Coherent Resource State ......................16
5.6.1. Processing Full State Notifications ................17
5.6.2. Processing Partial State Notifications .............17
6. Example ........................................................18
7. Security Considerations ........................................31
7.1. Authentication ............................................31
7.1.1. RLS and Subscriber in the Same Domain ..............31
7.1.2. RLS and Subscriber in Different Domains ............32
7.2. Risks of Improper Aggregation .............................33
7.3. Signing and Sealing .......................................33
7.4. Infinite Loops ............................................34
8. IANA Considerations ............................................34
8.1. New SIP Option Tag: eventlist .............................34
8.2. New MIME type for Resource List Meta-Information ..........34
8.3. URN Sub-Namespace .........................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
The SIP-specific event notification mechanism [2] allows a user (the subscriber) to request to be notified of changes in the state of a particular resource. This is accomplished by the subscriber generating a SUBSCRIBE request for the resource, which is processed by a notifier that represents the resource.
特定于SIP的事件通知机制[2]允许用户（订户）请求被通知特定资源的状态的变化。这是由订户生成资源的订阅请求来完成的，该请求由表示资源的通知程序处理。
In many cases, a subscriber has a list of resources they are interested in. Without some aggregating mechanism, this will require the subscriber to generate a SUBSCRIBE request for each resource about which they want information. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. Some specific problems are:
在许多情况下，订阅者都有他们感兴趣的资源列表。如果没有某种聚合机制，这将要求订阅者为他们想要了解的每个资源生成一个订阅请求。对于带宽有限的环境，例如无线网络，单独订阅每个资源是有问题的。一些具体问题是：
o Doing so generates substantial message traffic, in the form of the initial SUBSCRIBE requests for each resource and the refreshes of each individual subscription.
o 这样做会产生大量的消息流量，形式为每个资源的初始订阅请求和每个订阅的刷新。
o The notifier may insist on low refresh intervals, in order to avoid a long-lived subscription state. This means that the subscriber may need to generate SUBSCRIBE refreshes faster than it would like to or has the capacity to.
o 通知程序可能会坚持低刷新间隔，以避免长期订阅状态。这意味着订阅者可能需要以比其希望或有能力更快的速度生成订阅刷新。
o The notifier may generate NOTIFY requests more rapidly than the subscriber desires, causing NOTIFY traffic at a greater volume than is desired by the subscriber.
o 通知程序可以比订阅者期望的更快地生成通知请求，从而导致通知通信量比订阅者期望的大。
To solve these problems, this specification defines an extension to RFC 3265 [2] that allows for requesting and conveying notifications for lists of resources. A resource list is identified by a URI, and it represents a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information. In many cases, the URI used to identify the resource list will be a SIP URI [1]; however, the use of other schemes (such as pres: [10]) is also foreseen.
为了解决这些问题，本规范定义了RFC 3265[2]的扩展，该扩展允许请求和传递资源列表的通知。资源列表由URI标识，它表示零个或多个URI的列表。这些URI中的每一个都是订户希望接收其信息的单个资源的标识符。在许多情况下，用于标识资源列表的URI将是SIP URI[1]；然而，也可以预见使用其他方案（如pres:[10]）。
The notifier for the list is called a "resource list server", or RLS. In order to determine the state of the entire list, the RLS will act as if it has generated a subscription to each resource in the list.
列表的通知程序称为“资源列表服务器”，或RLS。为了确定整个列表的状态，RLS将充当它已生成对列表中每个资源的订阅的角色。
The resource list is not restricted to be inside the domain of the subscriber. Similarly, the resources in the list are not constrained to be in the domain of the resource list server.
资源列表不限于订阅服务器的域内。类似地，列表中的资源也不被限制在资源列表服务器的域中。
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 RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
The following terms are used throughout the remainder of this document.
本文件其余部分使用以下术语。
Back-End Subscription: Any subscription (SIP or otherwise) that an RLS creates to learn of the state of a resource. An RLS will create back-end subscriptions to learn of the state of a resource about which the RLS is not an authority. For back-end subscriptions, RLSes act as a subscriber.
后端订阅：RLS创建以了解资源状态的任何订阅（SIP或其他）。RLS将创建后端订阅，以了解RLS不是授权机构的资源的状态。对于后端订阅，RLSE充当订户。
List Subscription: A subscription to a resource list. In list subscriptions, RLSes act as the notifier.
列表订阅：对资源列表的订阅。在列表订阅中，RLSE充当通知程序。
Resource: A resource is any logical entity that has a state or states that can be subscribed to. Resources are identified by URIs.
资源：资源是具有可订阅状态的任何逻辑实体。资源由URI标识。
Resource List: A list of zero or more resources that can have their individual states subscribed to with a single subscription.
资源列表：一个由零个或多个资源组成的列表，这些资源的各个状态可以通过单个订阅进行订阅。
RLMI: Resource List Meta-Information. RLMI is a document that describes the state of the virtual subscriptions associated with a list subscription.
资源列表元信息。RLMI是描述与列表订阅关联的虚拟订阅状态的文档。
RLS: Resource List Server. RLSes accept subscriptions to resource lists and send notifications to update subscribers of the state of the resources in a resource list.
资源列表服务器。RLSE接受对资源列表的订阅，并发送通知以更新资源列表中资源状态的订阅方。
Virtual Subscription: A Virtual Subscription is a logical construct within an RLS that represents subscriptions to the resources in a resource list. For each list subscription it services, an RLS creates at least one virtual subscription for every resource in the resource list being subscribed to. In some cases, such as when the RLS is not the authority for the state of the resource, this virtual subscription will be associated with a back-end subscription. In other cases, such as when the RLS is the authority for the state of the resource, the virtual subscription will not have a corresponding back-end subscription.
虚拟订阅：虚拟订阅是RLS中的逻辑结构，表示对资源列表中资源的订阅。对于it服务的每个列表订阅，RLS为订阅的资源列表中的每个资源创建至少一个虚拟订阅。在某些情况下，例如当RLS不是资源状态的授权时，此虚拟订阅将与后端订阅相关联。在其他情况下，例如当RLS是资源状态的权威时，虚拟订阅将不具有相应的后端订阅。
This section provides an overview of the typical mode of operation of this extension. It is not normative.
本节概述了该扩展的典型操作模式。这是不规范的。
When users wish to subscribe to the resource of a list of resources, they can use the mechanisms described in this specification. The first step is the creation of a resource list. This resource list is represented by a SIP URI. The list contains a set of URIs, each of which represents a resource for which the subscriber wants to receive information. The resource list can exist in any domain. The list could be manipulated through a web page, through a voice response system, or through some other protocol. The specific means by which the list is created and maintained is outside the scope of this specification.
当用户希望订阅资源列表中的资源时，他们可以使用本规范中描述的机制。第一步是创建资源列表。此资源列表由SIPURI表示。该列表包含一组URI，每个URI表示订阅者希望接收其信息的资源。资源列表可以存在于任何域中。该列表可以通过网页、语音应答系统或其他协议进行操作。创建和维护列表的具体方式不在本规范的范围内。
To learn the resource state of the set of elements on the list, the user sends a single SUBSCRIBE request targeted to the URI of the list. This will be routed to an RLS for that URI. The RLS acts as a notifier, authenticates the subscriber, and accepts the subscription.
为了了解列表上元素集的资源状态，用户发送一个针对列表URI的订阅请求。这将路由到该URI的RLS。RLS充当通知程序，对订户进行身份验证，并接受订阅。
The RLS may have direct information about some or all of the resources specified by the list. If it does not, it could subscribe to any non-local resources specified by the list resource.
RLS可以具有关于列表指定的部分或全部资源的直接信息。如果没有，它可以订阅列表资源指定的任何非本地资源。
Note that subscriptions to non-local resources may or may not be SIP subscriptions; any mechanism for determining such information may be employed. This document uses the term "back-end subscription" to refer to such a subscription, regardless of whether SIP is used to establish and service it.
请注意，对非本地资源的订阅可能是也可能不是SIP订阅；可采用任何确定此类信息的机制。本文档使用术语“后端订阅”来指代此类订阅，而不管是否使用SIP来建立和服务它。
As the state of resources in the list change, the RLS generates notifications to the list subscribers. The RLS can, at its discretion, buffer notifications of resource changes and send the resource information to the subscriber in batches, rather than individually. This allows the RLS to provide rate limiting for the subscriber.
随着列表中资源的状态改变，RLS生成通知给列表订阅者。RLS可以自行决定缓冲资源更改的通知，并将资源信息分批发送给订阅者，而不是单独发送。这允许RLS为订户提供速率限制。
The list notifications contain a body of type multipart/related. The root section of the multipart/related content is an XML document that provides meta-information about each resource present in the list. The remaining sections contain the actual state information for each resource.
列表通知包含类型为multipart/related的正文。多部分/相关内容的根部分是一个XML文档，提供列表中每个资源的元信息。其余部分包含每个资源的实际状态信息。
The event list extension acts, in many ways, like an event template package. In particular, any single list subscription must be homogeneous with respect to the underlying event package. In other words, a single list subscription can apply only one event package to all the resources in the resource list.
事件列表扩展的作用在许多方面与事件模板包类似。特别是，任何单个列表订阅都必须与基础事件包相同。换句话说，单个列表订阅只能将一个事件包应用于资源列表中的所有资源。
Note that it is perfectly valid for an RLS to allow multiple subscriptions to the same list to use differing event packages.
请注意，RLS允许对同一列表的多个订阅使用不同的事件包是完全有效的。
The key difference between a list subscription and templates in general is that support for list subscriptions indicates support for arbitrary nesting of list subscriptions. In other words, elements within the list may be atomic elements, or they may be lists themselves.
列表订阅和模板之间的主要区别在于，对列表订阅的支持表示对列表订阅的任意嵌套的支持。换句话说，列表中的元素可以是原子元素，也可以是列表本身。
The consequence of this is that subscription to a URI that represents a list actually results in several virtual subscriptions to a tree of resources. The leaf nodes of this tree are virtual subscriptions of the event type given in the "Event" header field; all other nodes in the tree are list subscriptions that are serviced as described in this section and its subsections.
这样做的结果是，对表示列表的URI的订阅实际上会导致对资源树的多个虚拟订阅。此树的叶节点是“事件”标题字段中给定的事件类型的虚拟订阅；树中的所有其他节点都是列表订阅，按照本节及其子节所述提供服务。
Keep in mind that these virtual subscriptions are not literal SIP subscriptions (although they may result in SIP subscriptions, depending on the RLS implementation).
请记住，这些虚拟订阅不是字面SIP订阅（尽管它们可能导致SIP订阅，具体取决于RLS实现）。
This specification uses the SIP option tag mechanism for negotiating support for the extension defined herein. Refer to RFC 3261 [1] for the normative description of processing of the "Supported" and "Require" header fields and the 421 (Extension Required) response code.
本规范使用SIP选项标记机制来协商对本文定义的扩展的支持。关于“受支持”和“需要”标题字段以及421（需要扩展名）响应代码处理的规范性说明，请参阅RFC 3261[1]。
A non-normative description of the implications of the use of option tags follows. Any client that supports the event list extension will include an option tag of "eventlist" in a "Supported" header field of every SUBSCRIBE message for a subscription for which it is willing to process a list. If the subscription is made to a URI that represents a list, the RLS will include "eventlist" in a "Require" header field of the response to the SUBSCRIBE, and in all NOTIFY messages within that subscription.
下文对使用选项标签的含义进行了非规范性描述。任何支持事件列表扩展的客户端都将在其愿意处理列表的订阅的每个订阅消息的“受支持”头字段中包含一个选项标记“eventlist”。如果订阅是对表示列表的URI进行的，RLS将在订阅响应的“Require”头字段中以及该订阅内的所有通知消息中包括“eventlist”。
Use of "Require: eventlist" in NOTIFY messages is applied by the notifier to satisfy the RFC 3261 requirement that a UAC MUST insert a Require header field into a request if the UAC wishes to insist that a UAS understand an extension in order to process the request. Because the NOTIFY would not be usable without applying the eventlist option, the notifier is obligated to include it.
通知程序在通知消息中使用“Require:eventlist”以满足RFC 3261的要求，即如果UAC希望坚持UAS理解扩展以处理请求，则UAC必须在请求中插入Require头字段。因为如果不应用eventlist选项，NOTIFY将不可用，所以通知程序有义务包含它。
Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except to break interoperability in certain cases, and is consequently NOT RECOMMENDED.
在订阅请求的“Require”头字段中包含“eventlist”除了在某些情况下破坏互操作性外，没有任何作用，因此不建议这样做。
Sending of "Supported: eventlist" in a NOTIFY message is meaningless and silly. Implementations SHOULD NOT include "Supported: eventlist" in any requests except for SUBSCRIBE.
在NOTIFY消息中发送“Supported:eventlist”是毫无意义和愚蠢的。除了SUBSCRIBE之外，实现不应在任何请求中包含“Supported:eventlist”。
There is nothing in a SIP URI that indicates whether it represents a list of resources or a single resource. Therefore, if a subscriber sends a request to a URI that represents a list resource but does not include a Supported header field listing the "eventlist" token, the notifier will typically return a 421 (Extension Required) response code. RFC 3261 [1] advises that servers avoid returning a 421 and instead attempt to process the request without the extension. However, in this case, the URI fundamentally represents a list resource, and therefore the subscription cannot proceed without this extension.
SIPURI中没有任何内容指示它是表示资源列表还是表示单个资源。因此，如果订户向表示列表资源但不包括列出“eventlist”令牌的受支持的头字段的URI发送请求，通知程序通常将返回421（需要扩展名）响应代码。RFC 3261[1]建议服务器避免返回421，而是尝试在没有扩展的情况下处理请求。但是，在本例中，URI基本上表示一个列表资源，因此没有此扩展，订阅无法继续。
Since the primary benefit of the resource list server is to reduce the overall messaging volume to a subscriber, it is RECOMMENDED that the subscription duration to a list be reasonably long. The default, when no duration is specified, is taken from the underlying event package. Of course, the standard techniques [2] can be used to increase or reduce this amount.
由于资源列表服务器的主要好处是减少订阅服务器的总体消息量，因此建议订阅列表的持续时间合理较长。未指定持续时间时，默认值取自基础事件包。当然，可以使用标准技术[2]来增加或减少这一数量。
An implementation compliant to this specification MUST support the multipart/related and application/rlmi+xml MIME types. These types MUST be included in an Accept header sent in a SUBSCRIBE message, in addition to any other types supported by the client (including any types required by the event package being used).
符合此规范的实现必须支持多部分/相关和应用程序/rlmi+xml MIME类型。除了客户端支持的任何其他类型（包括所使用的事件包所需的任何类型）之外，这些类型必须包含在订阅消息中发送的接受标头中。
Once the subscriber is authenticated, the RLS performs authorization per its local policy. In many cases, each resource list is associated with a particular user (the one who created it and manages the set of elements in it), and only that user will be allowed to subscribe. Of course, this mode of operation is not inherent in the use of resource lists, and an RLS can use any authorization policy it chooses.
一旦用户通过身份验证，RLS将根据其本地策略执行授权。在许多情况下，每个资源列表都与特定的用户（创建它并管理其中的元素集的用户）相关联，并且只有该用户才允许订阅。当然，这种操作模式不是使用资源列表所固有的，RLS可以使用它选择的任何授权策略。
This specification leaves the choice about how and when to generate NOTIFY requests at the discretion of the implementor. One of the differentiators between various RLS implementations is the means by which they aggregate, rate-limit, or optimize the way in which
本规范让实现者自行决定如何以及何时生成NOTIFY请求。各种RLS实现之间的一个区别是它们的聚合方式、速率限制或优化方式
notifications are generated. As a baseline behavior, the RLS MAY generate a NOTIFY to the RLS subscriber whenever the state of any resource on the list changes.
将生成通知。作为基线行为，RLS可以在列表上的任何资源的状态改变时生成通知给RLS订户。
It is important to understand that any given subscription is a subscription either to a single resource or to a list of resources. This nature (single resource versus list of resources) cannot change during the duration of a single subscription. In particular, this means that RLSes MUST NOT send NOTIFY messages that do not contain RLMI for a subscription if they have previously sent NOTIFY messages in that subscription containing RLMI. Similarly, RLSes MUST NOT send NOTIFY messages that do contain RLMI for a subscription if they have previously sent NOTIFY messages in that subscription which do not.
必须了解，任何给定的订阅都是对单个资源或资源列表的订阅。这种性质（单个资源与资源列表）在单个订阅期间无法更改。特别是，这意味着，如果RLSE以前在包含RLMI的订阅中发送过NOTIFY消息，则不得发送不包含该订阅RLMI的NOTIFY消息。类似地，如果RLSE以前在订阅中发送过不包含RLMI的NOTIFY消息，则不得发送包含该订阅的RLMI的NOTIFY消息。
List representations necessarily contain RLMI documents for two reasons. Importantly, they identify the resource to which the event state corresponds. Many state syntaxes do not fully identify the resource to which the state applies, or they may identify the resource in a different way than it is represented in the list; for example, PIDF documents may contain resource URIs that are not identical to the URI used to retrieve them. Further, RLMI documents serve to disambiguate multiple instances of a single resource.
出于两个原因，列表表示必然包含RLMI文档。重要的是，它们标识事件状态对应的资源。许多状态语法不能完全识别状态所应用的资源，或者它们可能以不同于列表中所表示的方式识别资源；例如，PIDF文档可能包含与用于检索它们的URI不同的资源URI。此外，RLMI文档用于消除单个资源的多个实例的歧义。
See Section 5 for a detailed definition of the syntax used to convey the state of resource lists. For the purposes of the following discussion, it is important to know that the overall list contains zero or more resources, and that the resources contain zero or more instances. Each instance has a state associated with it (pending, active, or terminating) representing the state of the virtual subscription.
有关用于传达资源列表状态的语法的详细定义，请参见第5节。出于以下讨论的目的，必须知道整个列表包含零个或多个资源，并且这些资源包含零个或多个实例。每个实例都有一个与之关联的状态（挂起、活动或终止），表示虚拟订阅的状态。
Notifications contain a multipart document, the first part of which always contains meta-information about the list (e.g., membership, state of the virtual subscription to the resource). Remaining parts are used to convey the actual state of the resources listed in the meta-information.
通知包含一个多部分文档，其第一部分始终包含有关列表的元信息（例如，成员资格、资源的虚拟订阅状态）。其余部分用于传达元信息中列出的资源的实际状态。
The "state" attribute of each instance of a resource in the meta-information is set according to the state of the virtual subscription. The meanings of the "state" attribute are described in RFC 3265 [2].
根据虚拟订阅的状态设置元信息中资源的每个实例的“状态”属性。RFC 3265[2]中描述了“状态”属性的含义。
If an instance of a resource was previously reported to the subscriber but is no longer available (i.e., the virtual subscription to that instance has been terminated), the resource list server SHOULD include that resource instance in the meta-information in the first NOTIFY message sent to the subscriber following the instance's
如果某个资源的实例先前已报告给订阅服务器，但不再可用（即，对该实例的虚拟订阅已终止），则资源列表服务器应将该资源实例包含在该实例发出后发送给订阅服务器的第一条通知消息中的元信息中
unavailability. The RLS MAY continue to do so for future notifications.
不可用。RLS可以继续这样做以备将来通知。
When sending information for a terminated resource instance, the RLS indicates a state of "terminated" and an appropriate reason value. Valid reason values and their meanings are described in RFC 3265 [2]. If the RLS will attempt to recover the resource state again at some point in the future (e.g., when the reason in the meta-information is "probation"), then the instance of the resource SHOULD remain in the meta-information until the instance state is available, or until the RLS gives up on making such state available.
当发送终止资源实例的信息时，RLS指示“终止”状态和适当的原因值。RFC 3265[2]中描述了有效原因值及其含义。如果RLS将在将来的某个时刻再次尝试恢复资源状态（例如，当元信息中的原因为“试用”）时，则资源的实例应保留在元信息中，直到实例状态可用，或者直到RLS放弃使该状态可用为止。
When the first SUBSCRIBE message for a particular subscription is received by an RLS, the RLS will often not know state information for all the resources specified by the resource list. For any resource for which state information is not known, the corresponding "uri" attribute will be set appropriately, and no <instance> elements will be present for the resource.
当RLS接收到特定订阅的第一个订阅消息时，RLS通常不知道由资源列表指定的所有资源的状态信息。对于状态信息未知的任何资源，相应的“uri”属性将被适当设置，并且资源将不存在<instance>元素。
For an initial notification, sections corresponding to resources for which the RLS does have state will be populated with appropriate data (subject, of course, to local policy decisions). This will often occur if the resource list server is co-located with the server for one or more of the resources specified on the list.
对于初始通知，与RLS具有状态的资源相对应的部分将填充适当的数据（当然，取决于本地政策决定）。如果资源列表服务器与列表上指定的一个或多个资源的服务器位于同一位置，则通常会发生这种情况。
Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document in which the full state is indicated. The RLS SHOULD also include state information for all resources in the list for which the RLS has state, subject to policy restrictions. This allows the subscriber to refresh their state, and to recover from lost notifications.
由于后续订阅消息而触发的即时通知应包括指示完整状态的RLMI文档。RLS还应包括列表中RLS具有状态的所有资源的状态信息，受策略限制的约束。这允许订户刷新其状态，并从丢失的通知中恢复。
Notifications for a resource list can convey information about a subset of the list elements. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state.
资源列表的通知可以传递有关列表元素子集的信息。这意味着需要定义一个显式算法来构造相干和一致的状态。
The XML document present in the root of the multipart/related document contains a <resource> element for some or all of the resources in the list. Each <resource> element contains a URI that uniquely identifies the resource to which that section corresponds. When a NOTIFY arrives, it can contain full or partial state (as indicated by the "fullState" attribute of the top-level <list> element). If full state is indicated, then the recipient replaces all state associated with the list with the entities in the NOTIFY body. If full state is not indicated, the recipient of the NOTIFY
多部分/相关文档根目录中的XML文档包含列表中部分或全部资源的<resource>元素。每个<resource>元素都包含一个URI，该URI唯一地标识该节所对应的资源。当通知到达时，它可以包含完全或部分状态（如顶级<list>元素的“fullState”属性所示）。如果指示完全状态，则收件人将使用通知正文中的实体替换与列表关联的所有状态。如果未指明完整状态，则通知的收件人
updates information for each identified resource. Information for any resources that are not identified in the NOTIFY is not changed, even if they were indicated in previous NOTIFY messages. See Section 5.6 for more information.
更新每个已识别资源的信息。NOTIFY中未标识的任何资源的信息不会更改，即使它们已在以前的NOTIFY消息中指示。详见第5.6节。
When full state is indicated, note that it applies only to the RLMI document in which it occurs. In particular, one of the <resource> elements in the document may in turn refer to another list of resources. Any such sub-lists will be detailed in their own RLMI documents, which may or may not have full state indicated.
当指示完整状态时，请注意，它仅适用于发生该状态的RLMI文档。特别地，文档中的<resource>元素之一可以依次引用另一个资源列表。任何此类子列表将在其自己的RLMI文件中详细说明，这些文件可能会或可能不会显示完整状态。
Further note that the underlying event package may have its own rules for compositing partial state notification. When processing data related to those packages, their rules apply (i.e., the fact that they were reported as part of a list does not change their partial notification semantics).
进一步注意，底层事件包可能有自己的规则用于合成部分状态通知。当处理与这些包相关的数据时，它们的规则适用（即，它们作为列表的一部分报告的事实不会改变它们的部分通知语义）。
Finally, note that as a consequence of the way in which resource list subscriptions work, polling of resource state may not be particularly useful. While such polls will retrieve the resource list, they will not necessarily contain state for some or all of the resources on the list.
最后，请注意，由于资源列表订阅的工作方式，轮询资源状态可能不是特别有用。列表中的某些资源不一定都包含，而列表中的某些资源也不一定包含。
Forking makes little sense with subscriptions to event lists, since the whole idea is a centralization of the source of notifications. Therefore, a subscriber to a list MUST NOT install multiple subscriptions when the initial request is forked. If multiple responses are received, they are handled using the techniques described in Section 4.4.9 of RFC 3265 [2].
分叉对于订阅事件列表没有什么意义，因为整个想法是集中通知源。因此，当初始请求分叉时，列表的订户不得安装多个订阅。如果收到多个响应，则使用RFC 3265[2]第4.4.9节中所述的技术进行处理。
One potential role of the RLS is to perform rate limitations on behalf of the subscriber. As such, this specification does not mandate any particular rate limitation, and rather leaves that to the discretion of the implementation.
RLS的一个潜在角色是代表订户执行速率限制。因此，本规范不强制规定任何特定的速率限制，而是由实现自行决定。
In order to convey the state of multiple resources, the list extension uses the "multipart/related" mime type. The syntax for multipart/related is defined in "The MIME Multipart/Related Content-type" [4].
为了传递多个资源的状态，列表扩展使用“multipart/related”mime类型。multipart/related的语法在“MIME multipart/related内容类型”中定义[4]。
The root document of the multipart/related body MUST be a Resource List Meta-Information (RLMI) document. It is of the type "application/rlmi+xml". This document contains the meta-information for the resources contained in the notification. The schema for this XML document is given below.
多部分/相关正文的根文档必须是资源列表元信息（RLMI）文档。它属于“应用程序/rlmi+xml”类型。此文档包含通知中包含的资源的元信息。下面给出了此XML文档的架构。
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi"
elementFormDefault="qualified"
xmlns="urn:ietf:params:xml:ns:rlmi"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="resource" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:attribute name="version" type="xs:unsignedInt"
use="required" />
<xs:attribute name="fullState" type="xs:boolean"
use="required" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="resource">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="instance" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="instance">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi"
elementFormDefault="qualified"
xmlns="urn:ietf:params:xml:ns:rlmi"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="resource" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:attribute name="version" type="xs:unsignedInt"
use="required" />
<xs:attribute name="fullState" type="xs:boolean"
use="required" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="resource">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="instance" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="instance">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
processContents="lax" />
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active" />
<xs:enumeration value="pending" />
<xs:enumeration value="terminated" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="reason" type="xs:string"
use="optional" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
processContents="lax" />
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active" />
<xs:enumeration value="pending" />
<xs:enumeration value="terminated" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="reason" type="xs:string"
use="optional" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute processContents="lax" />
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
An example of a document formatted using this schema follows.
下面是使用此模式格式化的文档示例。
<?xml version="1.0"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@lists.vancouver.example.com"
version="7" fullState="true">
<name xml:lang="en">Buddy List</name>
<name xml:lang="fr">Liste d'amis</name>
<resource uri="sip:bob@vancouver.example.com">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="12345.aaa@vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="12345.aab@vancouver.example.com"/>
</resource>
<resource uri="sip:jim@vancouver.example.com">
<?xml version="1.0"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@lists.vancouver.example.com"
version="7" fullState="true">
<name xml:lang="en">Buddy List</name>
<name xml:lang="fr">Liste d'amis</name>
<resource uri="sip:bob@vancouver.example.com">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="12345.aaa@vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="12345.aab@vancouver.example.com"/>
</resource>
<resource uri="sip:jim@vancouver.example.com">
<name>Jim</name>
<instance id="oflzxqzuvg" state="terminated"
reason="rejected" />
</resource>
<resource uri="sip:ed@vancouver.example.com">
<name>Ed</name>
<instance id="grqhzsppxb" state="pending"/>
</resource>
</list>
<name>Jim</name>
<instance id="oflzxqzuvg" state="terminated"
reason="rejected" />
</resource>
<resource uri="sip:ed@vancouver.example.com">
<name>Ed</name>
<instance id="grqhzsppxb" state="pending"/>
</resource>
</list>
The <list> element present in a list notification MUST contain three attributes.
列表通知中的<list>元素必须包含三个属性。
The first mandatory <list> attribute is "uri", which contains the uri that corresponds to the list. Typically, this is the URI to which the SUBSCRIBE request was sent.
第一个必需的<list>属性是“uri”，它包含与列表对应的uri。通常，这是向其发送订阅请求的URI。
The second mandatory <list> attribute is "version", which contains a number from 0 to 2^32-1. This version number MUST be 0 for the first NOTIFY message sent within a subscription, and MUST increase by exactly one for each subsequent NOTIFY sent within a subscription.
第二个必需的<list>属性是“version”，它包含一个从0到2^32-1的数字。对于在订阅中发送的第一条NOTIFY消息，此版本号必须为0，对于在订阅中发送的每个后续NOTIFY消息，此版本号必须增加1。
The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription.
第三个强制属性是“fullState”。“fullState”属性指示通知消息是否包含列表中每个资源的信息。如果是，则该属性的值为“true”（或“1”）；否则，它是“false”（或“0”）。订阅中发送的第一个通知必须包含完整状态，收到订阅的订阅请求后发送的第一个通知也必须包含完整状态。
Finally, <list> elements MAY contain a "cid" attribute. If present, the "cid" attribute identifies a section within the multipart/related body that contains aggregate state information for the resources contained in the list. The definition of such aggregate information is outside the scope of this document and will be defined on a per-package basis, as needed. The cid attribute is the Content-ID for the corresponding section in the multipart body.
最后，<list>元素可能包含一个“cid”属性。如果存在，“cid”属性，则标识多部分/相关正文中的一个部分，该部分包含列表中包含的资源的聚合状态信息。此类汇总信息的定义不在本文件的范围内，将根据需要按每个包进行定义。cid属性是多部分正文中相应部分的内容ID。
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root. See Section 5.5 for an example.
cid属性必须仅引用多部分/相关文档的顶级部分，其中出现的RLMI文档是该文档的根。有关示例，请参见第5.5节。
The resource list contains one <resource> element for each resource being reported in the notification. These resource elements contain attributes that identify meta-data associated with each resource.
资源列表包含通知中报告的每个资源的一个<resource>元素。这些资源元素包含标识与每个资源关联的元数据的属性。
The "uri" attribute identifies the resource to which the <resource> element corresponds. Typically, this will be a SIP URI that, if subscribed to, would return the state of the resource. This attribute MUST be present.
“uri”属性标识<resource>元素所对应的资源。通常，这将是一个SIPURI，如果订阅，它将返回资源的状态。此属性必须存在。
Each list and resource element contains zero or more name elements. These name elements contain human-readable descriptions or names for the resource list or resource. The contents of these elements are somewhat analogous to the "Display Name" present in the SIP name-addr element.
每个列表和资源元素包含零个或多个名称元素。这些名称元素包含资源列表或资源的可读描述或名称。这些元素的内容在某种程度上类似于SIP Name addr元素中的“Display Name”。
Name elements optionally contain the standard XML "xml:lang" attribute. The "xml:lang" attribute, if present, specifies the language of the human-readable name. If this attribute is present, it MUST contain a valid language tag. Language tags are defined in RFC 3066 [6]. The language tag assists applications in determining which of potentially several name elements should be rendered to the user.
Name元素可以选择包含标准的XML“XML:lang”属性。“xml:lang”属性（如果存在）指定人类可读名称的语言。如果此属性存在，则它必须包含有效的语言标记。语言标记在RFC 3066[6]中定义。language标记帮助应用程序确定应该向用户呈现几个可能的名称元素中的哪一个。
Each resource element contains zero or more instance elements. These instance elements are used to represent a single notifier for the resource. For event packages that allow forking, multiple virtual subscriptions may exist for a given resource. Multiple virtual subscriptions are represented as multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, at most one instance will be present for a given resource.
每个资源元素包含零个或多个实例元素。这些实例元素用于表示资源的单个通知程序。对于允许分叉的事件包，给定资源可能存在多个虚拟订阅。多个虚拟订阅在相应的资源元素中表示为多个实例元素。对于不发生分叉的订阅，给定资源最多会有一个实例。
The "id" attribute contains an opaque string used to uniquely identify the instance of the resource. The "id" attribute is unique only within the context of a resource. Construction of this string is an implementation decision. Any mechanism for generating this string is valid, as long as uniqueness within the resource is assured.
“id”属性包含用于唯一标识资源实例的不透明字符串。“id”属性仅在资源的上下文中是唯一的。构造此字符串是一个实现决策。只要资源中的唯一性得到保证，生成此字符串的任何机制都是有效的。
The "state" attribute contains the subscription state for the identified instance of the resource. This attribute contains one of the values "active", "pending", or "terminated". The meanings for
“state”属性包含已标识资源实例的订阅状态。此属性包含“活动”、“挂起”或“终止”值之一。意义
these values are as defined for the "Subscription-State" header field in RFC 3265 [2].
这些值是为RFC 3265[2]中的“订阅状态”标题字段定义的。
If the "state" attribute indicates "terminated", then a "reason" attribute MUST also be present. This "reason" attribute has the same values and meanings as those given for the "reason" parameter on the "Subscription-State" header field in RFC 3265 [2]. Note that the "reason" attribute is included for informational purposes; the list subscriber is not expected to take any automated actions based on the reason value.
如果“state”属性表示“terminated”，则“reason”属性也必须存在。此“reason”属性的值和含义与RFC 3265[2]中“Subscription State”标题字段中“reason”参数的值和含义相同。请注意，“reason”属性用于提供信息；列表订阅服务器不应根据原因值执行任何自动操作。
Finally, the "cid" attribute, which MUST be present if the "state" attribute is "active", identifies the section within the multipart/related body that contains the actual resource state. This state is expressed in the content type defined by the event package for conveying state. The cid attribute is the Content-ID for the corresponding section in the multipart body.
最后，“cid”属性（如果“state”属性为“active”则必须存在）标识多部分/相关正文中包含实际资源状态的部分。此状态以事件包为传递状态定义的内容类型表示。cid属性是多部分正文中相应部分的内容ID。
The cid attribute MUST refer only to top-level parts of the multipart/related document for which the RLMI document in which it appears is the root.
cid属性必须仅引用多部分/相关文档的顶级部分，其中出现的RLMI文档是该文档的根。
For example, consider a multipart/related document containing three parts; we'll label these parts A, B, and C. Part A is type application/rlmi+xml, part B is type multipart/related, and part C is type application/pidf+xml. Part B is in turn a document containing three parts: D, E, and F. Part D is of type application/rlmi+xml, and parts E and F are of type application/pidf+xml.
例如，考虑包含三个部分的多部分/相关文档；我们将标记这些部分A、B和C。A部分是类型application/rlmi+xml，B部分是类型multipart/related，C部分是类型application/pidf+xml。B部分又是一个包含三部分的文档：D、E和F。D部分的类型为application/rlmi+xml，E和F部分的类型为application/pidf+xml。
+-------------------------------------------+
| Top Level Document: multipart/related |
| |
| +---------------------------------------+ |
| | Part A: application/rlmi+xml | |
| +---------------------------------------+ |
| | Part B: multipart/related | |
| | | |
| | +-----------------------------------+ | |
| | | Part D: application/rlmi+xml | | |
| | +-----------------------------------+ | |
| | | Part E: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | Part F: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | |
| +---------------------------------------+ |
| | Part C: application/pidf+xml | |
| +---------------------------------------+ |
| |
+-------------------------------------------+
+-------------------------------------------+
| Top Level Document: multipart/related |
| |
| +---------------------------------------+ |
| | Part A: application/rlmi+xml | |
| +---------------------------------------+ |
| | Part B: multipart/related | |
| | | |
| | +-----------------------------------+ | |
| | | Part D: application/rlmi+xml | | |
| | +-----------------------------------+ | |
| | | Part E: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | Part F: application/pidf+xml | | |
| | +-----------------------------------+ | |
| | | |
| +---------------------------------------+ |
| | Part C: application/pidf+xml | |
| +---------------------------------------+ |
| |
+-------------------------------------------+
Any "cid" attributes in document A must refer only to parts B or C. Referring to parts D, E, or F would be illegal. Similarly, any "cid" attributes in document D must refer only to parts E or F. Referring to any other parts would be illegal. Also note that the subscription durations of any back-end subscriptions are not propagated into the meta-information state in any way.
文件A中的任何“cid”属性只能指B或C部分。指D、E或F部分是非法的。同样，文件D中的任何“cid”属性必须仅指E或F部分。指任何其他部分都是非法的。还请注意，任何后端订阅的订阅持续时间都不会以任何方式传播到元信息状态。
The resource list subscriber maintains a table for each resource list. The table contains a row for each resource in the resource list. Each row is indexed by the URI for that resource. That URI is obtained from the "uri" attribute on each <resource> element. The contents of each row contain the state of that resource as conveyed in the resource document.
资源列表订阅服务器为每个资源列表维护一个表。该表包含资源列表中每个资源的一行。每一行都由该资源的URI索引。该URI是从每个<resource>元素的“URI”属性获得的。每行的内容都包含资源文档中传递的资源状态。
For resources that provide versioning information (which is mandated by [2] for any formats that allow partial notification), each row also contains a resource state version number. The version number of the row is initialized with the version specified in the first document received, as defined by the corresponding event package. This value is used when comparing versions of partial notifications for a resource.
对于提供版本控制信息的资源（对于允许部分通知的任何格式，[2]强制要求提供版本控制信息），每行还包含一个资源状态版本号。行的版本号使用接收到的第一个文档中指定的版本初始化，该版本由相应的事件包定义。比较资源的部分通知版本时使用此值。
The processing of the resource list notification depends on whether it contains full or partial state.
资源列表通知的处理取决于它是包含完全状态还是部分状态。
If a notification contains full state, indicated by the <list> attribute "fullState" set to "true", the notification is used to update the table. A check is first made to ensure that the "version" attribute of the <list> attribute in the received message is greater than the local version number. If not, the received document is discarded without any further processing. Otherwise, the contents of the resource-list table are flushed and repopulated from the contents of the document. A new row in the table is created for each "resource" element.
如果通知包含由设置为“true”的<list>属性“fullState”指示的完整状态，则该通知用于更新表。首先进行检查，以确保所接收消息中<list>属性的“version”属性大于本地版本号。否则，将丢弃接收到的文档，而不进行任何进一步处理。否则，资源列表表的内容将被刷新，并从文档的内容中重新填充。将为每个“资源”元素创建表中的新行。
If a notification contains partial state, indicated by the <list> attribute "fullState" set to "false", a check is made to ensure that no list notifications have been lost. The value of the local version number (the "version" attribute of the <list> element) is compared to the version number of the new document.
如果通知包含由设置为“false”的<list>属性“fullState”指示的部分状态，则会进行检查以确保没有丢失任何列表通知。本地版本号的值（<list>元素的“version”属性）与新文档的版本号进行比较。
o If the value in the new document is exactly one higher than the local version number, the local version number is increased by one, and the document is processed as described below.
o 如果新文档中的值正好比本地版本号高一个，则本地版本号将增加一个，并按如下所述处理文档。
o If the version in the document is more than one higher than the local version number, the local version number is set to the value in the new document, and the document is processed as described below. The list subscriber SHOULD also generate a refresh request to trigger a full state notification.
o 如果文档中的版本比本地版本号高出一个以上，则本地版本号将设置为新文档中的值，并按如下所述处理文档。列表订阅服务器还应生成刷新请求以触发完整状态通知。
o If the version in the document is less than or equal to the local version, the document is discarded without any further processing.
o 如果文档中的版本小于或等于本地版本，则文档将被丢弃，而无需进一步处理。
For each resource listed in the document, the subscriber checks to see whether a row exists for that resource. This check is done by comparing the Resource-URI value with the URI associated with the row. If the resource doesn't exist in the table, a row is added, and
对于文档中列出的每个资源，订阅者将检查该资源是否存在一行。此检查通过比较资源URI值和与行关联的URI来完成。如果表中不存在该资源，则会添加一行，然后
its state is set to the information from that "resource" element. If the resource does exist, its state is updated to be the information from that "resource" element, as described in the definition of the event package. If a row is updated or created such that its state is now "terminated," that entry MAY be removed from the table at any time.
其状态设置为来自该“资源”元素的信息。如果资源确实存在，其状态将更新为来自该“资源”元素的信息，如事件包定义中所述。如果更新或创建一行，使其状态现在为“终止”，则可以随时从表中删除该条目。
This section gives an example call flow. It is not normative. If a conflict arises between this call flow and the normative behavior described in this or any other document, the normative descriptions are to be followed.
本节给出了一个示例调用流。这是不规范的。如果此调用流与本文档或任何其他文档中描述的规范行为之间发生冲突，则应遵循规范性描述。
In this particular example, we request a subscription to a nested presence list. The subscriber's address-of-record is "sip:adam@vancouver.example.com", and the name of the nested list resource that we are subscribing to is called "sip:adam-buddies@pres.vancouver.example.com". The underlying event package is "presence", described by [8].
在这个特定的示例中，我们请求对嵌套状态列表的订阅。用户的记录地址为“sip:adam@vancouver.example.com，并且我们订阅的嵌套列表资源的名称称为“sip:adam”-buddies@pres.vancouver.example.com". 底层事件包是“存在”，如[8]所述。
In this example, the RLS has information to service some of the resources on the list, but must consult other servers to retrieve information for others. The implementation of the RLS in this example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such information.
在本例中，RLS具有为列表上的某些资源提供服务的信息，但必须咨询其他服务器以检索其他服务器的信息。本例中RLS的实现使用SIP SUBSCRIBE/NOTIFY机制来检索此类信息。
Terminal pres.vancouver.example.com pres.stockholm.example.org
| | pres.dallas.example.net |
1 |---SUBSCRIBE--->| | |
2 |<-----200-------| | |
3 |<----NOTIFY-----| | |
4 |------200------>| | |
5 | |---SUBSCRIBE--->| |
6 | |<-----200-------| |
7 | |<----NOTIFY-----| |
8 | |------200------>| |
9 | |------------SUBSCRIBE----------->|
10| |<--------------200---------------|
11| |<-------------NOTIFY-------------|
12| |---------------200-------------->|
13|<----NOTIFY-----| | |
14|------200------>| | |
Terminal pres.vancouver.example.com pres.stockholm.example.org
| | pres.dallas.example.net |
1 |---SUBSCRIBE--->| | |
2 |<-----200-------| | |
3 |<----NOTIFY-----| | |
4 |------200------>| | |
5 | |---SUBSCRIBE--->| |
6 | |<-----200-------| |
7 | |<----NOTIFY-----| |
8 | |------200------>| |
9 | |------------SUBSCRIBE----------->|
10| |<--------------200---------------|
11| |<-------------NOTIFY-------------|
12| |---------------200-------------->|
13|<----NOTIFY-----| | |
14|------200------>| | |
1. We initiate the subscription by sending a SUBSCRIBE message to our local RLS. (There is no reason that the RLS we contact has to be in our domain, of course). Note that we must advertise support for application/rlmi+xml and multipart/related because we support the eventlist extension, and that we must advertise application/pidf+xml because we are requesting a subscription to presence.
1. 我们通过向本地RL发送SUBSCRIBE消息来启动订阅。（当然，我们联系的RL没有理由必须在我们的领域内）。请注意，我们必须公布对application/rlmi+xml和multipart/related的支持，因为我们支持事件列表扩展；我们必须公布application/pidf+xml，因为我们请求订阅状态。
Terminal -> Local RLS
终端->本地RLS
SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip:adam-buddies@pres.vancouver.example.com>
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:terminal.vancouver.example.com>
Event: presence
Expires: 7200
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip:adam-buddies@pres.vancouver.example.com>
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:terminal.vancouver.example.com>
Event: presence
Expires: 7200
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
2. The Local RLS completes the SUBSCRIBE transaction. Note that authentication and authorization would normally take place at this point in the call flow. Those steps are omitted for brevity.
2. 本地RLS完成订阅事务。请注意，身份验证和授权通常会在调用流的这一点上进行。为了简洁起见，省略了这些步骤。
Local RLS -> Terminal
本地RLS->终端
SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
To: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Expires: 7200
Require: eventlist
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
To: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Expires: 7200
Require: eventlist
Content-Length: 0
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are assuming that the local RLS is also an authority for presence information for the users in the "vancouver.example.com" domain. The NOTIFY contains an RLMI document describing the entire buddy list (initial notifies require full state), as well as presence information for the users about which it already knows. Note that, since the RLS has not yet retrieved information for some of the entries on the list, those <resource> elements contain no <instance> elements.
3. 按照RFC 3265[2]的要求，RLS在接受订阅后立即发送通知。在本例中，我们假设本地RLS也是“wincover.example.com”域中用户状态信息的权威机构。NOTIFY包含一个RLMI文档，描述整个好友列表（初始通知需要完整状态），以及它已经知道的用户状态信息。注意，由于RLS尚未检索列表中某些条目的信息，因此那些<resource>元素不包含<instance>元素。
Local RLS -> Terminal
本地RLS->终端
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<nXYxAE@pres.vancouver.example.com>";
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<nXYxAE@pres.vancouver.example.com>";
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com"
version="1" fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:bob@vancouver.example.com"">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="bUZBsM@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="ZvSvkz@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
</resource>
</list>
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com"
version="1" fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:bob@vancouver.example.com"">
<name>Bob Smith</name>
<instance id="juwigmtboe" state="active"
cid="bUZBsM@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:dave@vancouver.example.com">
<name>Dave Jones</name>
<instance id="hqzsuxtfyq" state="active"
cid="ZvSvkz@pres.vancouver.example.com"/>
</resource>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
</resource>
</list>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <bUZBsM@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <bUZBsM@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:bob@vancouver.example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:bob@vancouver.example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:bob@vancouver.example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:bob@vancouver.example.com</contact>
</tuple>
</presence>
--50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary
--50UBfW7LSCVLtggUPe5z内容传输编码：二进制
Content-ID: <ZvSvkz@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
Content-ID: <ZvSvkz@pres.vancouver.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:dave@vancouver.example.com">
<tuple id="slie74">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:dave@vancouver.example.com">
<tuple id="slie74">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--50UBfW7LSCVLtggUPe5z--
--50UBfW7LSCVLtggUPe5z--
4. The terminal completes the transaction.
4. 终端完成交易。
Terminal -> Local RLS
终端->本地RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
5. In order to service the subscription, the local RLS subscribes to the state of the resources. In this step, the RLS attempts to subscribe to the presence state of the resource "sip:ed@dallas.example.net". Since the local RLS knows how to receive notifications for list subscriptions, it includes the "Supported: eventlist" header field in its request. Although the linkage between this subscription and the one sent by the terminal is left up to the application, this message demonstrates some reasonable behavior by including "Accept" header fields for all the body types it knows the subscriber (Terminal) supports. This is safe to do, since the local RLS will only pass these formats through to the subscriber and does not need to actually understand them.
5. 为了服务于订阅，本地RLS订阅资源的状态。在此步骤中，RLS尝试订阅资源“sip:ed@dallas.example.net". 因为本地RLS知道如何接收列表订阅的通知，所以它在其请求中包含“Supported:eventlist”头字段。尽管此订阅与终端发送的订阅之间的链接由应用程序决定，但此消息通过包含订阅服务器（终端）支持的所有主体类型的“接受”头字段，展示了一些合理的行为。这样做是安全的，因为本地RLS只会将这些格式传递给订阅者，而不需要真正理解它们。
Local RLS -> Presence Server in dallas.example.net
本地RLS->dallas.example.net中的状态服务器
SUBSCRIBE sip:ed@dallas.example.net SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
SUBSCRIBE sip:ed@dallas.example.net SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
Max-Forwards: 70
To: <sip:ed@dallas.example.net>
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn
Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V
zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
Max-Forwards: 70
To: <sip:ed@dallas.example.net>
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm8sIHRoaXMgaXNuJ3QgYSByZWFsIGNlcnQuIFlvdSBvn
Zpb3VzbHkgaGF2ZSB0aW1lIHRvIGtpbGwuIEkKc3VnZ2V
zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
6. The Presence Server in dallas.example.net completes the SUBSCRIBE transaction. Note that authentication would normally take place at this point in the call flow. This step is omitted for brevity.
6. dallas.example.net中的状态服务器完成订阅事务。请注意，身份验证通常会在调用流的这一点上进行。为简洁起见，省略此步骤。
Presence Server in dallas.example.net -> Local RLS
dallas.example.net中的状态服务器->本地RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
To: <sip:ed@dallas.example.net>;tag=e45TmHTh
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:dallas.example.net>
Expires: 3600
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMEyGjdG1LH
To: <sip:ed@dallas.example.net>;tag=e45TmHTh
From: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:dallas.example.net>
Expires: 3600
Content-Length: 0
7. In this example, we assume that the server at dallas.example.net doesn't have enough authorization information to reject or accept our subscription. The initial notify, therefore, contains a "Subscription-State" of "pending". Presumably, the party responsible for accepting or denying authorization for the resource is notified of this change; however, those steps are not included in this call flow for brevity.
7. 在本例中，我们假设dallas.example.net上的服务器没有足够的授权信息来拒绝或接受我们的订阅。因此，初始通知包含“待定”的“订阅状态”。据推测，负责接受或拒绝资源授权的一方已被告知该变更；但是，为了简洁起见，这些步骤不包括在这个调用流中。
Presence Server in dallas.example.net -> Local RLS
dallas.example.net中的状态服务器->本地RLS
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:dallas.example.net>
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:dallas.example.net>
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
8. The local RLS completes the NOTIFY transaction. Note that, at this point, the Local RLS has new information to report to the subscriber. Whether it chooses to report the information immediately or spool it up for later delivery is completely up to the application. For this example, we assume that the RLS will wait for a short period of time before doing so, in order to allow the subscriptions it sent out sufficient time to provide useful data.
8. 本地RLS完成NOTIFY事务。注意，此时，本地RLS有新信息要报告给订户。它是选择立即报告信息还是将其假脱机以供以后交付完全取决于应用程序。对于本例，我们假设RLS将在这样做之前等待一段短时间，以便允许其发送的订阅有足够的时间来提供有用的数据。
Local RLS -> Presence Server in dallas.example.net
本地RLS->dallas.example.net中的状态服务器
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.dallas.example.net;
branch=z9hG4bKfwpklPxmrW
From: <sip:ed@dallas.example.net>;tag=e45TmHTh
To: <sip:adam@vancouver.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.vancouver.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
9. The Local RLS subscribes to the state of the other non-local resource.
9. 本地RLS订阅其他非本地资源的状态。
Local RLS -> RLS in stockholm.example.org
本地RLS->斯德哥尔摩网站中的RLS.example.org
SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70
To: <sip:adam-friends@stockholm.example.org>
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70
To: <sip:adam-friends@stockholm.example.org>
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.vancouver.example.com>
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4gQ2VydGFp
bmx5IHlvdSBoYXZlIGJldHRlcgp0aGluZ3MgdG8gYmUgZG9p
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIHlldD8K
Identity-Info: https://vancouver.example.com/cert
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: application/pkcs7-mime
Content-Length: 0
10. The RLS in stockholm.example.org completes the SUBSCRIBE transaction. Note that authentication would normally take place at this point in the call flow. This step is omitted for brevity.
10. stockholm.example.org中的RLS完成订阅事务。请注意，身份验证通常会在调用流的这一点上进行。为简洁起见，省略此步骤。
RLS in stockholm.example.org -> Local RLS
斯德哥尔摩的RLS.example.org->本地RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:stockholm.example.org>
Expires: 3600
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKFSrAF8CZFL
To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
From: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:stockholm.example.org>
Expires: 3600
Content-Length: 0
11. In this example, we assume that the RLS in stockholm.example.org is also an authority for presence information for the users in the "stockholm.example.org" domain. The NOTIFY contains an RLMI document describing the contained buddy list, as well as presence information for those users. In this particular case, the RLS in stockholm.example.org has chosen to sign [14] the body of the NOTIFY message. As described in RFC 3851, signing is performed by creating a multipart/signed document that has two parts. The first part is the document to be signed (in this example, the multipart/related document that describes the list resource states), while the second part is the actual signature.
11. 在本例中，我们假设stockholm.example.org中的RLS也是“stockholm.example.org”域中用户状态信息的权威。NOTIFY包含一个RLMI文档，描述所包含的好友列表，以及这些用户的状态信息。在这种特殊情况下，stockholm.example.org中的RLS选择在NOTIFY消息的主体上签名[14]。如RFC 3851所述，通过创建包含两部分的多部分/签名文档来执行签名。第一部分是要签名的文档（在本例中，是描述列表资源状态的多部分/相关文档），而第二部分是实际签名。
RLS in stockholm.example.org -> Local RLS
斯德哥尔摩的RLS.example.org->本地RLS
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:stockholm.example.org>
Event: presence
Subscription-State: active;expires=3600
Require: eventlist
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038
NOTIFY sip:pres.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:stockholm.example.org>
Event: presence
Subscription-State: active;expires=3600
Require: eventlist
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
[PKCS#7在此签名]
--l3WMZaaL8NpQWGnQ4mlU--
--l3WMZaaL8NpQWGnQ4mlU--
12. The Local RLS completes the NOTIFY transaction.
12. 本地RLS完成NOTIFY事务。
Local RLS -> RLS in stockholm.example.org
本地RLS->斯德哥尔摩网站中的RLS.example.org
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.stockholm.example.org;
branch=z9hG4bKmGL1nyZfQI
From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3
To: <sip:adam@vancouver.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.vancouver.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Content-Length: 0
13. At this point, the Local RLS decides it has collected enough additional information to warrant sending a new notification to the user. Although sending a full notification would be perfectly acceptable, the RLS decides to send a partial notification instead. The RLMI document contains only information for the updated resources, as indicated by setting the "fullState" parameter to "false". To avoid corrupting the S/MIME signature on the data received from the RLS in stockholm.example.org, the local RLS copies the entire multipart/signed body as-is into the notification that it sends.
13. 在这一点上，本地RLS决定它已经收集了足够多的额外信息来保证向用户发送新的通知。尽管发送完整通知是完全可以接受的，但RLS决定改为发送部分通知。RLMI文档仅包含更新资源的信息，如将“fullState”参数设置为“false”所示。为了避免损坏从stockholm.example.org中的RLS接收的数据上的S/MIME签名，本地RLS将整个多部分/签名正文原样复制到它发送的通知中。
Local RLS -> Terminal
本地RLS->终端
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.vancouver.example.com>";
boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862
NOTIFY sip:terminal.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.vancouver.example.com>";
boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com" version="2"
fullState="false">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
<instance id="sdlkmeopdf" state="pending"/>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
<instance id="cmpqweitlp" state="active"
cid="1KQhyE@pres.vancouver.example.com"/>
</resource>
</list>
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@pres.vancouver.example.com" version="2"
fullState="false">
<name xml:lang="en">Buddy List at COM</name>
<name xml:lang="de">Liste der Freunde an COM</name>
<resource uri="sip:ed@dallas.example.net">
<name>Ed at NET</name>
<instance id="sdlkmeopdf" state="pending"/>
</resource>
<resource uri="sip:adam-friends@stockholm.example.org">
<name xml:lang="en">My Friends at ORG</name>
<name xml:lang="de">Meine Freunde an ORG</name>
<instance id="cmpqweitlp" state="active"
cid="1KQhyE@pres.vancouver.example.com"/>
</resource>
</list>
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.vancouver.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <ZPvJHL@stockholm.example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@stockholm.example.org>";
boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at ORG</name>
<name xml:lang="de">Liste der Freunde an ORG</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <Cvjpeo@stockholm.example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi"
uri="sip:adam-friends@stockholm.example.org" version="1"
fullState="true">
<name xml:lang="en">Buddy List at ORG</name>
<name xml:lang="de">Liste der Freunde an ORG</name>
<resource uri="sip:joe@stockholm.example.org">
<name>Joe Thomas</name>
<instance id="1" state="active"
cid="mrEakg@stockholm.example.org"/>
</resource>
<resource uri="sip:mark@stockholm.example.org">
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
<name>Mark Edwards</name>
<instance id="1" state="active"
cid="KKMDmv@stockholm.example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <mrEakg@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:joe@stockholm.example.org">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:mark@stockholm.example.org">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID: <K9LB7k@stockholm.example.org>
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
[PKCS#7在此签名]
--l3WMZaaL8NpQWGnQ4mlU--
--l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL--
--TfZxoxgAvLqgj4wRWPDL--
14. The terminal completes the NOTIFY transaction.
14. 终端完成通知事务。
Terminal -> Local RLS
终端->本地RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bK4EPlfSFQK1
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:terminal.vancouver.example.com>
Content-Length: 0
Note that the mechanisms for obtaining state information for resources in a list are generally left to the RLS implementor. Some of the security issues below are specific to the circumstance in which a SIP back-end subscription is used for such a purpose. Non-SIP mechanisms for obtaining state information of resources in a list will typically have their own security issues associated with doing so; however, exhaustively enumerating such access methods is not possible in this document. Implementors using such mechanisms must analyze their chosen access methods for relevant security issues.
注意，用于获取列表中资源的状态信息的机制通常留给RLS实现者。下面的一些安全问题特定于使用SIP后端订阅来实现此目的的情况。用于获取列表中资源的状态信息的非SIP机制通常具有与此相关的自身安全问题；然而，在本文档中不可能详尽列举此类访问方法。使用这种机制的实现者必须分析他们所选择的访问方法以解决相关的安全问题。
If back-end subscriptions are required to retrieve resource state information, the end user is no longer the direct subscriber to the state of the resource. This means that direct authentication of the user is no longer possible.
如果需要后端订阅来检索资源状态信息，则最终用户不再是资源状态的直接订户。这意味着不再可能对用户进行直接身份验证。
It is expected that the most common deployment of RLSes entails that the subscribers to the RLS will be in the same domain as the RLS. When this is the case, the RLS then has the ability to act as an authentication service. The role of authentication service is defined in "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [7].
预计最常见的RLS部署需要RLS的订户与RLS位于同一域中。在这种情况下，RLS随后能够充当身份验证服务。身份验证服务的角色在“会话启动协议（SIP）中的身份验证管理增强功能”中定义[7]。
At a high level, under this system, the RLS authenticates the subscriber and then includes an "Identity" header field in all of the back-end subscriptions performed on behalf of that authenticated user. This "Identity" header field cryptographically asserts that the request has been authorized to be made on behalf of the user indicated in the "From" header field.
在高级别上，在该系统下，RLS认证订户，然后在代表该认证用户执行的所有后端订阅中包括“Identity”报头字段。此“标识”标头字段以加密方式声明已授权代表“发件人”标头字段中指示的用户发出请求。
Because the ability to authenticate requests is central to the proper functioning of the network, any RLS that uses SIP back-end subscriptions to acquire information about the resources in a resource list MUST be able to act as an authentication service as defined in [7], provided that local administrative policy allows it to do so.
由于对请求进行身份验证的能力是网络正常运行的核心，任何使用SIP后端订阅来获取资源列表中资源信息的RL必须能够充当[7]中定义的身份验证服务，前提是本地管理策略允许它这样做。
In other words, all RLS implementations that support back-end SIP subscriptions also must include the ability to be configured to act as an authentication service. Whether any given administrator chooses to activate such a feature is completely up to them. Of course, lacking the ability to act as an identity server, any RLS so configured will behave as described in the following section, since it is effectively acting as if it were in a different domain than the user.
换句话说，所有支持后端SIP订阅的RLS实现还必须包括配置为充当身份验证服务的能力。是否有特定的管理员选择激活这样的功能完全取决于他们。当然，由于缺少充当身份服务器的能力，因此任何这样配置的RL都将按照以下部分中所述的方式运行，因为它实际上就像它位于与用户不同的域中一样。
In the general case, the SIP Authenticated Identity extensions do not provide a means for the RLS to securely assert that subscriptions are being performed on the end user's behalf. Specifically, when the subscriber and the RLS are in different domains, the RLS will have no means by which it can vouch for the user's identity. Mechanisms by which back-end subscriptions in such circumstances can be authenticated are left for future study.
在一般情况下，SIP认证的身份扩展不提供RLS安全地断言正在代表最终用户执行订阅的方法。具体地说，当订户和RLS在不同的域中时，RLS将没有能够证明用户身份的手段。在这种情况下，后端订阅的身份验证机制留待将来研究。
Until such general solutions are developed, RLSes that are in a different domain than the subscriber on whose behalf they are creating back-end subscriptions SHOULD subscribe to the resources using their own identity. By doing so, the RLS will generally obtain only the resource information that is made publicly available.
在开发此类通用解决方案之前，位于不同于其创建后端订阅的订阅服务器的域中的RLSE应使用自己的身份订阅资源。通过这样做，RLS通常将仅获得公开可用的资源信息。
Absent such general solutions, implementations of subscriber user agents MAY attempt direct subscriptions to resources in the resource list when subscribing to an RLS outside of their domain (either directly or by way of another resource list subscription). The resources to be subscribed to will be those indicated in the "uri" attribute of the <resource> elements present in the RLMI document returned by the RLS. Directly subscribing to the resources allows proper authentication of the user to take place, which will generally authorize them to receive more complete state information. Implementations that choose to perform such direct subscriptions SHOULD use the data retrieved instead of any information about the resource obtained via the list subscription.
在缺少此类通用解决方案的情况下，订户用户代理的实现可以在订阅其域外的RLS时尝试直接订阅资源列表中的资源（直接订阅或通过另一资源列表订阅）。要订阅的资源将是RLS返回的RLMI文档中存在的<resource>元素的“uri”属性中指示的资源。直接订阅资源允许对用户进行适当的身份验证，这通常会授权他们接收更完整的状态信息。选择执行此类直接订阅的实现应使用检索到的数据，而不是通过列表订阅获得的有关资源的任何信息。
A resource list server typically serves information to multiple subscribers at once. In many cases, resources may be present in several lists; additionally, it is quite possible that resource list servers will have two users subscribe to the same list.
资源列表服务器通常一次向多个订阅者提供信息。在许多情况下，资源可能存在于多个列表中；此外，资源列表服务器很可能会有两个用户订阅同一个列表。
In these cases, misguided RLS implementations may attempt to minimize network load by maintaining only one back-end subscription to a resource in a list and presenting the result of such a subscription to more than one user. Of course, doing so circumvents any authorization policy that the notifier for the resource maintains. Keep in mind that authorization is often much more than a simple binary "allowed/not allowed" decision; resources may render very different -- and even conflicting -- resource states, depending on the identity of the subscribing user.
在这些情况下，错误引导的RLS实现可能试图通过仅维护对列表中的资源的一个后端订阅并将这种订阅的结果呈现给多个用户来最小化网络负载。当然，这样做会绕过资源通知程序维护的任何授权策略。请记住，授权通常不仅仅是一个简单的二进制“允许/不允许”决策；根据订阅用户的身份，资源可能呈现非常不同甚至冲突的资源状态。
To prevent the transmission of event information to anyone other than the intended recipient, implementations MUST NOT present the result of one back-end subscription to more than one user, unless:
为防止将事件信息传输给预期收件人以外的任何人，实施不得将一个后端订阅的结果呈现给多个用户，除非：
a. The RLS has adequate access to the complete authorization policy associated with the resource to which the back-end subscription has been made, AND
a. RLS有足够的权限访问与已进行后端订阅的资源相关联的完整授权策略，以及
b. The RLS can and has determined that presenting the information to more than one user does not violate such policy.
b. RLS可以并且已经确定将信息呈现给多个用户并不违反该策略。
Note that this is a very difficult problem to solve correctly. Even in the cases where such access is believed possible, this mode of operation is NOT RECOMMENDED.
请注意，这是一个很难正确解决的问题。即使在认为可以访问的情况下，也不建议使用这种操作模式。
Implementors should keep in mind that any section of the MIME body may be signed and/or encrypted as necessary. Resource List Servers should take care not to modify any MIME bodies they receive from any back-end subscriptions, and should not generally rely on being able to read them.
实现者应该记住，MIME主体的任何部分都可以根据需要进行签名和/或加密。资源列表服务器应该注意不要修改它们从任何后端订阅接收到的任何MIME主体，并且通常不应该依赖于能够读取它们。
In order to facilitate security, resource list servers SHOULD pass along indication for support of "multipart/signed" and "application/ pkcs7-mime" content types to any SIP back-end subscriptions, if the subscriber includes them in the initial SUBSCRIBE message. Not doing so may actually result in resources refusing to divulge state (if notifier policy requires encryption, but the RLS fails to convey support), or subscribers discarding valid state (if subscriber policy requires a signature, but the RLS fails to convey support).
为了促进安全性，资源列表服务器应将支持“多部分/签名”和“应用程序/pkcs7 mime”内容类型的指示传递给任何SIP后端订阅（如果订阅服务器在初始订阅消息中包含这些内容类型）。不这样做实际上可能会导致资源拒绝泄露状态（如果通知程序策略需要加密，但RLS无法传递支持），或者订阅者放弃有效状态（如果订阅者策略需要签名，但RLS无法传递支持）。
Note that actual implementation of encryption and signing by the RLS is not necessary to be able to pass through signed and/or encrypted bodies.
注意，RLS的加密和签名的实际实现对于能够通过签名和/或加密的实体来说不是必需的。
One risk introduced by the ability to nest resource lists is the possibility of creating lists that ultimately contain themselves as a sub-list. Detection and handling of such a case is trivial when the RLS services all the virtual subscriptions internally. When back-end subscriptions are created to service virtual subscriptions, however, detection of such situations becomes a more difficult problem.
嵌套资源列表的能力带来的一个风险是创建最终将自身作为子列表包含的列表的可能性。当RLS在内部为所有虚拟订阅提供服务时，这种情况的检测和处理是微不足道的。但是，当创建后端订阅以服务虚拟订阅时，检测此类情况就变得更加困难。
Implementors of RLSes that create back-end subscriptions MUST implement safeguards to prevent such nestings from creating an infinite loop of subscriptions. Typically, such mechanisms will require support in the back-end subscription protocol. In particular, applying filters to the back-end subscriptions can be an effective way to preclude such problems.
创建后端订阅的RLSE的实现者必须实施保护措施，以防止此类嵌套创建无限订阅循环。通常，此类机制需要后端订阅协议中的支持。特别是，对后端订阅应用筛选器可以是防止此类问题的有效方法。
This section defines a new option tag for the registry established by Section 27.1 of RFC 3261[1].
本节为RFC 3261[1]第27.1节建立的注册表定义了一个新的选项标签。
Option Tag Name: eventlist
选项标记名称：eventlist
Description: Extension to allow subscriptions to lists of resources.
描述：允许订阅资源列表的扩展。
Published specification: RFC 4662
已发布规范：RFC 4662
MIME Media Type Name: application
MIME媒体类型名称：应用程序
MIME subtype name: rlmi+xml
MIME子类型名称：rlmi+xml
Required parameters: None
所需参数：无
Optional parameters: charset
可选参数：字符集
See RFC 3023 [12] for a discussion of the charset parameter on XML-derived MIME types. Since this MIME type is used exclusively in SIP, the use of UTF-8 encoding is strongly encouraged.
有关XML派生MIME类型上的字符集参数的讨论，请参见RFC 3023[12]。由于此MIME类型仅在SIP中使用，因此强烈鼓励使用UTF-8编码。
Encoding considerations: 8-bit text
编码注意事项：8位文本
Security considerations: Security considerations specific to uses of this MIME type are discussed in RFC 4662. RFC 1874 [11] and RFC 3023 [12] discuss security issues common to all uses of XML.
安全注意事项：RFC4662中讨论了特定于此MIME类型使用的安全注意事项。RFC 1874[11]和RFC 3023[12]讨论了所有XML使用中常见的安全问题。
Interoperability considerations: The use of this MIME body is intended to be generally interoperable. No unique considerations have been identified.
互操作性注意事项：此MIME正文的使用旨在实现一般的互操作性。没有确定独特的考虑因素。
Published specification: RFC 4662
已发布规范：RFC 4662
Applications that use this media type: This media type is used to convey meta-information for the state of lists of resources within a Session Initiation Protocol (SIP) subscription.
使用此媒体类型的应用程序：此媒体类型用于传递会话启动协议（SIP）订阅中资源列表状态的元信息。
Additional information: Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None. Object Identifier(s) or OID(s): None.
其他信息：幻数：无。文件扩展名：无。Macintosh文件类型代码：无。对象标识符或OID：无。
Intended usage: Limited Use
预期用途：有限用途
Other Information/General Comment: None.
其他信息/一般性意见：无。
Person to contact for further information: Name: Adam Roach E-Mail: adam@estacado.net Author/Change Controller: The specification of this MIME type is a work product of the SIMPLE working group and was authored by Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has change control over its specification.
有关详细信息的联系人：姓名：Adam Roach电子邮件：adam@estacado.net作者/变更控制者：此MIME类型的规范是简单工作组的工作成果，由Adam Roach、Jonathan Rosenberg和Ben Campbell编写。IETF对其规范具有变更控制权。
URI: urn:ietf:params:xml:ns:rlmi
URI: urn:ietf:params:xml:ns:rlmi
Description: This is the XML namespace URI for XML elements defined by RFC 4662 to describe information about subscriptions when such subscriptions are aggregated within a single SIP subscription. It is used in the application/rlmi+xml body type.
描述：这是RFC4662定义的XML元素的XML名称空间URI，用于描述在单个SIP订阅中聚合订阅时有关订阅的信息。它用于application/rlmi+xml主体类型。
Registrant Contact: Name: Adam Roach E-Mail: adam@estacado.net Author/Change Controller: The specification of this MIME type is a work product of the SIMPLE working group and was authored by Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has change control over its specification.
注册人联系人：姓名：Adam Roach电子邮件：adam@estacado.net作者/变更控制者：此MIME类型的规范是简单工作组的工作成果，由Adam Roach、Jonathan Rosenberg和Ben Campbell编写。IETF对其规范具有变更控制权。
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=utf-8"/>
<title>Namespace for SIP Event Resource List
Meta-Information</title>
</head>
<body>
<h1>Namespace for SIP Event Resource List
Meta-Information</h1>
<h2>application/rlmi+xml</h2>
<p>See <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]">
RFC4662</a>.</p>
</body>
</html>
END
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=utf-8"/>
<title>Namespace for SIP Event Resource List
Meta-Information</title>
</head>
<body>
<h1>Namespace for SIP Event Resource List
Meta-Information</h1>
<h2>application/rlmi+xml</h2>
<p>See <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]">
RFC4662</a>.</p>
</body>
</html>
END
Thanks to Sean Olson for a review of and corrections to the usage of XML in this protocol.
感谢Sean Olson对此协议中XML的使用进行了回顾和更正。
Thanks also to Hisham Khartabil, Paul Kyzivat, Keith Drage, and Robert Sparks for their careful reviews of and comments on this document.
还感谢Hisham Khartabil、Paul Kyzivat、Keith Drage和Robert Sparks对本文件的仔细审查和评论。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[3] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[4] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[6] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[7] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[9] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9] Burger，E.，“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[10] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[10] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
[11] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[11] Levinson，E.，“SGML媒体类型”，RFC1874，1995年12月。
[12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[12] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[13] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[14] Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[15] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
Authors' Addresses
作者地址
Adam Roach Estacado Systems US
Adam Roach Estacado系统美国公司
EMail: adam@estacado.net
EMail: adam@estacado.net
Ben Campbell Estacado Systems US
Ben Campbell Estacado系统美国公司
EMail: ben@estacado.net
EMail: ben@estacado.net
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054-2711
EMail: jdrosen@cisco.com
EMail: jdrosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。