Network Working Group J. Rosenberg
Request for Comments: 5025 Cisco
Category: Standards Track December 2007
Network Working Group J. Rosenberg
Request for Comments: 5025 Cisco
Category: Standards Track December 2007
Presence Authorization Rules
存在授权规则
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted.
授权是存在系统中的一项关键功能。授权策略（也称为授权规则）指定可以向哪些观察者提供哪些状态信息以及何时提供。本规范定义了一种可扩展标记语言（XML）文档格式，用于表示状态授权规则。尽管允许使用其他技术，但客户机可以使用XML配置访问协议（XCAP）操纵此类文档。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Structure of Presence Authorization Documents ...................3
3.1. Conditions .................................................4
3.1.1. Identity ............................................4
3.1.1.1. Acceptable Forms of Authentication .........4
3.1.1.2. Computing a URI for the Watcher ............5
3.1.2. Sphere ..............................................6
3.2. Actions ....................................................7
3.2.1. Subscription Handling ...............................7
3.3. Transformations ............................................9
3.3.1. Providing Access to Data Component Elements .........9
3.3.1.1. Device Information .........................9
3.3.1.2. Person Information ........................10
3.3.1.3. Service Information .......................11
3.3.2. Providing Access to Presence Attributes ............12
3.3.2.1. Provide Activities ........................12
3.3.2.2. Provide Class .............................12
3.3.2.3. Provide DeviceID ..........................13
3.3.2.4. Provide Mood ..............................13
3.3.2.5. Provide Place-is ..........................13
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Structure of Presence Authorization Documents ...................3
3.1. Conditions .................................................4
3.1.1. Identity ............................................4
3.1.1.1. Acceptable Forms of Authentication .........4
3.1.1.2. Computing a URI for the Watcher ............5
3.1.2. Sphere ..............................................6
3.2. Actions ....................................................7
3.2.1. Subscription Handling ...............................7
3.3. Transformations ............................................9
3.3.1. Providing Access to Data Component Elements .........9
3.3.1.1. Device Information .........................9
3.3.1.2. Person Information ........................10
3.3.1.3. Service Information .......................11
3.3.2. Providing Access to Presence Attributes ............12
3.3.2.1. Provide Activities ........................12
3.3.2.2. Provide Class .............................12
3.3.2.3. Provide DeviceID ..........................13
3.3.2.4. Provide Mood ..............................13
3.3.2.5. Provide Place-is ..........................13
3.3.2.6. Provide Place-type ........................13
3.3.2.7. Provide Privacy ...........................13
3.3.2.8. Provide Relationship ......................14
3.3.2.9. Provide Sphere ............................14
3.3.2.10. Provide Status-Icon ......................14
3.3.2.11. Provide Time-Offset ......................14
3.3.2.12. Provide User-Input .......................14
3.3.2.13. Provide Note .............................15
3.3.2.14. Provide Unknown Attribute ................15
3.3.2.15. Provide All Attributes ...................16
4. When to Apply the Authorization Policies .......................17
5. Implementation Requirements ....................................17
6. Example Document ...............................................18
7. XML Schema .....................................................19
8. Schema Extensibility ...........................................21
9. XCAP Usage .....................................................22
9.1. Application Unique ID .....................................22
9.2. XML Schema ................................................22
9.3. Default Namespace .........................................22
9.4. MIME Type .................................................22
9.5. Validation Constraints ....................................22
9.6. Data Semantics ............................................22
9.7. Naming Conventions ........................................23
9.8. Resource Interdependencies ................................23
9.9. Authorization Policies ....................................23
10. Security Considerations .......................................23
11. IANA Considerations ...........................................24
11.1. XCAP Application Usage ID ................................24
11.2. URN Sub-Namespace Registration ...........................25
11.3. XML Schema Registrations .................................25
12. Acknowledgements ..............................................26
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................27
3.3.2.6. Provide Place-type ........................13
3.3.2.7. Provide Privacy ...........................13
3.3.2.8. Provide Relationship ......................14
3.3.2.9. Provide Sphere ............................14
3.3.2.10. Provide Status-Icon ......................14
3.3.2.11. Provide Time-Offset ......................14
3.3.2.12. Provide User-Input .......................14
3.3.2.13. Provide Note .............................15
3.3.2.14. Provide Unknown Attribute ................15
3.3.2.15. Provide All Attributes ...................16
4. When to Apply the Authorization Policies .......................17
5. Implementation Requirements ....................................17
6. Example Document ...............................................18
7. XML Schema .....................................................19
8. Schema Extensibility ...........................................21
9. XCAP Usage .....................................................22
9.1. Application Unique ID .....................................22
9.2. XML Schema ................................................22
9.3. Default Namespace .........................................22
9.4. MIME Type .................................................22
9.5. Validation Constraints ....................................22
9.6. Data Semantics ............................................22
9.7. Naming Conventions ........................................23
9.8. Resource Interdependencies ................................23
9.9. Authorization Policies ....................................23
10. Security Considerations .......................................23
11. IANA Considerations ...........................................24
11.1. XCAP Application Usage ID ................................24
11.2. URN Sub-Namespace Registration ...........................25
11.3. XML Schema Registrations .................................25
12. Acknowledgements ..............................................26
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................27
The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity [17], in order to learn their presence information [18]. This subscription is handled by a presence agent. However, presence information is sensitive, and a presence agent needs authorization from the presentity prior to handing out presence information. As such, a presence authorization document format is needed. This specification defines a format for such a document, called a presence authorization document.
即时消息和状态（简单）规范的会话发起协议（SIP）允许称为观察者的用户订阅称为状态实体的另一用户[17]，以便了解其状态信息[18]。此订阅由状态代理处理。然而，存在信息是敏感的，并且存在代理在分发存在信息之前需要来自存在实体的授权。因此，需要存在授权文档格式。本规范定义了此类文档的格式，称为状态授权文档。
[8] specifies a framework for representing authorization policies, and is applicable to systems such as geo-location and presence. This framework is used as the basis for presence authorization documents. In the framework, an authorization policy is a set of rules. Each rule contains conditions, actions, and transformations. The conditions specify under what conditions the rule is to be applied to presence server processing. The actions element tells the server what actions to take. The transformations element indicates how the presence data is to be manipulated before being presented to that watcher, and as such, defines a privacy filtering operation. [8] identifies a small number of specific conditions common to presence and location services, and leaves it to other specifications, such as this one, to fill in usage specific details.
[8] 指定用于表示授权策略的框架，并适用于地理位置和状态等系统。此框架用作存在授权文档的基础。在该框架中，授权策略是一组规则。每个规则都包含条件、操作和转换。这些条件指定在何种条件下将规则应用于状态服务器处理。actions元素告诉服务器要采取的操作。transformations元素指示在呈现给该观察者之前如何操作状态数据，并因此定义隐私过滤操作。[8] 标识状态和位置服务共有的少量特定条件，并将其留给其他规范（如本规范）来填写特定于使用情况的详细信息。
A presence authorization document can be manipulated by clients using several means. One such mechanism is the XML Configuration Access Protocol (XCAP) [2]. This specification defines the details necessary for using XCAP to manage presence authorization documents.
客户可以通过多种方式操纵状态授权文档。其中一种机制是XML配置访问协议（XCAP）[2]。本规范定义了使用XCAP管理状态授权文档所需的详细信息。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释，并指出符合性实施的要求级别。
A presence authorization document is an XML document, formatted according to the schema defined in [8]. Presence authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in [8], this document is composed of rules that contain three parts - conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant of information to the watcher. As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism is privacy safe, since the lack of any action or transformation can only result in less information being presented to a watcher.
状态授权文档是根据[8]中定义的模式格式化的XML文档。状态授权文档继承通用策略文档的MIME类型，即应用程序/auth策略+xml。如[8]所述，本文档由包含三个部分的规则组成——条件、操作和转换。每一个动作或转换，也称为许可，都具有向观察者授予信息的积极性质。因此，有一个定义良好的机制来组合从多个源获得的操作和转换。这种机制是隐私安全的，因为缺少任何操作或转换只会导致向观察者提供的信息减少。
This section defines the new conditions, actions, and transformations defined by this specification.
本节定义了本规范定义的新条件、操作和转换。
Although the <identity> element is defined in [8], that specification indicates that the specific usages of the framework document need to define details that are protocol and usage specific. In particular, it is necessary for a usage of the common policy framework to:
尽管[8]中定义了<identity>元素，但该规范指出框架文档的特定用法需要定义特定于协议和用法的细节。特别是，使用共同政策框架有必要：
o Define acceptable means of authentication.
o 定义可接受的身份验证方法。
o Define the procedure for representing the identity of the WR (Watcher/Requestor) as a URI or Internationalized Resource Identifier (IRI) [13].
o 定义将WR（观察者/请求者）的标识表示为URI或国际化资源标识符（IRI）[13]的过程。
This sub-section defines those details for systems based on [18]. It does so in general terms, so that the recommendations defined here apply to existing and future authentication mechanisms in SIP.
本小节定义了基于[18]的系统的详细信息。一般来说，它是这样做的，因此这里定义的建议适用于SIP中现有和未来的身份验证机制。
When used with SIP, a request is considered authenticated if one of the following is true:
当与SIP一起使用时，如果满足以下条件之一，则认为请求已通过身份验证：
The watcher proves its identity to the server through a form of cryptographic authentication, including authentication based on a shared secret or a certificate, and that authentication yields an identity for the watcher.
观察者通过一种加密身份验证（包括基于共享秘密或证书的身份验证）向服务器证明其身份，并且该身份验证为观察者生成一个身份。
The request comes from a sender that is asserting the identity of the watcher, and:
请求来自断言观察者身份的发送者，并且：
1. the assertion includes a claim that the asserting party used a form of cryptographic authentication (as defined above) to determine the identity of the watcher, and
1. 断言包括断言方使用某种形式的加密身份验证（如上所述）来确定观察者的身份的声明，以及
2. the server trusts that assertion, and
2. 服务器信任该断言，并且
3. the assertion provides an identity in the form of a URI.
3. 断言以URI的形式提供标识。
Based on this definition, examples of valid authentication techniques include SIP [5], digest authentication [4], cryptographically verified identity assertions (RFC 4474 [15]), and identity assertions made in closed network environments (RFC 3325 [16]).
基于此定义，有效身份验证技术的示例包括SIP[5]、摘要身份验证[4]、加密验证身份断言（RFC 4474[15]）和在封闭网络环境中进行的身份断言（RFC 3325[16]）。
However, the anonymous authentication described on page 194 of RFC 3261 [5] is not considered a valid mechanism for authentication
但是，RFC 3261[5]第194页所述的匿名身份验证不被视为有效的身份验证机制
because it does not produce an identity for the watcher. However, an anonymous From header field, when used in conjunction with RFC 4474 [15], is considered an acceptable mechanism for authentication, since it still implies that the asserting node performed authentication that produced the identity of the watcher.
因为它不会为观察者生成身份。然而，当与RFC 4474[15]结合使用时，匿名自报头字段被认为是一种可接受的身份验证机制，因为它仍然意味着断言节点执行了产生观察者身份的身份验证。
Computing the URI for the watcher depends on whether the identity is being ascertained through authentication or through an asserted identity.
计算观察者的URI取决于身份是通过身份验证还是通过断言的身份来确定。
If an identity assertion is being utilized, the asserted identity itself (which is in the form of a URI for acceptable forms of identity assertion) is utilized as the URI. If the identity assertion mechanism asserts multiple URIs for the watcher, then each of them is used for the comparisons outlined in [8], and if any of them match a <one> or <except> element, the watcher is considered a match.
如果正在使用标识断言，则所断言的标识本身（对于可接受的标识断言形式，其形式为URI）将用作URI。如果标识断言机制为观察者断言多个URI，则每个URI都用于[8]中概述的比较，如果其中任何URI与<one>或<except>元素匹配，则观察者被视为匹配。
If an identity is being determined directly by a cryptographic authentication, that authentication must produce a URI, or must produce some form of identifier that can be linked, through provisioning, to a URI that is bound to that identifier.
如果身份直接由加密身份验证确定，则该身份验证必须生成URI，或者必须生成某种形式的标识符，该标识符可以通过设置链接到绑定到该标识符的URI。
For example, in the case of SIP Digest authentication, the authentication process produces a username scoped within a realm. That username and realm are bound to an Address of Record (AOR) through provisioning, and the resulting AOR is used as the watcher URI. Consider the following "user record" in a database:
例如，在SIP摘要身份验证的情况下，身份验证过程会生成一个作用域内的用户名。该用户名和域通过设置绑定到记录地址（AOR），并将生成的AOR用作观察者URI。考虑以下数据库中的“用户记录”：
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
If the presence server receives a SUBSCRIBE request, challenges it with the realm set to "example.com", and the subsequent SUBSCRIBE contains an Authorization header field with a username of "ali" and a digest response generated with the password "f779ajvvh8a6s6", the identity used in matching operations is "sip:alice@example.com".
如果状态服务器接收到一个订阅请求，并使用设置为“example.com”的域对其进行质询，随后的订阅包含一个用户名为“ali”的授权标头字段和一个使用密码“f779ajvvh8a6s6”生成的摘要响应，则匹配操作中使用的标识为“sip:alice@example.com".
In SIP systems, it is possible for a user to have aliases - that is, there are multiple SIP AORs "assigned" to a single user. In terms of this specification, there is no relationship between those aliases. Each would look like a different user. This will be the consequence for systems where the watcher is in a different domain than the presentity. However, even if the watcher and presentity are in the
在SIP系统中，用户可能有别名，也就是说，有多个SIP AOR“分配”给单个用户。根据本规范，这些别名之间没有关系。每个人看起来都像不同的用户。这将是观察者与存在实体处于不同领域的系统的后果。然而，即使观察者和存在实体处于
same domain, and the presence server knows that there are aliases for the watcher, these aliases are not mapped to each other or used in any way.
同一个域，并且状态服务器知道观察者有别名，这些别名不会相互映射或以任何方式使用。
SIP also allows for anonymous requests. If a request is anonymous because the watcher utilized an authentication mechanism that does not provide an identity to the presence server (such as the SIP digest "anonymous" username), the request is considered unauthenticated (as discussed above) and will match only an empty <identity> element. If a request is anonymous because it contains a Privacy header field [14], but still contains an asserted identity meeting the criteria defined above, that identity is utilized, and the fact that the request was anonymous has no impact on the identity processing.
SIP还允许匿名请求。如果请求是匿名的，因为观察者使用的身份验证机制不向状态服务器提供身份（例如SIP摘要“匿名”用户名），则该请求被视为未经身份验证（如上所述），并且将仅匹配空的<identity>元素。如果请求是匿名的，因为它包含隐私头字段[14]，但仍然包含符合上述定义标准的断言标识，则该标识将被使用，并且请求是匿名的这一事实对标识处理没有影响。
It is important to note that SIP frequently uses both SIP URI and tel URI [12] as identifiers, and to make matters more confusing, a SIP URI can contain a phone number in its user part, in the same format used in a tel URI. A WR identity that is a SIP URI with a phone number will NOT match the <one> and <except> conditions whose 'id' is a tel URI with the same number. The same is true in the reverse. If the WR identity is a tel URI, this will not match a SIP URI in the <one> or <except> conditions whose user part is a phone number. URIs of different schemes are never equivalent.
需要注意的是，SIP经常使用SIP URI和tel URI[12]作为标识符，并且为了使事情更加混乱，SIP URI可以在其用户部分包含电话号码，格式与tel URI中使用的格式相同。作为具有电话号码的SIP URI的WR标识将与“id”为具有相同号码的电话URI的<one>和<Exception>条件不匹配。反之亦然。如果WR标识是电话URI，则这将与用户部分为电话号码的<one>或<except>条件中的SIP URI不匹配。不同方案的URI永远不会相等。
The <sphere> element is defined in [8]. However, each application making use of the common policy specification needs to determine how the presence server computes the value of the <sphere> to be used in the evaluation of the condition.
[8]中定义了<sphere>元素。但是，使用公共策略规范的每个应用程序都需要确定状态服务器如何计算要在条件评估中使用的<sphere>的值。
To compute the value of <sphere>, the presence agent examines all published presence documents for the presentity. If at least one of them includes the <sphere> element [9] as part of the person data component [10], and all of those containing the element have the same value for it, which is the value used for the <sphere> in presence policy processing. If, however, the <sphere> element was not present in any of the published documents, or it was present but had inconsistent values, its value is considered undefined in terms of presence policy processing.
为了计算<sphere>的值，presence agent检查所有已发布的presence实体的presence文档。如果其中至少有一个包含<sphere>元素[9]作为个人数据组件[10]的一部分，并且包含该元素的所有元素都具有相同的值，即用于在场状态下<sphere>策略处理的值。但是，如果<sphere>元素不存在于任何已发布文档中，或者它存在但具有不一致的值，则其值在状态策略处理方面被视为未定义。
Care must be taken in using <sphere> as a condition for determining the subscription handling. Since the value of <sphere> changes dynamically, a state change can cause a subscription to be suddenly terminated. The watcher has no way to know, aside from polling, when their subscription would be reinstated as the value of <sphere>
在使用<sphere>作为确定订阅处理的条件时必须小心。由于<sphere>的值是动态变化的，因此状态变化可能会导致订阅突然终止。除了轮询之外，观察者无法知道他们的订阅何时会恢复为<sphere>的值
changes. For this reason, <sphere> is primarily useful for matching on rules that define transformations.
变化。因此，<sphere>主要用于匹配定义转换的规则。
The <sub-handling> element specifies the subscription authorization decision that the server should make. It also specifies whether or not the presence document for the watcher should be constructed using "polite blocking". Usage of polite blocking and the subscription authorization decision are specified jointly since proper privacy handling requires a correlation between them. As discussed in [8], since the combination algorithm runs independently for each permission, if correlations exist between permissions, they must be merged into a single variable. That is what is done here. The <sub-handling> element is an enumerated Integer type. The defined values are:
元素指定服务器应该做出的订阅授权决策。它还指定是否应使用“礼貌阻止”构造观察者的状态文档。礼貌阻止和订阅授权决策的使用是共同指定的，因为正确的隐私处理需要它们之间的关联。如[8]所述，由于组合算法对每个权限独立运行，因此如果权限之间存在相关性，则必须将它们合并为单个变量。这就是我们在这里所做的。<sub handling>元素是枚举整数类型。定义的值为：
block: This action tells the server to reject the subscription, placing it in the "terminated" state. It has the value of zero, and it represents the default value. No value of the <sub-handling> element can ever be lower than this. Strictly speaking, it is not necessary for a rule to include an explicit block action, since the default in the absence of any action will be block. However, it is included for completeness.
block：此操作告诉服务器拒绝订阅，使其处于“已终止”状态。它的值为零，表示默认值。<sub handling>元素的任何值都不能低于此值。严格地说，规则没有必要包含显式的阻止操作，因为在没有任何操作的情况下，默认设置为阻止。但是，为了完整性，将其包括在内。
confirm: This action tells the server to place the subscription in the "pending" state, and await input from the presentity to determine how to proceed. It has a value of ten.
确认：此操作告诉服务器将订阅置于“挂起”状态，并等待presentity的输入以确定如何继续。它的值是10。
polite-block: This action tells the server to place the subscription into the "active" state, and to produce a presence document that indicates that the presentity is unavailable. A reasonable document would exclude device and person information elements, and include only a single service whose basic status is set to closed [3]. This action has a value of twenty.
礼貌阻止：此操作告诉服务器将订阅置于“活动”状态，并生成一个表示该实体不可用的状态文档。一个合理的文档将排除设备和人员信息元素，并且只包括一个基本状态设置为关闭的服务[3]。此操作的值为20。
allow: This action tells the server to place the subscription into the "active" state. This action has a value of thirty.
允许：此操作告诉服务器将订阅置于“活动”状态。此操作的值为30。
NOTE WELL: Placing a value of block for this element does not guarantee that a subscription is denied! If any matching rule has any other value for this element, the subscription will receive treatment based on the maximum of those other values. This is based on the combining rules defined in [8].
请注意：为该元素设置block值并不保证订阅被拒绝！如果任何匹配规则对此元素具有任何其他值，则订阅将根据这些其他值的最大值接受处理。这是基于[8]中定义的组合规则。
Future specifications that wish to define new types of actions MUST define an entirely new action (separate from <sub-handling>), and define their own set of values for that action. A document could contain both <sub-handling> and a subscription handling action defined by a future specification; in that case, since each action is always a positive grant of information, the resulting action is the least restrictive one across both elements.
希望定义新类型操作的未来规范必须定义一个全新的操作（与<sub handling>不同），并为该操作定义自己的一组值。文档可以包含<sub-handling>和未来规范定义的订阅处理操作；在这种情况下，由于每个动作始终是信息的正向授予，因此产生的动作是两个元素中限制最少的动作。
The exact behavior of a presence server upon a change in the sub-handling value can be described by utilizing the subscription processing state machine in Figure 1 of RFC 3857 [6].
通过使用RFC 3857[6]图1中的订阅处理状态机，可以描述状态服务器在子处理值发生变化时的确切行为。
If the <sub-handling> permission changes value to "block", this causes a "rejected" event to be generated into the subscription state machine for all affected subscriptions. This will cause the state machine to move into the "terminated" state, resulting in the transmission of a NOTIFY to the watcher with a Subscription-State header field with value "terminated" and a reason of "rejected" [7], which terminates their subscription. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "block", the subscription processing follows the "subscribe, policy=reject" branch from the "init" state, and a 403 response to the SUBSCRIBE is generated.
如果<sub handling>权限将值更改为“block”，这将导致在订阅状态机中为所有受影响的订阅生成“拒绝”事件。这将导致状态机进入“终止”状态，从而向观察者发送通知，其中订阅状态标头字段的值为“终止”，原因为“拒绝”[7]，从而终止其订阅。如果新订阅稍后到达，并且应用于该订阅的<sub handling>的值为“block”，则订阅处理遵循“init”状态的“subscribe，policy=reject”分支，并生成对订阅的403响应。
If the <sub-handling> permission changes value to "confirm", the processing depends on the states of the affected subscriptions. Unfortunately, the state machine in RFC 3857 does not define an event corresponding to an authorization decision of "pending". If the subscription is in the "active" state, it moves back into the "pending" state. This causes a NOTIFY to be sent, updating the Subscription-State [7] to "pending". No reason is included in the Subscription-State header field (none are defined to handle this case). No further documents are sent to this watcher. There is no change in state if the subscription is in the "pending", "waiting", or "terminated" states. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "confirm", the subscription processing follows the "subscribe, no policy" branch from the "init" state, and a 202 response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of "pending". No presence document is included in that NOTIFY.
如果<sub handling>权限将值更改为“confirm”，则处理取决于受影响订阅的状态。不幸的是，RFC3857中的状态机没有定义与“待定”授权决策对应的事件。如果订阅处于“活动”状态，它将移回“挂起”状态。这会导致发送通知，将订阅状态[7]更新为“待定”。订阅状态标头字段中不包含任何原因（未定义任何原因来处理此情况）。不会向该观察者发送进一步的文档。如果订阅处于“挂起”、“等待”或“终止”状态，则状态不会发生变化。如果新订阅稍后到达，并且应用于该订阅的<sub handling>的值为“confirm”，则订阅处理遵循“init”状态的“subscribe，no policy”分支，并生成对订阅的202响应，随后是订阅状态为“pending”的NOTIFY。该通知中不包含出席文件。
If the <sub-handling> permission changes value from "blocked" or "confirm" to "polite-block" or "allow", this causes an "approved" event to be generated into the state machine for all affected subscriptions. If the subscription was in the "pending" state, the state machine will move to the "active" state, resulting in the transmission of a NOTIFY with a Subscription-State header field of "active", and the inclusion of a presence document in that NOTIFY.
如果<sub handling>权限将值从“blocked”或“confirm”更改为“little block”或“allow”，这将导致在状态机中为所有受影响的订阅生成“approved”事件。如果订阅处于“挂起”状态，状态机将移动到“活动”状态，从而发送订阅状态标题字段为“活动”的通知，并在该通知中包含状态文档。
If the subscription was in the "waiting" state, it will move into the "terminated" state. If a new subscription arrives later on, and the value of <sub-handling> that applies to that subscription is "polite-block" or "allow", the subscription processing follows the "subscribe, policy=accept" branch from the "init" state, and a 200 OK response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of "active" with a presence document in the body of the NOTIFY.
如果订阅处于“等待”状态，它将进入“终止”状态。如果新订阅稍后到达，且应用于该订阅的<sub handling>值为“礼貌阻止”或“允许”，则订阅处理遵循“init”状态的“subscribe，policy=accept”分支，并生成对订阅的200 OK响应，然后是订阅状态为“active”的通知通知正文中有出席文件。
The transformations defined here are used to drive the behavior of the privacy filtering operation. Each transformation defines the visibility a watcher is granted to a particular component of the presence document. One group of transformations grants visibility to person, device, and service data elements based on identifying information for those elements. Another group of transformations provides access to particular data elements in the presence document.
这里定义的转换用于驱动隐私过滤操作的行为。每个转换都定义了观察者被授予状态文档特定组件的可见性。一组转换基于个人、设备和服务数据元素的标识信息，为这些元素提供可见性。另一组转换提供对状态文档中特定数据元素的访问。
The transformations in this section provide access to person, device, and service data component elements. Once access has been granted to such an element, access to specific presence attributes for that element is controlled by the permissions defined in Section 3.3.2.
本节中的转换提供对人员、设备和服务数据组件元素的访问。一旦授予了对该元素的访问权，对该元素特定状态属性的访问权将由第3.3.2节中定义的权限控制。
The <provide-devices> permission allows a watcher to see <device> information present in the presence document. It is a set variable. Each member of the set provides a way to identify a device or group of devices. This specification defines three types of elements in the set - <class>, which identifies a device occurrence by class; <deviceID>, which identifies a device occurrence by device ID; and <occurrence-id>, which identifies a device occurrence by occurrence ID. The device ID and occurrence ID are defined in [10]. Each member of the set is identified by its type (class, deviceID, or occurrence-id) and value (value of the class, value of the deviceID, or value of the occurrence-id).
<provide devices>权限允许观察者查看状态文档中的<device>信息。它是一个集合变量。集合中的每个成员都提供了一种识别设备或设备组的方法。本规范在集合中定义了三种类型的元素-<class>，它们按类别标识设备出现<deviceID>，它通过设备ID标识设备事件；和<事件id>，它通过事件id标识设备事件。设备id和事件id在[10]中定义。集合的每个成员由其类型（类、设备id或事件id）和值（类的值、设备id的值或事件id的值）标识。
For example, consider the following <provide-devices> element:
例如，考虑下面的<提供设备>元素：
<provide-devices>
<deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID>
<class>biz</class>
</provide-devices>
<provide-devices>
<deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID>
<class>biz</class>
</provide-devices>
This set has two members. This is combined with a <provide-devices> element from a different rule:
这个集合有两个成员。这与来自不同规则的<provide devices>元素组合：
<provide-devices>
<class>home</class>
<class>biz</class>
</provide-devices>
<provide-devices>
<class>home</class>
<class>biz</class>
</provide-devices>
The result of the set combination (using the union operation) is a set with three elements:
集合组合（使用并集运算）的结果是一个包含三个元素的集合：
<provide-devices>
<class>home</class>
<class>biz</class>
<deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID>
</provide-devices>
<provide-devices>
<class>home</class>
<class>biz</class>
<deviceID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</deviceID>
</provide-devices>
The <provide-devices> element can also take on the special value <all-devices>, which is a short-hand notation for all device occurrences present in the presence document.
<provide devices>元素还可以采用特殊值<all devices>，这是表示状态文档中出现的所有设备的简写符号。
Permission is granted to see a particular device occurrence if one of the device identifiers in the set identifies that device occurrence. If a <class> permission is granted to the watcher, and the <class> of the device occurrence matches the value of the <class> permission based on case-sensitive equality, the device occurrence is included in the presence document. If a <deviceID> permission is granted to the watcher, and the <deviceID> of the device occurrence matches the value of the <deviceID> permission based on URI equivalence, the device occurrence is included in the presence document. If an <occurrence-id> permission is granted to the watcher, and the <occurrence-id> of the device occurrence matches the value of the <occurrence-id> permission based on case-sensitive equality, the device occurrence is included in the presence document. In addition, a device occurrence is included in the presence document if the <all-devices> permission was granted to the watcher.
如果集合中的一个设备标识符标识了某个设备事件，则授予查看该设备事件的权限。如果向观察者授予<class>权限，并且设备出现的<class>与基于区分大小写的相等性的<class>权限值匹配，则设备出现将包含在状态文档中。如果将<deviceID>权限授予观察者，并且设备出现的<deviceID>与基于URI等价性的<deviceID>权限值匹配，则设备出现将包含在状态文档中。如果向观察者授予<occurrence id>权限，并且设备事件的<occurrence id>与基于区分大小写的相等性的<occurrence id>权限值匹配，则设备事件将包含在状态文档中。此外，如果向观察者授予了<all devices>权限，则存在文档中将包含设备事件。
The <provide-persons> permission allows a watcher to see the <person>
information present in the presence document. It is a set variable.
Each member of the set provides a way to identify a person
occurrence. This specification defines two types of elements in the
set - <class>, which identifies a person occurrence by class, and
<occurrence-id>, which identifies an occurrence by its occurrence ID.
Each member of the set is identified by its type (class or
occurrence-id) and value (value of the class or value of the
occurrence-id). The <provide-persons> element can also take on the
The <provide-persons> permission allows a watcher to see the <person>
information present in the presence document. It is a set variable.
Each member of the set provides a way to identify a person
occurrence. This specification defines two types of elements in the
set - <class>, which identifies a person occurrence by class, and
<occurrence-id>, which identifies an occurrence by its occurrence ID.
Each member of the set is identified by its type (class or
occurrence-id) and value (value of the class or value of the
occurrence-id). The <provide-persons> element can also take on the
special value <all-persons>, which is a short-hand notation for all person occurrences present in the presence document. The set combination is done identically to the <provide-devices> element.
特殊值<all persons>，是状态文档中出现的所有人员的简写符号。集合组合的完成方式与<provide devices>元素相同。
Permission is granted to see a particular person occurrence if one of the person identifiers in the set identifies that person occurrence. If a <class> permission is granted to the watcher, and the <class> of the person occurrence matches the value of the <class> permission based on case-sensitive equality, the person occurrence is included in the presence document. If an <occurrence-id> permission is granted to the watcher, and the <occurrence-id> of the person occurrence matches the value of the <occurrence-id> permission based on case-sensitive equality, the person occurrence is included in the presence document. In addition, a person occurrence is included in the presence document if the <all-persons> permission was granted to the watcher.
如果集合中的一个人员标识符标识了某个人员事件，则授予查看该人员事件的权限。如果向观察者授予<class>权限，并且人员事件的<class>与基于区分大小写的相等性的<class>权限值匹配，则人员事件将包含在状态文档中。如果向观察者授予<occurrence id>权限，并且人员事件的<occurrence id>与基于区分大小写的相等性的<occurrence id>权限值匹配，则人员事件将包含在状态文档中。此外，如果向观察者授予了<all persons>权限，则人员事件将包含在状态文档中。
The <provide-services> permission allows a watcher to see service information present in <tuple> elements in the presence document. Like <provide-devices>, it is a set variable. Each member of the set provides a way to identify a service occurrence. This specification defines four types of elements in the set - <class>, which identifies a service occurrence by class; <occurrence-id>, which identifies a service by its occurrence ID; <service-uri>, which identifies a service by its service URI; and <service-uri-scheme>, which identifies a service by its service URI scheme. Each member of the set is identified by its type (class, occurrence-id, service-uri, or service-uri-scheme) and value (value of the class, value of the occurrence-id, value of the service-uri, or value of the service-uri-scheme). The <provide-services> element can also take on the special value <all-services>, which is a short-hand notation for all service occurrences present in the presence document. The set combination is done identically to the <provide-persons> element.
<provide services>权限允许观察者查看状态文档中<tuple>元素中的服务信息。与<provide devices>类似，它是一个集合变量。集合的每个成员都提供了一种识别服务事件的方法。本规范在集合中定义了四种类型的元素-<class>，它们按类标识服务事件<事件id>，它通过事件id标识服务<服务uri>，它通过服务uri标识服务；和<service uri scheme>，它通过服务uri方案标识服务。集合的每个成员由其类型（类、事件id、服务uri或服务uri方案）和值（类的值、事件id的值、服务uri的值或服务uri方案的值）标识。<provide services>元素还可以采用特殊值<all services>，这是表示状态文档中出现的所有服务事件的简写符号。集合组合与<provide persons>元素相同。
Permission is granted to see a particular service occurrence if one
of the service identifiers in the set identifies that service
occurrence. If a <class> permission is granted to the watcher, and
the <class> of the service occurrence matches the value of the
<class> permission based on case-sensitive equality, the service
occurrence is included in the presence document. If a <service-uri>
permission is granted to the watcher, and the <service-uri> of the
service occurrence matches the value of the <service-uri> permission
based on URI equivalence, the service occurrence is included in the
presence document. If an <occurrence-id> permission is granted to
the watcher, and the <occurrence-id> of the service occurrence
matches the value of the <occurrence-id> permission based on case-
Permission is granted to see a particular service occurrence if one
of the service identifiers in the set identifies that service
occurrence. If a <class> permission is granted to the watcher, and
the <class> of the service occurrence matches the value of the
<class> permission based on case-sensitive equality, the service
occurrence is included in the presence document. If a <service-uri>
permission is granted to the watcher, and the <service-uri> of the
service occurrence matches the value of the <service-uri> permission
based on URI equivalence, the service occurrence is included in the
presence document. If an <occurrence-id> permission is granted to
the watcher, and the <occurrence-id> of the service occurrence
matches the value of the <occurrence-id> permission based on case-
sensitive equality, the service occurrence is included in the presence document. If a <service-uri-scheme> permission is granted to the watcher, and the scheme of the service URI for the service occurrence matches the value of <service-uri-scheme> based on case-sensitive equality, the service occurrence is included in the presence document. In addition, a service occurrence is included in the presence document if the <all-services> permission was granted to the watcher.
敏感相等，服务事件包含在状态文档中。如果向观察者授予<service uri scheme>权限，并且基于区分大小写的相等性，服务事件的服务uri的方案与<service uri scheme>的值匹配，则服务事件包含在存在文档中。此外，如果向观察者授予了<all services>权限，则存在文档中将包含服务事件。
The permissions of Section 3.3.1 provide coarse-grained access to presence data by allowing or blocking specific services or devices, and allowing or blocking person information.
第3.3.1节的权限通过允许或阻止特定服务或设备，以及允许或阻止人员信息，提供对状态数据的粗粒度访问。
Once person, device, or service information is included in the document, the permissions in this section define which presence attributes are reported there. Certain information is always reported. In particular, the <contact>, <service-class> [9], <basic> status, and <timestamp> elements in all <tuple> elements, if present, are provided to watchers. The <timestamp> element in all <person> elements, if present, is provided to watchers. The <timestamp> and <deviceID> elements in all <device> elements, if present, are provided to all watchers.
文档中包含人员、设备或服务信息后，本节中的权限将定义报告的状态属性。某些信息总是被报告的。特别是，所有<tuple>元素中的<contact>、<service class>[9]、<basic>状态和<timestamp>元素（如果存在）都提供给观察者。所有<person>元素中的<timestamp>元素（如果存在）将提供给观察者。所有<device>元素中的<timestamp>和<deviceID>元素（如果存在）都提供给所有观察者。
This permission controls access to the <activities> element defined in [9]. The name of the element providing this permission is <provide-activities>, and it is a Boolean type. If its value is TRUE, then the <activities> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<activities>元素的访问。提供此权限的元素的名称为<提供活动>，并且是布尔类型。如果其值为TRUE，则person数据元素中的<activities>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <class> element defined in [9]. The name of the element providing this permission is <provide-class>, and it is a Boolean type. If its value is TRUE, then any <class> element in a person, service, or device data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<class>元素的访问。提供此权限的元素的名称为<提供类>，并且是布尔类型。如果其值为TRUE，则向观察者报告个人、服务或设备数据元素中的任何<class>元素。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <deviceID> element in a <tuple> element, as defined in [9]. The name of the element providing this permission is <provide-deviceID>, and it is a Boolean type. If its value is TRUE, then the <deviceID> element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. Note that the <deviceID> in a device data element is always included, and not controlled by this permission.
此权限控制对<tuple>元素中<deviceID>元素的访问，如[9]中所定义。提供此权限的元素的名称为<提供设备ID>，并且是布尔类型。如果其值为TRUE，则服务数据元素中的<deviceID>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。请注意，设备数据元素中的<deviceID>始终包括在内，不受此权限的控制。
This permission controls access to the <mood> element defined in [9]. The name of the element providing this permission is <provide-mood>, and it is a Boolean type. If its value is TRUE, then the <mood> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<mood>元素的访问。提供此权限的元素的名称为<provide mood>，它是布尔类型。如果其值为TRUE，则person数据元素中的<mood>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <place-is> element defined in [9]. The name of the element providing this permission is <provide-place-is>, and it is a Boolean type. If its value is TRUE, then the <place-is> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<place is>元素的访问。提供此权限的元素的名称为<provide place is>，它是布尔类型。如果其值为TRUE，则person数据元素中的<place is>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <place-type> element defined in [9]. The name of the element providing this permission is <provide-place-type>, and it is a Boolean type. If its value is TRUE, then the <place-type> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<place type>元素的访问。提供此权限的元素的名称为<provide place type>，它是布尔类型。如果其值为TRUE，则person数据元素中的<place type>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <privacy> element defined in [9]. The name of the element providing this permission is <provide-privacy>, and it is a Boolean type. If its value is TRUE, then the <privacy> element in the person or service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<privacy>元素的访问。提供此权限的元素的名称是<provide privacy>，它是布尔类型。如果其值为TRUE，则person或service数据元素中的<privacy>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <relationship> element defined in [9]. The name of the element providing this permission is <provide-relationship>, and it is a Boolean type. If its value is TRUE, then the <relationship> element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<relationship>元素的访问。提供此权限的元素的名称为<提供关系>，并且是布尔类型。如果其值为TRUE，则服务数据元素中的<relationship>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <sphere> element defined in [9]. The name of the element providing this permission is <provide-sphere>, and it is a Boolean type. If its value is TRUE, then the <sphere> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<sphere>元素的访问。提供此权限的元素的名称是<ProviderSphere>，它是布尔类型。如果其值为TRUE，则person数据元素中的<sphere>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <status-icon> element defined in [9]. The name of the element providing this permission is <provide-status-icon>, and it is a Boolean type. If its value is TRUE, then any <status-icon> element in the person or service data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<status icon>元素的访问。提供此权限的元素的名称为<提供状态图标>，它是布尔类型。如果其值为TRUE，则人员或服务数据元素中的任何<status icon>元素都会报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <time-offset> element defined in [9]. The name of the element providing this permission is <provide-time-offset>, and it is a Boolean type. If its value is TRUE, then the <time-offset> element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[9]中定义的<time offset>元素的访问。提供此权限的元素的名称为<提供时间偏移>，并且是布尔类型。如果其值为TRUE，则person数据元素中的<time offset>元素将报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission controls access to the <user-input> element defined in [9]. The name of the element providing this permission is <provide-user-input>, and it is an enumerated integer type. Its value defines what information is provided to watchers in person, device, or service data elements:
此权限控制对[9]中定义的<user input>元素的访问。提供此权限的元素的名称为<提供用户输入>，它是枚举整数类型。其值定义了在个人、设备或服务数据元素中向观察者提供的信息：
false: This value indicates that the <user-input> element is removed from the document. It is assigned the numeric value of 0.
false：此值表示已从文档中删除<user input>元素。它被指定为0的数值。
bare: This value indicates that the <user-input> element is to be retained. However, any "idle-threshold" and "since" attributes are to be removed. This value is assigned the numeric value of 10.
bare：该值表示要保留<user input>元素。但是，任何“空闲阈值”和“自”属性都将被删除。该值被指定为数字值10。
thresholds: This value indicates that the <user-input> element is to be retained. However, only the "idle-threshold" attribute is to be retained. This value is assigned the numeric value of 20.
阈值：该值表示要保留<user input>元素。但是，只保留“空闲阈值”属性。该值被指定为数字值20。
full: This value indicates that the <user-input> element is to be retained, including any attributes. This value is assigned the numeric value of 30.
full：该值表示要保留<user input>元素，包括任何属性。此值被指定为数字值30。
This permission controls access to the <note> element defined in [3] for <tuple> and [10] for <person> and <device>. The name of the element providing this permission is <provide-note>, and it is a Boolean type. If its value is TRUE, then any <note> elements in the person, service, or device data elements are reported to the watcher. If FALSE, this presence attribute is removed if present.
此权限控制对[3]中为<tuple>定义的<note>元素和[10]中为<person>和<device>定义的<note>元素的访问。提供此权限的元素的名称为<提供注释>，并且是布尔类型。如果其值为TRUE，则将个人、服务或设备数据元素中的任何<note>元素报告给观察者。如果为FALSE，则此状态属性在存在时将被删除。
This permission has no bearing on any <note> values present within <activities>, <mood>, <place-is>, <place-type>, <privacy>, <relationship>, or <service-class> elements. Notes within these elements are essentially values for their respective elements, and are present if the respective element is permitted in the presence document. For example, if an <activities> element is present in a presence document, and there is a <note> value for it, that note is present in the document sent to the watcher if the <provide-activities> permission is given, regardless of whether the <provide-note> permission is given.
此权限与<activities>、<mood>、<place is>、<place type>、<privacy>、<relationship>或<service class>元素中存在的任何<note>值无关。这些元素中的注释基本上是其各自元素的值，如果存在文档中允许相应元素，则注释会出现。例如，如果一个<activities>元素出现在状态文档中，并且该元素有一个<note>值，那么如果授予<provide activities>权限，则该注释将出现在发送给观察者的文档中，而不管是否授予<provide note>权限。
It is important that systems be allowed to include proprietary or new presence information and that users be able to set permissions for that information, without requiring an upgrade of the presence server and authorization system. For this reason, the <provide-unknown-attribute> permission is defined. This permission indicates that the unknown presence attribute with the given name and namespace (supplied as mandatory attributes of the <provide-unknown-attribute> element) should be included in the document. Its type is Boolean.
重要的是，允许系统包含专有或新的状态信息，并且用户能够为该信息设置权限，而无需升级状态服务器和授权系统。因此，定义了<provide unknown attribute>权限。此权限表示文档中应包含具有给定名称和命名空间的未知状态属性（作为<provide unknown attribute>元素的强制属性提供）。它的类型是布尔型的。
The value of the name attribute MUST be an unqualified element name (meaning that a namespace prefix MUST NOT be included), and the value of the ns attribute MUST be a namespace URI. The two are combined to form a qualified element name, which will be matched to all unknown
name属性的值必须是非限定元素名（意味着不能包含名称空间前缀），ns属性的值必须是名称空间URI。这两个元素组合在一起形成一个限定元素名，它将与所有未知元素匹配
child elements of the Presence Information Data Format (PIDF) <tuple>, <device>, or <person> elements with the same qualified name. In this context, "unknown" means that the presence server is not aware of any schemas that define authorization policies for that element. By definition, this will exclude the <provide-unknown-attribute> rule from being applied to any of the presence status extensions defined by RPID, since authorization policies for those are defined here.
状态信息数据格式（PIDF）<tuple>、<device>或具有相同限定名称的<person>元素的子元素。在此上下文中，“未知”意味着状态服务器不知道为该元素定义授权策略的任何模式。根据定义，这将排除<provide unknown attribute>规则应用于RPID定义的任何状态扩展，因为这些状态扩展的授权策略在此处定义。
Another consequence of this definition is that the interpretation of the <provide-unknown-attribute> element can change should the presence server be upgraded. For example, consider a server that, prior to the upgrade, had an authorization document that used <provide-unknown-attribute> with a value of TRUE for some attribute, say foo. This attribute was from a namespace and schema unknown to the server, and so the attribute was provided to watchers. However, after upgrade, the server is now aware of a new namespace and schema for a permission that grants access to the foo attribute. Now, the <provide-unknown-attribute> permission for the foo attribute will be ignored, resulting in a removal of those elements from presence documents sent to watchers. The system remains privacy safe, but behavior might not be as expected. Developers of systems that allow clients to set policies are advised to check the capabilities of the server (using the mechanism described in Section 8) before uploading a new authorization document, to make sure that the behavior will be as expected.
此定义的另一个结果是，如果状态服务器升级，<provide unknown attribute>元素的解释可能会更改。例如，考虑一个服务器，在升级之前，它有一个授权文件，它使用“未知属性>提供了某个属性的真值，比如说Foo。该属性来自服务器未知的命名空间和架构，因此该属性提供给了观察者。但是，升级后，服务器现在知道一个新的命名空间和模式，用于授予对foo属性的访问权限。现在，foo属性的<provide unknown attribute>权限将被忽略，从而从发送给观察者的状态文档中删除这些元素。系统保持隐私安全，但行为可能不符合预期。建议允许客户端设置策略的系统开发人员在上载新授权文档之前检查服务器的功能（使用第8节中描述的机制），以确保行为符合预期。
This permission grants access to all presence attributes in all of the person, device, and tuple elements that are present in the document (the ones present in the document are determined by the <provide-persons>, <provide-devices>, and <provide-services> permissions). It is effectively a macro that expands into a set of provide-activities, provide-class, provide-deviceID, provide-mood, provide-place-is, provide-place-type, provide-privacy, provide-relationship, provide-sphere, provide-status-icon, provide-time-offset, provide-user-input, provide-note, and provide-unknown-attribute permissions such that each presence attribute in the document has a permission for it. This implies that, so long as an entire person, service, or device occurrence is provided, every single presence attribute, including ones not known to the server and/or defined in future presence document extensions, is granted to the watcher.
此权限授予对文档中存在的所有person、device和tuple元素（文档中存在的元素由<Provider persons>、<Provider devices>和<Provider services>权限确定）中所有状态属性的访问权限。它实际上是一个宏，可扩展为一组提供活动、提供类、提供设备ID、提供心情、提供地点is、提供地点类型、提供隐私、提供关系、提供范围、提供状态图标、提供时间偏移、提供用户输入、提供注释、，并提供未知属性权限，以便文档中的每个状态属性都对其具有权限。这意味着，只要提供了整个人员、服务或设备事件，每个存在属性（包括服务器不知道和/或在未来存在文档扩展中未定义的属性）都将授予观察者。
This specification does not mandate at what point in the processing of presence data the privacy filtering aspects of the authorization policy are applied. However, they must be applied such that the final presence document sent to the watcher is compliant to the privacy policy described in the authorization documents that apply to the user (there can be more than one; the rules for combining them are described in [8]). More concretely, if the presence document sent to a watcher is D, and the privacy filtering operation applied do a presence document x is F(x), then D MUST have the property that D = F(D). In other words, further applications of the privacy filtering operation would not result in any further changes of the presence document, making further application of the filtering operation a no-op. A corollary of this is that F(F(D)) = D for all D.
本规范不要求在处理状态数据时应用授权策略的隐私过滤方面。但是，必须应用它们，以便发送给观察者的最终状态文档符合适用于用户的授权文档中描述的隐私政策（可以有多个；组合它们的规则在[8]中描述）。更具体地说，如果发送给观察者的状态文档是D，并且应用于状态文档x的隐私过滤操作是F（x），那么D必须具有D＝F（D）的属性。换句话说，隐私过滤操作的进一步应用不会导致存在文档的任何进一步改变，使得过滤操作的进一步应用成为不可操作的。这的推论是，对于所有D，F（F（D））=D。
The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription.
当服务器决定接受或拒绝订阅时，将应用文档的订阅处理方面。
The rules defined by the document in this specification form a "contract" of sorts between a client that creates this document and the server that executes the policies it contains. Consequently, presence servers implementing this specification MUST support all of the conditions, actions, and transformations defined in this specification. If servers were to implement a subset of these, clients would need a mechanism to discover which subset is supported. No such mechanism is defined.
本规范中文档定义的规则在创建此文档的客户端和执行其包含的策略的服务器之间形成了一种“契约”。因此，实现本规范的状态服务器必须支持本规范中定义的所有条件、操作和转换。如果服务器要实现其中的一个子集，客户端将需要一种机制来发现支持哪一个子集。没有定义这种机制。
It is RECOMMENDED that clients support all of the actions, transformations, and conditions defined in this specification. If a client supports a subset, it is possible that a user might manipulate their authorization rules from a different client, supporting a different subset, and store those results on the server. When the user goes back to the first client and views their presence authorization rules there, the client may not be able to properly render or manipulate the document retrieved from the server, since it may contain conditions, actions, or transformations not supported by the client. The only reason that this normative requirement is not a MUST is that there are valid conditions in which a user manipulates their presence authorization rules from a single client, in which case this problem does not occur.
建议客户机支持本规范中定义的所有操作、转换和条件。如果客户机支持子集，则用户可能会从支持不同子集的不同客户机操作其授权规则，并将这些结果存储在服务器上。当用户返回到第一个客户端并在那里查看其状态授权规则时，客户端可能无法正确呈现或操作从服务器检索到的文档，因为它可能包含客户端不支持的条件、操作或转换。此规范性要求不是必须的唯一原因是，存在用户从单个客户端操纵其状态授权规则的有效条件，在这种情况下，不会出现此问题。
This specification makes no normative recommendations on the mechanism used to transport presence authorization documents from
本规范未对用于从中传输存在授权文件的机制提出规范性建议
clients to their servers. Although Section 9 defines how to utilize XCAP, XCAP is not normatively required by this specification.
将客户端连接到其服务器。尽管第9节定义了如何使用XCAP，但本规范并不规范地要求使用XCAP。
The following presence authorization document specifies permissions for the user "user@example.com". The watcher is allowed to access presence information (the 'allow' value for <sub-handling>). They will be granted access to the presence data of all services whose contact URI schemes are sip and mailto. Person information is also provided. However, since there is no <provide-devices>, no device information will be given to the watcher. Within the service and person information provided to the watcher, the <activities> element will be shown, as will the <user-input> element. However, any "idle-threshold" and "since" attributes in the <user-input> element will be removed. Finally, the presence attribute <foo> will be shown to the watcher. Any other presence attributes will be removed.
以下状态授权文档指定用户的权限“user@example.com". 允许观察者访问状态信息（“子处理”）的“允许”值。他们将被授权访问其联系人URI方案为sip和mailto的所有服务的状态数据。还提供了人员信息。但是，由于没有<提供设备>，因此不会向观察者提供设备信息。在提供给观察者的服务和人员信息中，将显示<activities>元素和<user input>元素。但是，<user input>元素中的任何“空闲阈值”和“自”属性都将被删除。最后，状态属性<foo>将显示给观察者。任何其他状态属性都将被删除。
<?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<cr:rule id="a">
<cr:conditions>
<cr:identity>
<cr:one id="sip:user@example.com"/>
</cr:identity>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-services>
<pr:service-uri-scheme>sip</pr:service-uri-scheme>
<pr:service-uri-scheme>mailto</pr:service-uri-scheme>
</pr:provide-services>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-activities>true</pr:provide-activities>
<pr:provide-user-input>bare</pr:provide-user-input>
<pr:provide-unknown-attribute
ns="urn:vendor-specific:foo-namespace"
name="foo">true</pr:provide-unknown-attribute>
</cr:transformations>
</cr:rule>
</cr:ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<cr:rule id="a">
<cr:conditions>
<cr:identity>
<cr:one id="sip:user@example.com"/>
</cr:identity>
</cr:conditions>
<cr:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cr:actions>
<cr:transformations>
<pr:provide-services>
<pr:service-uri-scheme>sip</pr:service-uri-scheme>
<pr:service-uri-scheme>mailto</pr:service-uri-scheme>
</pr:provide-services>
<pr:provide-persons>
<pr:all-persons/>
</pr:provide-persons>
<pr:provide-activities>true</pr:provide-activities>
<pr:provide-user-input>bare</pr:provide-user-input>
<pr:provide-unknown-attribute
ns="urn:vendor-specific:foo-namespace"
name="foo">true</pr:provide-unknown-attribute>
</cr:transformations>
</cr:rule>
</cr:ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:simpleType name="booleanPermission">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<xs:element name="service-uri-scheme" type="xs:token"/>
<xs:element name="class" type="xs:token"/>
<xs:element name="occurrence-id" type="xs:token"/>
<xs:element name="service-uri" type="xs:anyURI"/>
<xs:complexType name="provideServicePermission">
<xs:choice>
<xs:element name="all-services">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:service-uri"/>
<xs:element ref="pr:service-uri-scheme"/>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="provide-services"
type="pr:provideServicePermission"/>
<xs:element name="deviceID" type="xs:anyURI"/>
<xs:complexType name="provideDevicePermission">
<xs:choice>
<xs:element name="all-devices">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:deviceID"/>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:simpleType name="booleanPermission">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<xs:element name="service-uri-scheme" type="xs:token"/>
<xs:element name="class" type="xs:token"/>
<xs:element name="occurrence-id" type="xs:token"/>
<xs:element name="service-uri" type="xs:anyURI"/>
<xs:complexType name="provideServicePermission">
<xs:choice>
<xs:element name="all-services">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:service-uri"/>
<xs:element ref="pr:service-uri-scheme"/>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="provide-services"
type="pr:provideServicePermission"/>
<xs:element name="deviceID" type="xs:anyURI"/>
<xs:complexType name="provideDevicePermission">
<xs:choice>
<xs:element name="all-devices">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:deviceID"/>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="provide-devices"
type="pr:provideDevicePermission"/>
<xs:complexType name="providePersonPermission">
<xs:choice>
<xs:element name="all-persons">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="provide-persons"
type="pr:providePersonPermission"/>
<xs:element name="provide-activities"
type="pr:booleanPermission"/>
<xs:element name="provide-class"
type="pr:booleanPermission"/>
<xs:element name="provide-deviceID"
type="pr:booleanPermission"/>
<xs:element name="provide-mood"
type="pr:booleanPermission"/>
<xs:element name="provide-place-is"
type="pr:booleanPermission"/>
<xs:element name="provide-place-type"
type="pr:booleanPermission"/>
<xs:element name="provide-privacy"
type="pr:booleanPermission"/>
<xs:element name="provide-relationship"
type="pr:booleanPermission"/>
<xs:element name="provide-status-icon"
type="pr:booleanPermission"/>
<xs:element name="provide-sphere"
type="pr:booleanPermission"/>
<xs:element name="provide-time-offset"
type="pr:booleanPermission"/>
<xs:element name="provide-user-input">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="false"/>
<xs:enumeration value="bare"/>
<xs:enumeration value="thresholds"/>
</xs:choice>
</xs:complexType>
<xs:element name="provide-devices"
type="pr:provideDevicePermission"/>
<xs:complexType name="providePersonPermission">
<xs:choice>
<xs:element name="all-persons">
<xs:complexType/>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="pr:occurrence-id"/>
<xs:element ref="pr:class"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:complexType>
<xs:element name="provide-persons"
type="pr:providePersonPermission"/>
<xs:element name="provide-activities"
type="pr:booleanPermission"/>
<xs:element name="provide-class"
type="pr:booleanPermission"/>
<xs:element name="provide-deviceID"
type="pr:booleanPermission"/>
<xs:element name="provide-mood"
type="pr:booleanPermission"/>
<xs:element name="provide-place-is"
type="pr:booleanPermission"/>
<xs:element name="provide-place-type"
type="pr:booleanPermission"/>
<xs:element name="provide-privacy"
type="pr:booleanPermission"/>
<xs:element name="provide-relationship"
type="pr:booleanPermission"/>
<xs:element name="provide-status-icon"
type="pr:booleanPermission"/>
<xs:element name="provide-sphere"
type="pr:booleanPermission"/>
<xs:element name="provide-time-offset"
type="pr:booleanPermission"/>
<xs:element name="provide-user-input">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="false"/>
<xs:enumeration value="bare"/>
<xs:enumeration value="thresholds"/>
<xs:enumeration value="full"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="provide-note" type="pr:booleanPermission"/>
<xs:element name="sub-handling">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="block"/>
<xs:enumeration value="confirm"/>
<xs:enumeration value="polite-block"/>
<xs:enumeration value="allow"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:complexType name="unknownBooleanPermission">
<xs:simpleContent>
<xs:extension base="pr:booleanPermission">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="ns" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="provide-unknown-attribute"
type="pr:unknownBooleanPermission"/>
<xs:element name="provide-all-attributes">
<xs:complexType/>
</xs:element>
</xs:schema>
<xs:enumeration value="full"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="provide-note" type="pr:booleanPermission"/>
<xs:element name="sub-handling">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="block"/>
<xs:enumeration value="confirm"/>
<xs:enumeration value="polite-block"/>
<xs:enumeration value="allow"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:complexType name="unknownBooleanPermission">
<xs:simpleContent>
<xs:extension base="pr:booleanPermission">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="ns" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="provide-unknown-attribute"
type="pr:unknownBooleanPermission"/>
<xs:element name="provide-all-attributes">
<xs:complexType/>
</xs:element>
</xs:schema>
It is anticipated that future changes to this specification are accomplished through extensions that define new types of permissions. These extensions MUST exist within a different namespace. Furthermore, the schema defined above and the namespace for elements defined within it MUST NOT be altered by future specifications. Changes in the basic schema, or in the interpretation of elements within that schema, may result in violations of user privacy due to misinterpretation of documents.
预计本规范的未来更改将通过定义新权限类型的扩展来完成。这些扩展必须存在于不同的命名空间中。此外，上面定义的模式和其中定义的元素的名称空间不能被未来的规范更改。基本模式中的更改或该模式中元素的解释中的更改可能会由于对文档的错误解释而导致侵犯用户隐私。
When extensions are made to the set of permissions, it becomes necessary for the agent constructing the permission document (typically a SIP user agent, though not necessarily) to know which permissions are supported by the server. This allows the agent to know how to build a document that results in the desired behavior, since unknown permissions would be ignored by the server. To handle this, when presence authorization documents are transported using
当对权限集进行扩展时，构建权限文档的代理（通常是SIP用户代理，但不一定）需要知道服务器支持哪些权限。这使代理知道如何构建一个文档，从而产生所需的行为，因为未知的权限将被服务器忽略。若要处理此问题，请在使用
XCAP, the XCAP capabilities document stored at the server SHOULD contain the namespaces for the permissions supported by the presence server. This way, an agent can query for this list prior to constructing a document.
XCAP，存储在服务器上的XCAP能力文档应该包含状态服务器支持的权限的名称空间。这样，代理可以在构建文档之前查询此列表。
The following section defines the details necessary for clients to manipulate presence authorization documents from a server using XCAP.
以下部分定义了客户端使用XCAP从服务器操作状态授权文档所需的详细信息。
XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "pres-rules" AUID within the IETF tree, via the IANA registration in Section 11.
XCAP要求应用程序使用在IETF树或供应商树中定义唯一的应用程序使用ID（AUID）。本规范通过第11节中的IANA注册，定义IETF树中的“pres规则”AUID。
XCAP requires application usages to define a schema for their documents. The schema for presence authorization documents is in Section 7.
XCAP要求应用程序使用为其文档定义模式。存在授权文件的模式见第7节。
XCAP requires application usages to define the default namespace for their URIs. The default namespace is urn:ietf:params:xml:ns:pres-rules.
XCAP要求应用程序使用为其URI定义默认命名空间。默认名称空间是urn:ietf:params:xml:ns:pres规则。
XCAP requires application usages to define the MIME type for documents they carry. Presence authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml.
XCAP需要应用程序使用来定义它们携带的文档的MIME类型。状态授权文档继承通用策略文档的MIME类型，即应用程序/auth策略+xml。
There are no additional constraints defined by this specification.
本规范未定义其他约束。
Semantics of a presence authorization document are discussed in Section 3.
第3节讨论了状态授权文档的语义。
When a presence agent receives a subscription for some user foo within a domain, it will look for all documents within http://[xcap root]/pres-rules/users/foo, and use all documents found beneath that point to guide authorization policy. If only a single document is used, it SHOULD be called "index".
当状态代理收到域中某个用户foo的订阅时，它将查找http://[xcap root]/pres rules/users/foo中的所有文档，并使用在该点下找到的所有文档指导授权策略。如果只使用一个文档，则应将其称为“索引”。
There are no additional resource interdependencies defined by this application usage.
此应用程序使用情况未定义其他资源相互依赖关系。
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write, or modify their own documents. A server can allow privileged users to modify documents that they don't own, but the establishment and indication of such policies are outside the scope of this document.
此应用程序用法不会修改默认的XCAP授权策略，即只有用户可以读取、写入或修改自己的文档。服务器可以允许特权用户修改他们不拥有的文档，但此类策略的建立和指示超出了本文档的范围。
Presence authorization policies contain very sensitive information. They indicate which other users are "liked" or "disliked" by a user. As such, when these documents are transported over a network, they SHOULD be encrypted.
状态授权策略包含非常敏感的信息。它们表示用户“喜欢”或“不喜欢”哪些其他用户。因此，当这些文档通过网络传输时，应该对其进行加密。
Modification of these documents by an attacker can disrupt the service seen by a user, often in subtle ways. As a result, when these documents are transported, the transport SHOULD provide authenticity and message integrity.
攻击者修改这些文档可能会破坏用户看到的服务，通常会以微妙的方式。因此，在传输这些文档时，传输应提供真实性和消息完整性。
In the case where XCAP is used to transfer the document, both clients and servers MUST implement HTTP over Transport Layer Security (TLS) and HTTP Digest authentication. Sites SHOULD authenticate clients using digest authentication over TLS, and sites SHOULD define the root services URI as an https URI.
在使用XCAP传输文档的情况下，客户端和服务器都必须实现HTTP over Transport Layer Security（TLS）和HTTP摘要身份验证。站点应该通过TLS使用摘要身份验证对客户端进行身份验证，并且站点应该将根服务URI定义为https URI。
Authorization documents themselves exist for the purposes of providing a security function - privacy. The SIP presence specifications [18] require the usage of an authorization function prior to the granting of presence information, and this specification meets that need. Presence authorization documents inherit the privacy properties of the common policy format on which they are based. This format has been designed to be privacy-safe, which means that failure of the presence server to obtain or understand an authorization document can never reveal more information than is
授权文件本身的存在是为了提供安全功能——隐私。SIP状态规范[18]要求在授予状态信息之前使用授权功能，本规范满足这一需求。状态授权文档继承它们所基于的公共策略格式的隐私属性。这种格式被设计为隐私安全的，这意味着状态服务器无法获取或理解授权文档，将永远无法透露更多的信息
desired about the user, only less. This is a consequence of the fact that all permissions are positive grants of information, and not negative grants.
关于用户的期望值，仅此而已。这是因为所有权限都是信息的正授予，而不是负授予。
A consequence of this design is that the results of combining several authorization documents can be non-obvious to end users. For example, if one authorization document grants permission for all users from the example.com domain to see their presence, and another document blocks joe@example.com, the combination of these will still provide presence to joe@example.com. Designers of user interfaces are encouraged to carefully pay attention to the results of combining multiple rules.
这种设计的一个结果是，组合多个授权文档的结果可能对最终用户不明显。例如，如果一个授权文档向example.com域中的所有用户授予查看其状态的权限，而另一个文档将阻止joe@example.com，两者的结合仍将为joe@example.com. 鼓励用户界面设计者仔细关注组合多个规则的结果。
Another concern is cases where a user sets their privacy preferences from one client, uploads their presence authorization document to a server, and then modifies them from a different client. If the clients support different subsets of the document format, users may be confused about what information is being revealed. Clients retrieving presence authorization documents from a server SHOULD render, to the users, information about rules that they do not understand, so that users can be certain what rules are in place.
Another concern is cases where a user sets their privacy preferences from one client, uploads their presence authorization document to a server, and then modifies them from a different client. If the clients support different subsets of the document format, users may be confused about what information is being revealed. Clients retrieving presence authorization documents from a server SHOULD render, to the users, information about rules that they do not understand, so that users can be certain what rules are in place.translate error, please retry
There are several IANA considerations associated with this specification.
与本规范相关的IANA注意事项有几个。
This section registers an XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2].
本节根据[2]中定义的IANA过程注册XCAP应用程序使用ID（AUID）。
Name of the AUID: pres-rules
AUID的名称：pres规则
Description: Presence rules are documents that describe the permissions that a presentity [17] has granted to users that seek to watch their presence.
描述：状态规则是描述状态实体[17]授予寻求观看其状态的用户的权限的文档。
This section registers a new XML namespace, per the guidelines in [11]
本节根据[11]中的指南注册一个新的XML名称空间
URI: The URI for this namespace is urn:ietf:params:xml:ns:pres-rules.
URI：此命名空间的URI是urn:ietf:params:xml:ns:pres规则。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML:
XML:
BEGIN
开始
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Presence Rules Namespace</title>
</head>
<body>
<h1>Namespace for Permission Statements</h1>
<h2>urn:ietf:params:xml:ns:pres-rules</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5025.txt">
RFC5025</a>.</p>
</body>
</html>
END
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Presence Rules Namespace</title>
</head>
<body>
<h1>Namespace for Permission Statements</h1>
<h2>urn:ietf:params:xml:ns:pres-rules</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5025.txt">
RFC5025</a>.</p>
</body>
</html>
END
This section registers an XML schema per the procedures in [11].
本节按照[11]中的过程注册XML模式。
URI: urn:ietf:params:xml:schema:pres-rules.
URI:urn:ietf:params:xml:schema:pres规则。
Registrant Contact: IETF, SIMPLE working group (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of Section 7.
此模式的XML可以作为第7节的唯一内容找到。
The author would like to thank Richard Barnes, Jari Urpalainen, Jon Peterson, and Martin Hynar for their comments.
作者要感谢Richard Barnes、Jari Urpalainen、Jon Peterson和Martin Hynar的评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2] Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[5] 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.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[6] Rosenberg，J.，“会话启动协议（SIP）的观察者信息事件模板包”，RFC3857，2004年8月。
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[7] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[8] Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，Polk，J.，和J.Rosenberg，“共同政策：表达隐私偏好的文件格式”，RFC 47452007年2月。
[9] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[9] Schulzrinne，H.，Gurbani，V.，Kyzivat，P.，和J.Rosenberg，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，RFC 44802006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10] Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[11] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[11] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[12] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[13] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[13] Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[14] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[14] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[15] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[16] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[16] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[17] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[17] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[18] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[18] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
Author's Address
作者地址
Jonathan Rosenberg Cisco Edison, NJ US
Jonathan Rosenberg Cisco Edison，美国新泽西州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.