Network Working Group H. Schulzrinne
Request for Comments: 4745 Columbia U.
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
J. Rosenberg
Cisco
February 2007
Network Working Group H. Schulzrinne
Request for Comments: 4745 Columbia U.
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
J. Rosenberg
Cisco
February 2007
Common Policy: A Document Format for Expressing Privacy Preferences
公共策略：用于表达隐私偏好的文档格式
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.
本文档定义了一个授权策略框架，用于控制对特定于应用程序的数据的访问。该框架结合了通用的特定于位置和状态的授权方面。XML模式指定用于表示公共策略规则的语言。公共策略框架可以扩展到其他应用程序域。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Modes of Operation ..............................................4
3.1. Passive Request-Response - PS as Server (Responder) ........5
3.2. Active Request-Response - PS as Client (Initiator) .........5
3.3. Event Notification .........................................5
4. Goals and Assumptions ...........................................6
5. Non-Goals .......................................................7
6. Basic Data Model and Processing .................................8
6.1. Identification of Rules ....................................9
6.2. Extensions .................................................9
7. Conditions .....................................................10
7.1. Identity Condition ........................................10
7.1.1. Overview ...........................................10
7.1.2. Matching One Entity ................................11
7.1.3. Matching Multiple Entities .........................11
7.2. Single Entity .............................................14
7.3. Sphere ....................................................15
7.4. Validity ..................................................16
8. Actions ........................................................17
9. Transformations ................................................18
10. Procedure for Combining Permissions ...........................18
10.1. Introduction .............................................18
10.2. Combining Rules (CRs) ....................................18
10.3. Example ..................................................19
11. Meta Policies .................................................21
12. Example .......................................................21
13. XML Schema Definition .........................................22
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
15.1. Common Policy Namespace Registration .....................25
15.2. Content-type Registration for
'application/auth-policy+xml' ............................26
15.3. Common Policy Schema Registration ........................27
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................28
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgments .......................................29
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Modes of Operation ..............................................4
3.1. Passive Request-Response - PS as Server (Responder) ........5
3.2. Active Request-Response - PS as Client (Initiator) .........5
3.3. Event Notification .........................................5
4. Goals and Assumptions ...........................................6
5. Non-Goals .......................................................7
6. Basic Data Model and Processing .................................8
6.1. Identification of Rules ....................................9
6.2. Extensions .................................................9
7. Conditions .....................................................10
7.1. Identity Condition ........................................10
7.1.1. Overview ...........................................10
7.1.2. Matching One Entity ................................11
7.1.3. Matching Multiple Entities .........................11
7.2. Single Entity .............................................14
7.3. Sphere ....................................................15
7.4. Validity ..................................................16
8. Actions ........................................................17
9. Transformations ................................................18
10. Procedure for Combining Permissions ...........................18
10.1. Introduction .............................................18
10.2. Combining Rules (CRs) ....................................18
10.3. Example ..................................................19
11. Meta Policies .................................................21
12. Example .......................................................21
13. XML Schema Definition .........................................22
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
15.1. Common Policy Namespace Registration .....................25
15.2. Content-type Registration for
'application/auth-policy+xml' ............................26
15.3. Common Policy Schema Registration ........................27
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................28
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgments .......................................29
This document defines a framework for creating authorization policies for access to application-specific data. This framework is the result of combining the common aspects of single authorization systems that more specifically control access to presence and location information and that previously had been developed separately. The benefit of combining these two authorization systems is two-fold. First, it allows building a system that enhances the value of presence with location information in a natural way and reuses the same underlying authorization mechanism. Second, it encourages a more generic authorization framework with mechanisms for extensibility. The applicability of the framework specified in this document is not limited to policies controlling access to presence and location information data, but can be extended to other application domains.
本文档定义了一个框架，用于创建访问特定于应用程序的数据的授权策略。该框架是将单一授权系统的共同方面结合在一起的结果，这些系统更具体地控制对存在和位置信息的访问，并且以前是单独开发的。结合这两个授权系统的好处是双重的。首先，它允许构建一个系统，以自然的方式通过位置信息增强存在的价值，并重用相同的底层授权机制。其次，它鼓励使用具有可扩展性机制的更通用的授权框架。本文档中指定的框架的适用性不仅限于控制访问状态和位置信息数据的策略，还可以扩展到其他应用程序域。
The general framework defined in this document is intended to be accompanied and enhanced by application-specific policies specified elsewhere. The common policy framework described here is enhanced by domain-specific policy documents, including presence [7] and location [8]. This relationship is shown in Figure 1.
本文件中定义的一般框架旨在通过其他地方指定的特定于应用程序的策略来辅助和增强。这里描述的公共策略框架通过特定于域的策略文档（包括状态[7]和位置[8]）得到了增强。这种关系如图1所示。
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
Figure 1: Common Policy Enhancements
图1：通用策略增强
This document starts with an introduction to the terminology in Section 2, an illustration of basic modes of operation in Section 3, a description of goals (see Section 4) and non-goals (see Section 5) of the policy framework, followed by the data model in Section 6. The structure of a rule, namely, conditions, actions, and transformations, is described in Sections 7, 8, and 9. The procedure for combining permissions is explained in Section 10 and used when conditions for more than one rule are satisfied. A short description
本文件首先介绍第2节中的术语、第3节中的基本操作模式说明、政策框架的目标（见第4节）和非目标（见第5节）说明，然后是第6节中的数据模型。第7、8和9节描述了规则的结构，即条件、操作和转换。第10节解释了合并权限的过程，并在满足多个规则的条件时使用。简短的描述
of meta policies is given in Section 11. An example is provided in Section 12. The XML schema will be discussed in Section 13. IANA considerations in Section 15 follow security considerations in Section 14.
第11节给出了元策略的定义。第12节提供了一个示例。XML模式将在第13节中讨论。第15节中的IANA考虑遵循第14节中的安全考虑。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
This document introduces the following terms:
本文件介绍了以下术语：
PT - Presentity / Target: The PT is the entity about whom information has been requested.
PT-存在实体/目标：PT是被请求提供信息的实体。
RM - Rule Maker: The RM is an entity that creates the authorization rules that restrict access to data items.
RM-规则制定者：RM是一个实体，用于创建限制对数据项访问的授权规则。
PS - (Authorization) Policy Server: This entity has access to both the authorization policies and the data items. In location-specific applications, the entity PS is labeled as location server (LS).
PS-（授权）策略服务器：此实体可以访问授权策略和数据项。在特定于位置的应用程序中，实体PS被标记为位置服务器（LS）。
WR - Watcher / Recipient: This entity requests access to data items of the PT. An access operation might be a read, a write, or any other operation.
WR-观察者/接收者：该实体请求访问PT的数据项。访问操作可以是读取、写入或任何其他操作。
A policy is given by a 'rule set' that contains an unordered list of 'rules'. A 'rule' has a 'conditions', an 'actions', and a 'transformations' part.
策略由包含无序“规则”列表的“规则集”给出。“规则”有“条件”、“操作”和“转换”部分。
The term 'permission' indicates the action and transformation components of a 'rule'.
术语“权限”表示“规则”的操作和转换组件。
The term 'using protocol' is defined in [9]. It refers to the protocol used to request access to and to return privacy-sensitive data items.
术语“使用协议”的定义见[9]。它是指用于请求访问和返回隐私敏感数据项的协议。
The abstract sequence of operations can roughly be described as follows. The PS receives a query for data items for a particular PT, via the using protocol. The using protocol (or more precisely, the authentication protocol) provides the identity of the requestor, either at the time of the query or at the subscription time. The authenticated identity of the WR, together with other information provided by the using protocol or generally available to the server,
抽象的操作顺序可以大致描述如下。PS通过使用协议接收特定PT的数据项查询。使用协议（或者更准确地说，身份验证协议）在查询时或订阅时提供请求者的身份。WR的认证身份，以及使用协议提供的或服务器通常可用的其他信息，
is then used for searching through the rule set. All matching rules are combined according to a permission combining algorithm described in Section 10. The combined rules are applied to the application data, resulting in the application of privacy based on the transformation policies. The resulting application data is returned to the WR.
然后用于搜索规则集。所有匹配规则根据第10节中描述的权限组合算法进行组合。将组合规则应用于应用程序数据，从而基于转换策略应用隐私。生成的应用程序数据将返回到WR。
Three different modes of operation can be distinguished:
可区分三种不同的操作模式：
In a passive request-response mode, the WR queries the PS for data items about the PT. Examples of protocols following this mode of operation include HTTP, FTP, LDAP, finger, and various remote procedure call (RPC) protocols, including Sun RPC, Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM), common object request broker architecture (Corba), and Simple Object Access Protocol (SOAP). The PS uses the rule set to determine whether the WR is authorized to access the PT's information, refusing the request if necessary. Furthermore, the PS might filter information by removing elements or by reducing the resolution of elements.
在被动请求-响应模式下，WR向PS查询关于PT的数据项。遵循此操作模式的协议示例包括HTTP、FTP、LDAP、finger和各种远程过程调用（RPC）协议，包括Sun RPC、分布式计算环境（DCE）、分布式组件对象模型（DCOM）、公共对象请求代理体系结构（Corba）和简单对象访问协议（SOAP）。PS使用规则集确定WR是否有权访问PT的信息，必要时拒绝请求。此外，PS可以通过移除元素或降低元素的分辨率来过滤信息。
Alternatively, the PS may contact the WR and convey data items. Examples include HTTP, SIP session setup (INVITE request), H.323 session setup or SMTP.
或者，PS可联系WR并传送数据项。示例包括HTTP、SIP会话设置（邀请请求）、H.323会话设置或SMTP。
Event notification adds a subscription phase to the "Active Request-Response - PS as Client (Initiator)" mode of operation. A watcher or subscriber asks to be added to the notification list for a particular presentity or event. When the presentity changes state or the event occurs, the PS sends a message to the WR containing the updated state. (Presence is a special case of event notification; thus, we often use the term interchangeably.)
事件通知将订阅阶段添加到“活动请求-响应-PS作为客户端（启动器）”操作模式。观察者或订阅者要求添加到特定实体或事件的通知列表中。当存在实体改变状态或事件发生时，PS向WR发送包含更新状态的消息。（存在是事件通知的一种特殊情况；因此，我们经常交替使用该术语。）
In addition, the subscriber may itself add a filter to the subscription, limiting the rate or content of the notifications. If an event, after filtering by the rule-maker-provided rules and by the subscriber-provided rules, only produces the same notification content that was sent previously, no event notification is sent.
此外，订户本身可以向订阅添加过滤器，从而限制通知的速率或内容。如果一个事件在通过规则制定者提供的规则和订阅者提供的规则进行过滤后，只生成与以前发送的相同的通知内容，则不发送任何事件通知。
A single PS may authorize access to data items in more than one mode. Rather than having different rule sets for different modes all three modes are supported with a one rule set schema. Specific instances of the rule set can omit elements that are only applicable to the subscription model.
单个PS可授权以多种模式访问数据项。这三种模式都支持一个规则集模式，而不是为不同的模式提供不同的规则集。规则集的特定实例可以忽略仅适用于订阅模型的元素。
Below, we summarize our design goals and constraints.
下面，我们总结一下我们的设计目标和约束。
Table representation:
表格表示法：
Each rule must be representable as a row in a relational database. This design goal should allow efficient policy implementation by utilizing standard database optimization techniques.
每个规则都必须在关系数据库中表示为一行。此设计目标应允许通过利用标准数据库优化技术实现有效的策略。
Permit only:
仅允许：
Rules only provide permissions rather than denying them. Removing a rule can never increase permissions. Depending on the interpretation of 'deny' and 'permit' rules, the ordering of rules might matter, making updating rule sets more complicated since such update mechanisms would have to support insertion at specific locations in the rule set. Additionally, it would make distributed rule sets more complicated. Hence, only 'permit' actions are allowed that result in more efficient rule processing. This also implies that rule ordering is not important. Consequently, to make a policy decision requires processing all rules.
规则只提供权限，而不是拒绝权限。删除规则永远不能增加权限。根据对“拒绝”和“允许”规则的解释，规则的顺序可能很重要，这使得更新规则集更加复杂，因为此类更新机制必须支持在规则集中的特定位置插入。此外，这将使分布式规则集更加复杂。因此，只允许执行“允许”操作，以提高规则处理的效率。这也意味着规则顺序并不重要。因此，做出决策需要处理所有规则。
Additive permissions:
添加权限：
A query for access to data items is matched against the rules in the rule database. If several rules match, then the overall permissions granted to the WR are the union of those permissions. A more detailed discussion is provided in Section 10.
访问数据项的查询与规则数据库中的规则匹配。如果多个规则匹配，则授予WR的总体权限是这些权限的并集。第10节提供了更详细的讨论。
Upgradeable:
可升级：
It should be possible to add additional rules later, without breaking PSs that have not been upgraded. Any such upgrades must not degrade privacy constraints, but PSs not yet upgraded may reveal less information than the rule maker would have chosen.
以后应该可以添加其他规则，而不会破坏尚未升级的PSs。任何此类升级都不得降低隐私限制，但尚未升级的PSs可能会显示比规则制定者选择的信息更少的信息。
Capability support:
能力支持：
In addition to the previous goal, a RM should be able to determine which extensions are supported by the PS. The mechanism used to determine the capability of a PS is outside the scope of this specification.
除上述目标外，RM还应能够确定PS支持哪些扩展。用于确定PS能力的机制不在本规范的范围内。
Protocol-independent:
协议独立：
The rule set supports constraints on both notifications or queries as well as subscriptions for event-based systems such as presence systems.
规则集支持对通知或查询以及基于事件的系统（如状态系统）的订阅的约束。
No false assurance:
无虚假保证：
It appears more dangerous to give the user the impression that the system will prevent disclosure automatically, but fail to do so with a significant probability of operator error or misunderstanding, than to force the user to explicitly invoke simpler rules. For example, rules based on weekday and time-of-day ranges seem particularly subject to misinterpretation and false assumptions on part of the RM. (For example, a non-technical RM would probably assume that the rules are based on the time zone of his current location, which may not be known to other components of the system.)
与强迫用户明确调用更简单的规则相比，给用户的印象是系统会自动阻止披露，但如果不这样做，很可能会导致操作员错误或误解，这似乎更危险。例如，基于工作日和时间范围的规则似乎特别容易受到RM部分的误解和错误假设的影响。（例如，非技术性RM可能会假设规则基于其当前位置的时区，系统的其他组件可能不知道该时区。）
We explicitly decided that a number of possibly worthwhile capabilities are beyond the scope of this first version. Future versions may include these capabilities, using the extension mechanism described in this document. Non-goals include:
我们明确决定，许多可能有价值的功能超出了第一个版本的范围。未来版本可能包括这些功能，使用本文档中描述的扩展机制。非目标包括：
No external references:
无外部参考：
Attributes within specific rules cannot refer to external rule sets, databases, directories, or other network elements. Any such external reference would make simple database implementation difficult and hence they are not supported in this version.
特定规则中的属性不能引用外部规则集、数据库、目录或其他网络元素。任何此类外部引用都会使简单的数据库实现变得困难，因此本版本不支持这些引用。
No regular expressions:
没有正则表达式：
Conditions are matched on equality or 'greater-than'-style comparisons, not regular expressions, partial matches such as the SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches ("*@example.com"). Most of these are better expressed as explicit elements.
根据相等或“大于”样式的比较匹配条件，而不是正则表达式、部分匹配（如类SQL运算符）（如“%foo%”）或全局样式匹配（“*@example.com”）。其中大多数更好地表示为显式元素。
No repeat times:
无重复次数：
Repeat times (e.g., every day from 9 am to 4 pm) are difficult to make work correctly, due to the different time zones that PT, WR, PS, and RM may occupy. It appears that suggestions for including time intervals are often based on supporting work/non-work distinctions, which unfortunately are difficult to capture by time alone. Note that this feature must not be confused with the 'Validity' element that provides a mechanism to restrict the lifetime of a rule.
由于PT、WR、PS和RM可能占用不同的时区，重复时间（例如每天从上午9点到下午4点）很难正常工作。似乎纳入时间间隔的建议通常基于支持工作/非工作区分，不幸的是，单靠时间很难捕捉到这些区分。请注意，此功能不能与提供限制规则生存期机制的“有效性”元素混淆。
A rule set (or synonymously, a policy) consists of zero or more rules. The ordering of these rules is irrelevant. The rule set can be stored at the PS and conveyed from RM to PS as a single document, in subsets or as individual rules. A rule consists of three parts: conditions (see Section 7), actions (see Section 8), and transformations (see Section 9).
规则集（或同义词策略）由零个或多个规则组成。这些规则的顺序无关紧要。规则集可以存储在PS中，并作为单个文档、子集或单个规则从RM传送到PS。规则由三部分组成：条件（见第7节）、操作（见第8节）和转换（见第9节）。
The conditions part is a set of expressions, each of which evaluates to either TRUE or FALSE. When a WR asks for information about a PT, the PS goes through each rule in the rule set. For each rule, it evaluates the expressions in the conditions part. If all of the expressions evaluate to TRUE, then the rule is applicable to this request. Generally, each expression specifies a condition based on some variable that is associated with the context of the request. These variables can include the identity of the WR, the domain of the WR, the time of day, or even external variables, such as the temperature or the mood of the PT.
条件部分是一组表达式，每个表达式的计算结果为TRUE或FALSE。当WR请求关于PT的信息时，PS将遍历规则集中的每个规则。对于每个规则，它计算条件部分中的表达式。如果所有表达式的计算结果均为TRUE，则该规则适用于此请求。通常，每个表达式根据与请求上下文关联的某个变量指定一个条件。这些变量可以包括WR的标识、WR的域、一天中的时间，甚至外部变量，如PT的温度或情绪。
Assuming that the rule is applicable to the request, the actions and transformations (commonly referred to as permissions) in the rule specify how the PS is supposed to handle this request. If the request is to view the location of the PT, or to view its presence, the typical action is "permit", which allows the request to proceed.
假设该规则适用于该请求，则规则中的操作和转换（通常称为权限）指定PS应如何处理该请求。如果请求是查看PT的位置或查看其存在，典型的操作是“允许”，允许请求继续。
Assuming the action allows the request to proceed, the transformations part of the rule specifies how the information about the PT -- their location information, their presence, etc. -- is modified before being presented to the WR. These transformations are in the form of positive permissions. That is, they always specify a piece of information that is allowed to be seen by the WR. When a PS processes a request, it takes the transformations specified across all rules that match, and creates the union of them. For computing this union, the data type, such as Integer, Boolean, Set, or the Undef data type, plays a role. The details of the algorithm for combining permissions is described in Section 10. The resulting
假设该操作允许请求继续进行，则规则的转换部分指定在将PT的信息（其位置信息、存在情况等）呈现给WR之前如何修改。这些转换是以正向权限的形式进行的。也就是说，它们总是指定一条允许WR查看的信息。当PS处理一个请求时，它会对所有匹配的规则进行指定的转换，并创建它们的联合。对于计算此并集，数据类型（如Integer、Boolean、Set或Undef数据类型）起着重要作用。第10节详细介绍了组合权限的算法。结果
union effectively represents a "mask" -- it defines what information is exposed to the WR. This mask is applied to the actual location or presence data for the PT, and the data that is permitted by the mask is shown to the WR. If the WR requests a subset of information only (such as city-level civic location data only, instead of the full civic location information), the information delivered to the WR MUST be the intersection of the permissions granted to the WR and the data requested by the WR.
联合有效地代表了一个“面具”——它定义了向WR公开的信息。该遮罩应用于PT的实际位置或存在数据，遮罩允许的数据显示给WR。如果WR仅请求信息的子集（例如，仅城市级市政位置数据，而不是完整的市政位置信息），则交付给WR的信息必须是授予WR的权限与WR请求的数据的交叉点。
Rules are encoded in XML. To this end, Section 13 contains an XML schema defining the Common Policy Markup Language. This, however, is purely an exchange format between RM and PS. The format does not imply that the RM or the PS use this format internally, e.g., in matching a query with the policy rules. The rules are designed so that a PS can translate the rules into a relational database table, with each rule represented by one row in the database. The database representation is by no means mandatory; we will use it as a convenient and widely-understood example of an internal representation. The database model has the advantage that operations on rows have tightly defined meanings. In addition, it appears plausible that larger-scale implementations will employ a backend database to store and query rules, as they can then benefit from existing optimized indexing, access control, scaling, and integrity constraint mechanisms. Smaller-scale implementations may well choose different implementations, e.g., a simple traversal of the set of rules.
规则是用XML编码的。为此，第13节包含一个定义公共策略标记语言的XML模式。但是，这纯粹是RM和PS之间的交换格式。该格式并不意味着RM或PS在内部使用此格式，例如，在将查询与策略规则匹配时。规则的设计使得PS可以将规则转换为关系数据库表，每个规则由数据库中的一行表示。数据库表示不是强制性的；我们将使用它作为一个方便且广泛理解的内部表示示例。数据库模型的优点是对行的操作具有严格定义的含义。此外，更大规模的实现可能会使用后端数据库来存储和查询规则，因为它们可以从现有的优化索引、访问控制、缩放和完整性约束机制中获益。较小规模的实现可能会选择不同的实现，例如，对规则集的简单遍历。
Each rule is equipped with a parameter that identifies the rule. This rule identifier is an opaque token chosen by the RM. A RM MUST NOT use the same identifier for two rules that are available to the PS at the same time for a given PT. If more than one RM modifies the same rule set, then it needs to be ensured that a unique identifier is chosen for each rule. A RM can accomplish this goal by retrieving the already specified rule set and choosing a new identifier for a rule that is different from the existing rule set.
每个规则都配备了一个用于标识规则的参数。此规则标识符是RM选择的不透明令牌。RM不能对给定PT的两个PS同时可用的规则使用相同的标识符。如果多个RM修改同一规则集，则需要确保为每个规则选择唯一标识符。RM可以通过检索已指定的规则集并为不同于现有规则集的规则选择新标识符来实现此目标。
The policy framework defined in this document is meant to be extensible towards specific application domains. Such an extension is accomplished by defining conditions, actions, and transformations that are specific to the desired application domain. Each extension MUST define its own namespace.
本文档中定义的策略框架旨在扩展到特定的应用程序域。这种扩展是通过定义特定于所需应用程序域的条件、操作和转换来实现的。每个扩展必须定义自己的命名空间。
Extensions cannot change the schema defined in this document, and this schema is not expected to change except via revision to this specification. Therefore, no versioning procedures for this schema or namespace are provided.
扩展无法更改此文档中定义的架构，并且除非通过修订本规范，否则此架构不会更改。因此，不提供此架构或命名空间的版本控制过程。
The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) that are used for authorization. A rule in a rule set might have a number of conditions that need to be met before executing the remaining parts of a rule (i.e., actions and transformations). Details about rule matching are described in Section 10. This document specifies only a few conditions (i.e., identity, sphere, and validity). Further condition elements can be added via extensions to this document. If a child element of the <conditions> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
对数据项的访问需要与存储在PS上的规则集相匹配。请求的每个实例都具有用于授权的不同属性（例如，请求者的身份）。在执行规则的其余部分（即操作和转换）之前，规则集中的规则可能需要满足许多条件。有关规则匹配的详细信息，请参见第10节。本文件仅规定了几个条件（即身份、范围和有效性）。可以通过对本文档的扩展添加更多条件元素。如果<conditions>元素的子元素位于未知或不受支持的命名空间中，则该子元素的计算结果为FALSE。
As noted in Section 5, conditions are matched on equality or "greater than" style comparisons, rather than regular expressions. Equality is determined according to the rules for the data type associated with the element in the schema given in Section 13, unless explicit comparison steps are included in this document. For xs:anyURI types, readers may wish to consult [2] for its discussion xs:anyURI, as well as the text in Section 13.
如第5节所述，条件是在相等或“大于”样式比较上匹配的，而不是正则表达式。根据第13节给出的模式中与元素关联的数据类型规则确定相等性，除非本文档中包含明确的比较步骤。对于xs:anyURI类型，读者可能希望参考[2]中关于xs:anyURI的讨论以及第13节中的文本。
The identity condition restricts matching of a rule either to a single entity or a group of entities. Only authenticated entities can be matched; acceptable means of authentication are defined in protocol-specific documents. If the <identity> element is absent, identities are not considered, and thus, other conditions in the rule apply to any user, authenticated or not.
标识条件限制规则与单个实体或一组实体的匹配。只能匹配经过身份验证的实体；协议特定文档中定义了可接受的身份验证方法。如果<identity>元素不存在，则不考虑身份，因此，规则中的其他条件适用于任何用户，无论是否经过身份验证。
The <identity> condition is considered TRUE if any of its child elements (e.g., the <one/> and the <many/> elements defined in this document) evaluate to TRUE, i.e., the results of the individual child element are combined using a logical OR.
如果<identity>条件的任何子元素（例如，本文档中定义的<one/>和<many/>元素）计算为TRUE，即使用逻辑OR组合单个子元素的结果，则认为<identity>条件为TRUE。
If a child element of the <identity> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
如果<identity>元素的子元素位于未知或不受支持的命名空间中，则该子元素的计算结果为FALSE。
The <one> element matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. For considerations regarding the 'id' attribute, refer to Section 7.2.
<one>元素正好匹配一个实体或用户的身份验证标识（包含在“id”属性中）。有关“id”属性的注意事项，请参阅第7.2节。
An example is shown below:
示例如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleset>
This example matches if the authenticated identity of the WR is either sip:alice@example.com, tel:+1-212-555-1234, or mailto:bob@example.net.
如果WR的认证标识为sip:alice@example.com，电话：+1-212-555-1234，或邮寄至：bob@example.net.
The <many> element is a mechanism to perform authorization decisions based on the domain part of the authenticated identity. As such, it allows matching a large and possibly unknown number of users within a domain.
<many>元素是一种基于身份验证的域部分执行授权决策的机制。因此，它允许在一个域中匹配大量可能未知的用户。
Furthermore, it is possible to include one or multiple <except> elements to exclude either individual users or users belonging to a specific domain. Excluding individual entities is implemented using a <except id="..."/> statement. The semantic of the 'id' attribute of the <except> element has the same meaning as the 'id' attribute of the <one> element (see Section 7.2). Excluding users belonging to a specific domain is implemented using the <except domain="..."/> element that excludes any user from the indicated domain.
此外，可以包括一个或多个<except>元素以排除单个用户或属于特定域的用户。排除单个实体是使用<except id=“…”/>语句实现的。<except>元素的“id”属性的语义与<one>元素的“id”属性的语义相同（参见第7.2节）。排除属于特定域的用户是使用<except domain=“…”/>元素实现的，该元素将任何用户排除在指定域之外。
If multiple <except> elements are listed as child elements of the <many> element, then the result of each <except> element is combined using a logical OR.
如果将多个<except>元素列为<many>元素的子元素，则使用逻辑OR组合每个<except>元素的结果。
Common policy MUST either use UTF-8 or UTF-16 to store domain names in the 'domain' attribute. For non-IDNs (Internationalized Domain Names), lowercase ASCII SHOULD be used. For the comparison operation between the value stored in the 'domain' attribute and the domain value provided via the using protocol (referred to as "protocol domain identifier"), the following rules are applicable:
公共策略必须使用UTF-8或UTF-16在“域”属性中存储域名。对于非IDN（国际化域名），应使用小写ASCII。对于“域”属性中存储的值与通过使用协议（称为“协议域标识符”）提供的域值之间的比较操作，以下规则适用：
1. Translate percent-encoding for either string.
1. 转换任一字符串的百分比编码。
2. Convert both domain strings using the ToASCII operation described in RFC 3490 [3].
2. 使用RFC 3490[3]中描述的ToASCII操作转换两个域字符串。
3. Compare the two domain strings for ASCII equality, for each label. If the string comparison for each label indicates equality, the comparison succeeds. Otherwise, the domains are not equal.
3. 比较每个标签的两个域字符串的ASCII相等性。如果每个标签的字符串比较指示相等，则比较成功。否则，域不相等。
If the conversion fails in step (2), the domains are not equal.
如果在步骤（2）中转换失败，则域不相等。
The <many/> element without any child elements or attributes matches any authenticated user.
没有任何子元素或属性的<many/>元素匹配任何经过身份验证的用户。
The following example shows such a rule that matches any authenticated user:
以下示例显示了与任何经过身份验证的用户匹配的规则：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r5">
<conditions>
<identity>
<many/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r5">
<conditions>
<identity>
<many/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleset>
7.1.3.2. Matching Any Authenticated Identity Except Enumerated Domains/Identities
7.1.3.2. 匹配除枚举域/标识之外的任何经过身份验证的标识
The <many> element enclosing one or more <except domain="..."/> elements matches any user from any domain except those enumerated. The <except id="..."/> element excludes particular users. The semantics of the 'id' attribute of the <except> element is described in Section 7.2. The results of the child elements of the <many> element are combined using a logical OR.
包含一个或多个<except domain=“…”/>元素的<many>元素与来自任何域（枚举域除外）的任何用户匹配。<except id=“…”/>元素排除特定用户。第7.2节描述了<except>元素的“id”属性的语义。使用逻辑OR组合<many>元素的子元素的结果。
An example is shown below:
示例如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<sphere value="work"/>
<identity>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1">
<conditions>
<sphere value="work"/>
<identity>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleset>
This example matches all users except any user in example.com, or any user in example.org or the particular users alice@bad.example.net, bob@good.example.net, and the user with the telephone number 'tel:+1-212-555-1234'. The last 'except' element is redundant since alice@example.com is already excluded through the first line.
此示例匹配除example.com中的任何用户、example.org中的任何用户或特定用户之外的所有用户alice@bad.example.net, bob@good.example.net，以及电话号码为“电话：+1-212-555-1234”的用户。最后一个“除外”元素是多余的，因为alice@example.com已通过第一行排除。
7.1.3.3. Matching Any Authenticated Identity within a Domain Except Enumerated Identities
7.1.3.3. 匹配域中除枚举标识以外的任何经过身份验证的标识
The <many> element with a 'domain' attribute and zero or more <except id="..."/> elements matches any authenticated user from the indicated domain except those explicitly enumerated. The semantics of the 'id' attribute of the <except> element is described in Section 7.2.
具有“domain”属性和零个或多个<except id=“…”/>元素的<many>元素与指定域中的任何经过身份验证的用户（显式枚举的用户除外）匹配。第7.2节描述了<except>元素的“id”属性的语义。
It is nonsensical to have domains in the 'id' attribute that do not match the value of the 'domain' attribute in the enclosing <many> element.
“id”属性中的域与封闭的<many>元素中的“domain”属性的值不匹配是毫无意义的。
An example is shown below:
示例如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleset>
This example matches any user within example.com (such as carol@example.com) except alice@example.com and bob@example.com.
此示例匹配example.com中的任何用户（例如carol@example.com)除了alice@example.com和bob@example.com.
The 'id' attribute used in the <one> and in the <except> element refers to a single entity. In the subsequent text, we use the term 'single-user entity' as a placeholder for the <one> and the <except> element. The <except> element fulfills the purpose of excluding elements from the solution set.
<one>和<except>元素中使用的“id”属性引用单个实体。在随后的文本中，我们使用术语“单用户实体”作为<one>和<except>元素的占位符。<except>元素实现了从解决方案集中排除元素的目的。
A single-user entity matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. If there is a match, the single-user entity is considered TRUE. The single-user entity MUST NOT contain a 'domain' attribute.
单个用户实体与一个实体或用户的身份验证标识（包含在“id”属性中）完全匹配。如果存在匹配项，则认为单用户实体为真。单用户实体不能包含“域”属性。
The 'id' attribute contains an identity that MUST first be expressed as a URI. Applications using this framework must describe how the identities they are using can be expressed as URIs.
“id”属性包含必须首先表示为URI的标识。使用此框架的应用程序必须描述如何将其使用的标识表示为URI。
The <sphere> element belongs to the group of condition elements. It can be used to indicate a state (e.g., 'work', 'home', 'meeting', 'travel') the PT is currently in. A sphere condition matches only if the PT is currently in the state indicated. The state may be conveyed by manual configuration or by some protocol. For example, RPID [10] provides the ability to inform the PS of its current sphere. The application domain needs to describe in more detail how the sphere state is determined. Switching from one sphere to another causes a switch between different modes of visibility. As a result, different subsets of rules might be applicable.
<sphere>元素属于条件元素组。它可用于指示PT当前所处的状态（例如，“工作”、“家庭”、“会议”、“旅行”）。仅当PT当前处于指示状态时，球体条件才匹配。该状态可以通过手动配置或某些协议进行传输。例如，RPID[10]提供了通知PS其当前球体的能力。应用领域需要更详细地描述如何确定球体状态。从一个球体切换到另一个球体会导致在不同的可见性模式之间切换。因此，可能适用不同的规则子集。
The content of the 'value' attribute of the <sphere> element MAY contain more than one token. The individual tokens MUST be separated by a blank character. A logical OR is used for the matching the tokens against the sphere settings of the PT. As an example, if the content of the 'value' attribute in the sphere attribute contains two tokens 'work' and 'home' then this part of the rule matches if the sphere for a particular PT is either 'work' OR 'home'. To compare the content of the 'value' attribute in the <sphere> element with the stored state information about the PT's sphere setting a case-insensitive string comparison MUST be used for each individual token. There is neither a registry for these values nor a language-specific indication of the sphere content. As such, the tokens are treated as opaque strings.
<sphere>元素的“value”属性的内容可能包含多个标记。各个标记必须用空白字符分隔。逻辑OR用于将令牌与PT的球体设置相匹配。例如，如果sphere属性中的'value'属性的内容包含两个标记'work'和'home'，那么如果特定PT的sphere是'work'或'home'，则该部分规则匹配。要将<sphere>元素中的'value'属性的内容与存储的关于PT球体设置的状态信息进行比较，必须对每个标记使用不区分大小写的字符串比较。这些值既没有注册表，也没有特定于语言的球体内容指示。因此，标记被视为不透明字符串。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<sphere value="work"/>
<identity>
<one id="sip:andrew@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r2">
<conditions>
<sphere value="work"/>
<identity>
<one id="sip:andrew@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="y6y55r2">
<conditions>
<sphere value="home"/>
<identity>
<one id="sip:allison@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="y6y55r2">
<conditions>
<sphere value="home"/>
<identity>
<one id="sip:allison@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="z6y55r2">
<conditions>
<identity>
<one id="sip:john@doe.example.com"/>
</identity>
<sphere value="home work"/>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="z6y55r2">
<conditions>
<identity>
<one id="sip:john@doe.example.com"/>
</identity>
<sphere value="home work"/>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
The rule example above illustrates that the rule with the entity andrew@example.com matches if the sphere is been set to 'work'. In the second rule, the entity allison@example.com matches if the sphere is set to 'home'. The third rule also matches since the value in the sphere element also contains the token 'home'.
上面的规则示例说明了规则与实体andrew@example.com如果球体设置为“工作”，则匹配。在第二条规则中，实体allison@example.com如果球体设置为“主页”，则匹配。第三条规则也匹配，因为sphere元素中的值也包含标记“home”。
The <validity> element is the third condition element specified in this document. It expresses the rule validity period by two attributes, a starting and an ending time. The validity condition is TRUE if the current time is greater than or equal to at least one <from> child, but less than the <until> child after it. This represents a logical OR operation across each <from> and <until> pair. Times are expressed in XML dateTime format. A rule maker might not always have access to the PS to invalidate some rules that grant permissions. Hence, this mechanism allows invalidating granted permissions automatically without further interaction between the rule maker and the PS. The PS does not remove the rules; instead the rule maker has to clean them up.
<validity>元素是本文档中指定的第三个条件元素。它通过两个属性表示规则有效期，即开始时间和结束时间。如果当前时间大于或等于至少一个<from>子项，但小于其后的<until>子项，则有效性条件为真。这表示跨越每个<from>和<until>对的逻辑OR操作。时间以XML日期时间格式表示。规则制定者可能并不总是能够访问PS以使授予权限的某些规则无效。因此，此机制允许自动使授予的权限无效，而无需规则制定者和PS之间进一步交互。PS不会删除规则；相反，规则制定者必须清理它们。
An example of a rule fragment is shown below:
规则片段的示例如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r3">
<conditions>
<validity>
<from>2003-08-15T10:20:00.000-05:00</from>
<until>2003-09-15T10:20:00.000-05:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="f3g44r3">
<conditions>
<validity>
<from>2003-08-15T10:20:00.000-05:00</from>
<until>2003-09-15T10:20:00.000-05:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
The <validity> element MUST have the <from> and <until> subelements in pairs. Multiple <from> and <until> elements might appear in pairs (i.e., without nesting of <from> and <until> elements). Using multiple <validity> elements as subelements of the <conditions> element is not useful since all subelements of the <conditions> element are combined as a logical AND.
<validity>元素必须成对地包含<from>和<until>子元素。多个<from>和<until>元素可能成对出现（即没有<from>和<until>元素嵌套）。使用多个<validity>元素作为<conditions>元素的子元素是没有用的，因为<conditions>元素的所有子元素都作为逻辑AND组合。
While conditions are the 'if'-part of rules, actions and transformations form their 'then'-part. The actions and transformations parts of a rule determine which operations the PS MUST execute after having received from a WR a data access request that matches all conditions of this rule. Actions and transformations only permit certain operations; there is no 'deny' functionality. Transformations exclusively specify PS-side operations that lead to a modification of the data items requested by the WR. Regarding location data items, for instance, a transformation could force the PS to lower the precision of the location information that is returned to the WR.
虽然条件是规则的“如果”部分，但动作和转换形成了它们的“那么”部分。规则的操作和转换部分确定PS从WR接收到符合该规则所有条件的数据访问请求后必须执行的操作。操作和转换只允许某些操作；没有“拒绝”功能。转换专门指定导致修改WR请求的数据项的PS端操作。例如，关于位置数据项，转换可能会迫使PS降低返回给WR的位置信息的精度。
Actions, on the other hand, specify all remaining types of operations the PS is obliged to execute, i.e., all operations that are not of transformation type. Actions are defined by application-specific usages of this framework. The reader is referred to the corresponding extensions to see examples of such elements.
另一方面，操作指定PS必须执行的所有剩余操作类型，即所有非转换类型的操作。操作由此框架的特定于应用程序的用法定义。读者可以参考相应的扩展来查看这些元素的示例。
Two sub-parts follow the conditions part of a rule: transformations and actions. As defined in Section 8, transformations specify operations that the PS MUST execute and that modify the result that is returned to the WR. This functionality is particularly helpful in reducing the granularity of information provided to the WR, as, for example, required for location privacy. Transformations are defined by application-specific usages of this framework.
两个子部分遵循规则的条件部分：转换和操作。如第8节所定义，转换指定PS必须执行的操作以及修改返回给WR的结果的操作。该功能在降低提供给WR的信息的粒度方面特别有用，例如，位置隐私所需的粒度。转换由该框架的特定于应用程序的用法定义。
A simple transformation example is provided in Section 10.
第10节提供了一个简单的转换示例。
This section describes how rules are selected and how actions and permissions are determined. When a PS receives a request for access to privacy-sensitive data, the request is matched against the rule set. A rule matches if all conditions contained as child elements in the <conditions> element of a rule evaluate to TRUE. Each type of condition defines when it is TRUE. All rules where the conditions match the request form the matching rule set. The permissions in the matching rule set are combined using a set of combining rules (CRs) described in Section 10.2.
本节介绍如何选择规则以及如何确定操作和权限。当PS收到访问隐私敏感数据的请求时，该请求与规则集匹配。如果规则的<conditions>元素中作为子元素包含的所有条件计算为TRUE，则规则匹配。每种类型的条件定义其为真的时间。条件与请求匹配的所有规则构成匹配规则集。使用第10.2节所述的一组组合规则（CRs）组合匹配规则集中的权限。
Each type of permission is combined across all matching rules. Each type of action or transformation is combined separately and independently. The combining rules generate a combined permission. The combining rules depend only on the data type of permission. If a particular permission type has no value in a rule, it assumes the lowest possible value for that permission for the purpose of computing the combined permission. That value is given by the data type for booleans (FALSE) and sets (empty set), and MUST be defined by any extension to the Common Policy for other data types.
每种类型的权限都跨所有匹配规则进行组合。每种类型的动作或转换都是独立组合的。组合规则生成一个组合权限。组合规则仅取决于权限的数据类型。如果某个特定的权限类型在规则中没有值，则为了计算组合的权限，它将假定该权限的最低可能值。该值由布尔值（FALSE）和集合（空集）的数据类型给出，并且必须由其他数据类型的公共策略的任何扩展来定义。
For boolean permissions, the resulting permission is TRUE if and only if at least one permission in the matching rule set has a value of TRUE and FALSE otherwise. For integer, real-valued and date-time permissions, the resulting permission is the maximum value across the permission values in the matching set of rules. For sets, it is the union of values across the permissions in the matching rule set.
对于布尔权限，当且仅当匹配规则集中至少有一个权限的值为TRUE和FALSE时，生成的权限为TRUE，否则为FALSE。对于整数、实数和日期时间权限，生成的权限是匹配规则集中权限值的最大值。对于集合，它是匹配规则集中跨权限的值的并集。
In the following example we illustrate the process of combining permissions. We will consider three conditions for our purpose, namely those of name identity (WR-ID), sphere, and validity (from,until). The ID column is used as a rule identifier. For editorial reasons we omit the domain part of the WR's identity.
在下面的示例中，我们演示了组合权限的过程。我们将考虑三个条件，我们的目的，即名称身份（WR-ID），球，和有效性（从，直到）。ID列用作规则标识符。出于编辑原因，我们省略了WR标识的域部分。
We use two actions in our example, namely X and Y. The values of X and Y are of data types Boolean and Integer, respectively.
在我们的示例中，我们使用了两个动作，即X和Y。X和Y的值分别为Boolean和Integer数据类型。
The transformation, referred to as Z, uses values that can be set either to '+' (or 3), 'o' (or 2) or '-' (or 1). Permission Z allows us to show the granularity reduction whereby a value of '+' shows the corresponding information unrestricted, and '-' shows nothing. This permission might be related to location information or other presence attributes like mood. Internally, we use the data type Integer for computing the permission of this attribute.
转换（称为Z）使用的值可以设置为“+”（或3）、“o”（或2）或“-”（或1）。权限Z允许我们显示粒度缩减，其中值“+”表示不受限制的相应信息，“-”不表示任何内容。此权限可能与位置信息或其他状态属性（如mood）相关。在内部，我们使用数据类型Integer来计算该属性的权限。
The label 'NULL' in the table indicates that no value is available for a particular cell.
表中的标签“NULL”表示特定单元格没有可用的值。
Conditions Actions/Transformations
+---------------------------------+---------------------+
| Id WR-ID sphere from until | X Y Z |
+---------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | NULL 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+---------------------------------+---------------------+
Conditions Actions/Transformations
+---------------------------------+---------------------+
| Id WR-ID sphere from until | X Y Z |
+---------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | NULL 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+---------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for the two <validity> attributes 'from' and 'until':
同样出于编辑原因，我们对“from”和“until”这两个<validity>属性使用以下缩写：
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
Note that B1 < B2 < A1 < A2 < A3.
注意B1<B2<A1<A2<A3。
The entity 'bob' acts as a WR and requests data items. The rule set consists of the six rules shown in the table and identified by the values 1 to 6 in the 'Id' column. The PS receives the query at
实体“bob”充当WR并请求数据项。规则集由表中所示的六条规则组成，并由“Id”列中的值1到6标识。PS在以下位置接收查询：
2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our example, we assume that the sphere value of the PT is currently set to 'work'.
2003-12-24T17:15:00+01:00，介于A1和A2之间。在我们的示例中，我们假设PT的球体值当前设置为“work”。
As a first step, it is necessary to determine which rules fire by evaluating the conditions part of each of them.
作为第一步，有必要通过评估每个规则的条件部分来确定哪些规则着火。
Rule 1 does not match since the sphere condition does not match. Rule 2 does not match as the identity of the WR (here 'alice') does not equal 'bob'. Rule 3 matches since all conditions evaluate to TRUE. Rule 4 does not match as the identity of the WR (here 'tom') does not equal 'bob'. Rule 5 matches. Rule 6 does not match since the rule is not valid anymore.
规则1不匹配，因为球体条件不匹配。规则2不匹配，因为WR的标识（此处为“alice”）不等于“bob”。规则3匹配，因为所有条件的计算结果都为TRUE。规则4不匹配，因为WR的标识（此处为“tom”）不等于“bob”。规则5匹配。规则6不匹配，因为该规则不再有效。
Only rules 3 and 5 fire. We use the actions and transformations part of these two rules to determine the combined permission, as shown below.
只有规则3和5会开火。我们使用这两个规则的操作和转换部分来确定组合权限，如下所示。
Actions/Transformations
+-----+-----------------------+
| Id | X Y Z |
+-----+-----------------------+
| 3 | TRUE 3 - |
| 5 | NULL 12 o |
+-----+-----------------------+
Actions/Transformations
+-----+-----------------------+
| Id | X Y Z |
+-----+-----------------------+
| 3 | TRUE 3 - |
| 5 | NULL 12 o |
+-----+-----------------------+
Each column is treated independently. The combined value of X is set to TRUE since the NULL value equals FALSE according to the description in Section 10.2. For the column with the name Y, we apply the maximum of 3 and 12, so that the combined value of Y is 12. For column Z, we again compute the maximum of 'o' and '-' (i.e., 2 and 1) which is 'o' (2).
每一列都是独立处理的。根据第10.2节中的说明，由于空值等于FALSE，因此X的组合值设置为TRUE。对于名称为Y的列，我们应用最大值3和12，因此Y的组合值为12。对于Z列，我们再次计算“o”和“-”（即2和1）的最大值，即“o”（2）。
The combined permission for all three columns is therefore:
因此，所有三列的组合权限为：
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 o |
+-----------------------+
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 o |
+-----------------------+
Meta policies authorize a rule maker to insert, update, or delete a particular rule or an entire rule set. Some authorization policies are required to prevent unauthorized modification of rule sets. Meta policies are outside the scope of this document.
元策略授权规则制定者插入、更新或删除特定规则或整个规则集。需要一些授权策略来防止未经授权修改规则集。元策略不在本文档的范围内。
A simple implementation could restrict access to the rule set only to the PT but more sophisticated mechanisms could be useful. As an example of such policies, one could think of parents configuring the policies for their children.
一个简单的实现可以将对规则集的访问限制为PT，但更复杂的机制可能会有用。作为此类政策的一个例子，可以想象父母为子女配置政策。
This section gives an example of an XML document valid with respect to the XML schema defined in Section 13. Semantically richer examples can be found in documents that extend this schema with application-domain-specific data (e.g., location or presence information).
本节给出了一个相对于第13节中定义的XML模式有效的XML文档示例。语义更丰富的示例可以在使用特定于应用程序域的数据（例如，位置或状态信息）扩展此模式的文档中找到。
Below a rule is shown with a condition that matches for a given authenticated identity (bob@example.com) and within a given time period. Additionally, the rule matches only if the target has set its sphere to 'work'.
下面显示了一条规则，其中的条件与给定的经过身份验证的标识相匹配(bob@example.com)在给定的时间段内。此外，该规则仅在目标将其球体设置为“工作”时匹配。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This section provides the XML schema definition for the common policy markup language described in this document.
本节提供本文档中描述的公共策略标记语言的XML模式定义。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- /ruleset -->
<xs:element name="ruleset">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- /ruleset/rule -->
<xs:complexType name="ruleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="conditions"
type="cp:conditionsType" minOccurs="0"/>
<xs:element name="actions"
type="cp:extensibleType" minOccurs="0"/>
<xs:element name="transformations"
type="cp:extensibleType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/conditions -->
<xs:complexType name="conditionsType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice maxOccurs="unbounded">
<xs:element name="identity"
type="cp:identityType" minOccurs="0"/>
<xs:element name="sphere"
type="cp:sphereType" minOccurs="0"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- /ruleset -->
<xs:element name="ruleset">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- /ruleset/rule -->
<xs:complexType name="ruleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="conditions"
type="cp:conditionsType" minOccurs="0"/>
<xs:element name="actions"
type="cp:extensibleType" minOccurs="0"/>
<xs:element name="transformations"
type="cp:extensibleType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/conditions -->
<xs:complexType name="conditionsType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice maxOccurs="unbounded">
<xs:element name="identity"
type="cp:identityType" minOccurs="0"/>
<xs:element name="sphere"
type="cp:sphereType" minOccurs="0"/>
<xs:element name="validity"
type="cp:validityType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/identity -->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/one -->
<xs:complexType name="oneType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:sequence>
<xs:attribute name="id"
type="xs:anyURI" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/many -->
<xs:complexType name="manyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:choice>
<xs:attribute name="domain"
use="optional" type="xs:string"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //many/except -->
<xs:element name="validity"
type="cp:validityType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/identity -->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/one -->
<xs:complexType name="oneType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:sequence>
<xs:attribute name="id"
type="xs:anyURI" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/many -->
<xs:complexType name="manyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:choice>
<xs:attribute name="domain"
use="optional" type="xs:string"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //many/except -->
<xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- //conditions/sphere -->
<xs:complexType name="sphereType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="value"
type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/validity -->
<xs:complexType name="validityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="until" type="xs:dateTime"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/actions or //rule/transformations -->
<xs:complexType name="extensibleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
<xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- //conditions/sphere -->
<xs:complexType name="sphereType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="value"
type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/validity -->
<xs:complexType name="validityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="until" type="xs:dateTime"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/actions or //rule/transformations -->
<xs:complexType name="extensibleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
This document describes a framework for policies. This framework is intended to be enhanced elsewhere by application-domain-specific data. Security considerations are to a great extent application-data dependent, and therefore need to be covered by documents that extend the framework defined in this specification. However, new action and transformation permissions along with their allowed values must be defined in a way so that the usage of the permissions combining rules of Section 10 does not lower the level of privacy protection. See Section 10 for more details on this privacy issue.
本文档描述了策略的框架。该框架旨在通过特定于应用程序域的数据在其他地方得到增强。安全注意事项在很大程度上依赖于应用程序数据，因此需要在扩展本规范中定义的框架的文档中加以说明。但是，必须以某种方式定义新的操作和转换权限及其允许值，以便使用第10节的权限组合规则不会降低隐私保护级别。有关此隐私问题的更多详细信息，请参见第10节。
This section registers a new XML namespace, a new XML schema, and a new MIME type. This section registers a new XML namespace per the procedures in [4].
本节注册一个新的XML名称空间、一个新的XML模式和一个新的MIME类型。本节按照[4]中的过程注册一个新的XML命名空间。
URI: urn:ietf:params:xml:ns:common-policy
URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
注册人联系人：IETF GEOPRIV工作组，Henning Schulzrinne（hgs+geopriv@cs.columbia.edu).
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>Common Policy Namespace</title>
</head>
<body>
<h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
RFC 4745</a>.</p>
</body>
</html>
END
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>Common Policy Namespace</title>
</head>
<body>
<h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
RFC 4745</a>.</p>
</body>
</html>
END
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [5] and guidelines in RFC 3023 [6].
本规范要求根据RFC 4288[5]的程序和RFC 3023[6]中的指南注册新的MIME类型。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: auth-policy+xml
MIME子类型名称：身份验证策略+xml
Mandatory parameters: none
强制参数：无
Optional parameters: charset
可选参数：字符集
Indicates the character encoding of enclosed XML.
指示封闭XML的字符编码。
Encoding considerations:
编码注意事项：
Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [6], Section 3.2.
使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[6]，第3.2节。
Security considerations:
安全考虑：
This content type is designed to carry authorization policies. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to Section 14 of RFC 4745 and to the security considerations described in Section 10 of RFC 3023 [6] for more information.
此内容类型旨在承载授权策略。应采取适当的预防措施来限制该信息的披露。有关更多信息，请参考RFC 4745第14节和RFC 3023[6]第10节中描述的安全注意事项。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 4745
已发布规范：RFC 4745
Applications which use this media type:
使用此媒体类型的应用程序：
Presence- and location-based systems
基于存在和位置的系统
Additional information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .apxml
文件扩展名：.apxml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com
更多信息的个人和电子邮件地址：Hannes Tschofenig，Hannes。Tschofenig@siemens.com
Intended usage: LIMITED USE
预期用途：有限用途
Author:
作者：
This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org>.
本规范是IETF GEOPRIV工作组的工作项，具有邮件列表地址<geopriv@ietf.org>.
Change controller:
更改控制器：
The IESG <iesg@ietf.org>
The IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:common-policy
URI: urn:ietf:params:xml:schema:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
注册人联系人：IETF GEOPRIV工作组，Henning Schulzrinne（hgs+geopriv@cs.columbia.edu).
XML: The XML schema to be registered is contained in Section 13. Its first line is
XML：要注册的XML模式包含在第13节中。它的第一行是
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
最后一行是
</xs:schema>
</xs:schema>
[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] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[2] Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[3] Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[5] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[7] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[7] Rosenberg，J.，“在场授权规则”，正在进行的工作，2006年6月。
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, February 2006.
[8] Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，和J.Polk，“表达位置信息隐私偏好的文档格式”，正在进行的工作，2006年2月。
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9] Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[10] Schulzrinne，H.，Gurbani，V.，Kyzivat，P.，和J.Rosenberg，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，RFC 44802006年7月。
We would like to thank Christian Guenther for his help with initial versions of this document.
我们要感谢Christian Guenther对本文件初始版本的帮助。
This document is partially based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C., helped the working group to make progress on the authorization policies based on the discussions among the participants.
本文件部分基于IETF GEOPRIV工作组内的讨论。2003年在华盛顿特区举行的Geopriv临时会议上的讨论帮助工作组根据与会者之间的讨论在授权政策方面取得了进展。
We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for discussing a number of details with us. They helped us to improve the quality of this document. Allison, Ted, and Andrew also helped us to make good progress with the internationalization support of the identifier/ domain attributes.
我们特别要感谢Allison Mankin<mankin@psg.com>，Randall Gellens<rg+ietf@qualcomm.com>，安德鲁·牛顿<anewton@ecotroph.net>，特德·哈迪<hardie@qualcomm.com>和乔恩·彼得森。peterson@neustar.biz>谢谢你和我们讨论一些细节。他们帮助我们提高了这份文件的质量。Allison、Ted和Andrew还帮助我们在标识符/域属性的国际化支持方面取得了良好的进展。
Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on presence authorization policies. We would also like to thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their comments. Martin Thomson helped us with the XML schema. Mark Baker provided a review of the media type. Scott Brim provided a review on behalf of the General Area Review Team.
此外，我们还要感谢IETF简单工作组讨论J.Rosenberg关于存在授权政策的草案。我们还要感谢Stefan Berg、Murugaraj Shanmugam、Christian Schmidt、Martin Thomson、Markus Isomaki、Aki Niemi、Eva Maria Leppanen、Josip Matanovic和Mark Baker的评论。Martin Thomson帮助我们使用XML模式。马克·贝克对媒体类型进行了回顾。Scott Brim代表一般区域审查小组进行了审查。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Phone: +1 212 939 7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑市奥托哈恩6环汉内斯·茨霍芬尼西门子网络股份有限公司，邮编81739
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
美国华盛顿特区西北I街1634号，1100室，民主与技术中心，小约翰B.莫里斯，邮编：20006
EMail: jmorris@cdt.org
URI: http://www.cdt.org
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑6环豪尔赫R.库利亚尔西门子奥托哈恩81739
EMail: Jorge.Cuellar@siemens.com
EMail: Jorge.Cuellar@siemens.com
James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
詹姆斯·波尔克思科2200美国德克萨斯州乔治·布什收费公路理查森，邮编75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA
Jonathan Rosenberg Cisco Systems 600美国纽约帕西帕尼拉尼德广场07054
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。