Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7199 M. Thomson
Category: Standards Track Mozilla
ISSN: 2070-1721 J. Winterbottom
Unaffiliated
H. Tschofenig
April 2014
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7199 M. Thomson
Category: Standards Track Mozilla
ISSN: 2070-1721 J. Winterbottom
Unaffiliated
H. Tschofenig
April 2014
Location Configuration Extensions for Policy Management
用于策略管理的位置配置扩展
Abstract
摘要
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.
当前位置配置协议能够为Internet主机提供指向主机位置的位置URI。这些协议缺少一种机制，目标主机无法检查或设置应用于它们分发的URI的隐私规则。本文档扩展了当前位置配置协议，为主机提供对应用于URI的规则的引用，以便主机可以查看或设置这些规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7199.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7199.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7
4. Location Configuration Extensions . . . . . . . . . . . . . . 8
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Basic Access Control Policy . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Access Control for Authorization Policy . . . . . . . . . 13
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15
7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Example Policy URI Generation Algorithm . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7
4. Location Configuration Extensions . . . . . . . . . . . . . . 8
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Basic Access Control Policy . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Access Control for Authorization Policy . . . . . . . . . 13
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15
7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Example Policy URI Generation Algorithm . . . . . . 18
A critical step in enabling Internet hosts to access location-based services is to provision those hosts with information about their own location. This is accomplished via a Location Configuration Protocol (LCP) [RFC5687], which allows a location provider (e.g., a local access network) to inform a host about its location.
使Internet主机能够访问基于位置的服务的一个关键步骤是为这些主机提供有关其自身位置的信息。这是通过位置配置协议（LCP）[RFC5687]实现的，该协议允许位置提供者（例如，本地接入网络）通知主机其位置。
There are two basic patterns for location configuration, namely configuration "by value" and "by reference" [RFC5808]. Configuration by value provisions a host directly with its location, by providing it location information that is directly usable (e.g., coordinates or a civic address). Configuration by reference provides a host with a URI that references the host's location, i.e., one that can be dereferenced to obtain the location (by value) of the host.
位置配置有两种基本模式，即配置“按值”和“按引用”[RFC5808]。按值配置通过向主机提供可直接使用的位置信息（例如坐标或公民地址），直接向主机提供其位置。通过引用配置为主机提供一个URI，该URI引用主机的位置，即可以取消引用以获取主机的位置（通过值）。
In some cases, location by reference offers a few benefits over location by value. From a privacy perspective, the required dereference transaction provides a policy enforcement point so that if suitable privacy policies have been provisioned, the opaque location URI can be safely conveyed over untrusted media. (If the location URI is not subject to privacy rules, then conveying the location URI may pose even greater risk than sending location by value [RFC5606].) If the target host is mobile, an application provider can use a single reference to obtain the location of the host multiple times, saving bandwidth to the host. For some configuration protocols, the location object referenced by a location URI provides a much more expressive syntax for location values than the configuration protocol itself (e.g., DHCP geodetic location [RFC6225] versus Geography Markup Language (GML) in a Presence Information Data Format Location Object (PIDF-LO) [RFC4119]).
在某些情况下，参照定位比价值定位有一些好处。从隐私的角度来看，所需的取消引用事务提供了一个策略实施点，因此，如果提供了合适的隐私策略，则不透明位置URI可以通过不受信任的媒体安全传输。（如果位置URI不受隐私规则的约束，那么传递位置URI可能比按值发送位置[RFC5606]带来更大的风险。）如果目标主机是移动的，应用程序提供商可以使用单个引用多次获取主机的位置，从而为主机节省带宽。对于一些配置协议，由位置URI引用的位置对象为位置值提供了比配置协议本身更具表现力的语法（例如，存在信息数据格式位置对象（PIDF-LO）[RFC4119]中的DHCP大地位置[RFC6225]与地理标记语言（GML））。
From a privacy perspective, however, current LCPs are limited in their flexibility, in that they do not provide hosts (the clients in an LCP) with a way to inform the Location Server with policy for how his location information should be handled. This document addresses this gap by defining a simple mechanism for referring to and manipulating policy and by extending current LCPs to carry policy references. Using the mechanisms defined in this document, an LCP server (acting for the Location Server (LS) or Location Information Server (LIS)) can inform a host as to which policy document controls a given location resource, and the host (in its Rule Maker role) can inspect this document and modify it as necessary.
然而，从隐私的角度来看，当前LCP的灵活性有限，因为它们不向主机（LCP中的客户端）提供一种方法来通知位置服务器如何处理其位置信息的策略。本文档通过定义引用和操作策略的简单机制，并通过扩展当前LCP以承载策略引用，解决了这一差距。使用本文档中定义的机制，LCP服务器（代表位置服务器（LS）或位置信息服务器（LIS））可以通知主机哪个策略文档控制给定的位置资源，并且主机（以其规则制定者角色）可以检查此文档并根据需要对其进行修改。
In the following figure, adapted from RFC 5808, this document extends the Location Configuration Protocols (1) and defines a simple protocol for policy exchange (4).
在下图（改编自RFC 5808）中，本文档扩展了位置配置协议（1）并定义了用于策略交换的简单协议（4）。
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol
| |(1) |(2)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol
| |(1) |(2)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
The remainder of this document is structured as follows:
本文件其余部分的结构如下：
After introducing a few relevant terms, we define policy URIs as a channel for referencing, inspecting, and updating policy documents. We then define an extension to the HELD protocol to allow it to carry policy URIs. Examples are given that demonstrate how policy URIs are carried in this protocol and how it can be used by clients.
在介绍了一些相关术语之后，我们将策略URI定义为引用、检查和更新策略文档的通道。然后，我们定义了对HOLD协议的扩展，以允许它携带策略URI。文中给出的示例演示了策略URI在该协议中的承载方式以及客户端如何使用它。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818] URI that identifies a policy resource that contains the authorization policy for a linked location resource. Access to the location resource is governed by the contents of the authorization policy.
策略URI是HTTP[RFC2616]或HTTPS[RFC2818]URI，用于标识包含链接位置资源的授权策略的策略资源。对位置资源的访问由授权策略的内容控制。
A policy URI identifies an HTTP resource that a Rule Maker can use to inspect and install policy documents that tell a Location Server how it should protect the associated location resource. A policy URI always identifies a resource that can be represented as a common-policy document [RFC4745] (possibly including some extensions; e.g., for geolocation policy [RFC6772]).
策略URI标识HTTP资源，规则制定者可以使用该资源检查和安装策略文档，这些文档告诉位置服务器应该如何保护关联的位置资源。策略URI始终标识可以表示为公共策略文档[RFC4745]（可能包括一些扩展；例如，用于地理位置策略[RFC6772]）的资源。
Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one that stores policy information. In this document, the Location Server is also a Rule Holder.
注意：RFC 3693[RFC3693]将规则持有者角色标识为存储策略信息的角色。在本文档中，位置服务器也是规则持有者。
A Location Server that is the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, in order to allow clients to inspect, replace, and delete policy documents. Clients support the three request methods as they desire to perform these operations.
作为策略URI权限的位置服务器必须支持对这些URI的GET、PUT和DELETE请求，以便允许客户端检查、替换和删除策略文档。客户机支持这三种请求方法，因为它们希望执行这些操作。
Knowledge of the policy URI can be considered adequate evidence of authorization; a policy URI functions as a shared secret between the client and the server (see Section 7). A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT). Or, a Location Server might require clients to authenticate using HTTP or Transport Layer Security (TLS) client authentication. Clients implementing this specification SHOULD support HTTP client authentication [RFC2617] and MAY support TLS client certificates.
了解策略URI可被视为授权的充分证据；策略URI充当客户端和服务器之间的共享机密（请参见第7节）。位置服务器应该允许所有请求，但它可以基于本地策略拒绝某些请求。例如，位置服务器可能允许客户端检查策略（GET），但不允许更新策略（PUT）。或者，位置服务器可能要求客户端使用HTTP或传输层安全（TLS）客户端身份验证进行身份验证。实现此规范的客户端应支持HTTP客户端身份验证[RFC2617]，并可能支持TLS客户端证书。
A GET request to a policy URI is a request for the referenced policy information. If the request is authorized, then the Location Server sends an HTTP 200 response containing the complete policy identified by the URI.
对策略URI的GET请求是对引用的策略信息的请求。如果请求得到授权，那么位置服务器将发送一个HTTP 200响应，其中包含URI标识的完整策略。
A PUT request to a policy URI is a request to replace the current policy. The entity-body of a PUT request includes a complete policy document. When a Location Server receives a PUT request, it MUST validate the policy document included in the body of the request. If the request is valid and authorized, then the Location Server MUST replace the current policy with the policy provided in the request.
对策略URI的PUT请求是替换当前策略的请求。PUT请求的实体主体包括完整的策略文档。当位置服务器收到PUT请求时，它必须验证请求正文中包含的策略文档。如果请求有效且经过授权，则位置服务器必须使用请求中提供的策略替换当前策略。
A DELETE request to a policy URI is a request to delete the referenced policy document. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request.
对策略URI的删除请求是删除引用的策略文档的请求。如果请求已授权，则位置服务器必须删除URI引用的策略，并且在通过put请求放置新策略文档之前，不允许访问其管辖的位置URI。
A policy URI is only valid while the corresponding location URI set is valid. A Location Server MUST NOT respond to any requests to a policy URI once the corresponding location URI set has expired. This expiry time is specified by the 'expires' attribute in the HELD locationResponse.
策略URI仅在相应的位置URI集有效时有效。一旦相应的位置URI集过期，位置服务器不得响应对策略URI的任何请求。此过期时间由Hold locationResponse中的“expires”属性指定。
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy. The latter one is permanent, since the expiry causes the policy URI to be invalidated as well.
因此，位置URI可能以三种方式变得无效：策略中的有效期间隔到期、通过删除请求删除策略文档，或者LCP指定的有效期间隔到期。前两个是临时的，因为可以使用策略URI来更新策略。后者是永久性的，因为过期也会导致策略URI无效。
The Location Server MUST support policy documents in the common-policy format [RFC4745], as identified by the MIME media type of "application/auth-policy+xml". The common-policy format MUST be provided as the default format in response to GET requests that do not include specific "Accept" headers, but content negotiation MAY be used to allow for other formats.
位置服务器必须支持公共策略格式[RFC4745]的策略文档，该格式由MIME媒体类型“application/auth policy+xml”标识。公共策略格式必须作为默认格式提供，以响应不包含特定“接受”头的GET请求，但可以使用内容协商来允许其他格式。
This usage of HTTP is generally compatible with the use of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] or Web Distributed Authoring and Versioning (WebDAV) [RFC4918] to manage policy documents, but this document does not define or require the use of these protocols.
HTTP的这种使用通常与使用可扩展标记语言（XML）配置访问协议（XCAP）[RFC4825]或Web分布式创作和版本控制（WebDAV）[RFC4918]来管理策略文档兼容，但本文档未定义或要求使用这些协议。
A Location Server creates a policy URI for a specific location resource at the time that the location resource is created; that is, a policy URI is created at the same time as the location URI that it controls. The URI of the policy resource MUST be different from the location URI.
位置服务器在创建位置资源时为特定位置资源创建策略URI；也就是说，策略URI与其控制的位置URI同时创建。策略资源的URI必须与位置URI不同。
A policy URI is provided in response to location configuration requests. A policy URI MUST NOT be provided to an entity that is not authorized to view or set policy. This document does not describe how policy might be provided to entities other than for location configuration, for example, in responses to dereferencing requests [RFC6753] or requests from third parties [RFC6155].
提供策略URI以响应位置配置请求。不得向无权查看或设置策略的实体提供策略URI。本文档未描述如何向位置配置以外的实体提供策略，例如，响应解引用请求[RFC6753]或来自第三方的请求[RFC6155]。
Each location URI has either one policy URI or no policy URI. The initial policy that is referenced by a policy URI MUST be identical to the policy that would be applied in the absence of a policy URI. A client that does not support policy URIs can continue to use the location URI as they would have if no policy URI were provided.
每个位置URI要么有一个策略URI，要么没有策略URI。策略URI引用的初始策略必须与在没有策略URI的情况下应用的策略相同。不支持策略URI的客户端可以继续使用位置URI，就像没有提供策略URI时一样。
For HELD, the client assumes that the default policy grants any requester access to location information, as long as the request possesses the location URI. To ensure that the authorization policy is less permissive, a client updates the policy prior to distributing the location URI.
对于HOLD，客户机假设默认策略授予任何请求者对位置信息的访问权，只要请求拥有位置URI。为了确保授权策略的权限较小，客户端在分发位置URI之前更新策略。
A Location Server chooses whether or not to provide a policy URI based on local policy. A HELD-specific extension also allows a requester to specifically ask for a policy URI.
位置服务器根据本地策略选择是否提供策略URI。保留的特定扩展还允许请求者专门请求策略URI。
A policy URI is effectively a shared secret between the Location Server and its clients. Knowledge of a policy URI is all that is required to perform any operations allowed on the policy. Thus, a policy URI should be constructed so that it is hard to predict and confidentiality protected when transmitted (see Section 7). To avoid reusing these shared secrets, the Location Server MUST generate a new policy URI whenever it generates a new location URI set.
策略URI实际上是位置服务器及其客户端之间的共享秘密。策略URI的知识是执行策略上允许的任何操作所需的全部知识。因此，策略URI的构造应确保在传输时很难预测和保护机密性（参见第7节）。为了避免重用这些共享机密，位置服务器必须在生成新的位置URI集时生成新的策略URI。
Client implementors should keep in mind that setting no policy (never performing an HTTP request to a policy URI) is very different from setting an empty policy (performing a PUT with the empty policy). By "the empty policy", we mean a policy containing no rules, which would be represented by the following policy document:
客户机实现人员应该记住，不设置策略（从不对策略URI执行HTTP请求）与设置空策略（使用空策略执行PUT）有很大不同。“空保单”是指不包含任何规则的保单，可通过以下保单文件表示：
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
</ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
</ruleset>
Figure 1: The Empty Policy
图1：空策略
If no policy is set, then the client tacitly accepts whatever policy the server applies to location URIs, including a policy that provides location to anyone that makes a dereference request. If the empty policy is set, then the opposite is true; the client directs the server to never provide access to location. (Since there are no rules to allow access and the policy language is default-deny.)
如果未设置任何策略，则客户端默认接受服务器应用于位置URI的任何策略，包括向发出取消引用请求的任何人提供位置的策略。如果设置了空策略，则相反为真；客户端指示服务器永远不提供对位置的访问。（因为没有允许访问的规则，策略语言为默认拒绝。）
Thus, implementors should consider carefully how to handle the case where the user provides no privacy policy input. On the one hand, an implementation might treat this case as if the user had no privacy preferences and, thus, set no policy. On the other hand, another implementation might decide that if a user provides no positive authorization, then the empty policy should be installed.
因此，实现者应该仔细考虑如何处理用户不提供隐私策略输入的情况。一方面，实现可能会将这种情况视为用户没有隐私偏好，因此不会设置任何策略。另一方面，另一个实现可能会决定，如果用户未提供积极授权，则应安装空策略。
The same reasoning could also be applied to servers, with the caveat that servers do not know whether a given HELD client supports the use of policy URIs. A client that does not understand policy URIs will not be able to set its own policy, so the server must choose a default that is open enough that clients will find it useful. On the other hand, once a client indicates that it understands policy URIs (by including a "requestPolicyUri" element in its HELD request), the
同样的推理也可以应用于服务器，但需要注意的是，服务器不知道给定的保留客户端是否支持使用策略URI。不理解策略URI的客户机将无法设置自己的策略，因此服务器必须选择一个足够开放的默认策略，以便客户机发现它很有用。另一方面，一旦客户机表明它理解策略URI（通过在其保留的请求中包含“requestPolicyUri”元素），则
server may change its default policy to something more restrictive -- even the empty, default-deny policy -- since the client can specify something more permissive if desired.
服务器可能会将其默认策略更改为更严格的策略，甚至是空的默认拒绝策略，因为客户机可以根据需要指定更宽松的策略。
Location configuration protocols can provision hosts with location URIs that refer to the host's location. If the target host is to control policy on these URIs, it needs a way to access the policy that the Location Server uses to guide how it serves location URIs. This section defines extensions to LCPs to carry policy URIs that the target can use to control access to location resources.
位置配置协议可以为主机提供引用主机位置的位置URI。如果目标主机要控制这些URI上的策略，它需要一种访问策略的方法，位置服务器使用该策略来指导它如何为位置URI提供服务。本节定义了LCP的扩展，以承载策略URI，目标可以使用这些URI控制对位置资源的访问。
The HELD protocol [RFC5985] defines a "locationUriSet" element, which contains a set of one or more location URIs that reference the same resource and share a common access control policy. The schema in Figure 2 defines two extension elements for HELD: an empty "requestPolicyUri" element that is added to a location request to indicate that a Device desires that a policy URI be allocated and a "policyUri" element that is included in the location response.
保留协议[RFC5985]定义了一个“LocationURI集”元素，其中包含一组引用相同资源并共享公共访问控制策略的一个或多个位置URI。图2中的模式为HOLD定义了两个扩展元素：一个空的“requestPolicyUri”元素，添加到位置请求中以指示设备希望分配策略URI，另一个“policyUri”元素包含在位置响应中。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="requestPolicyUri">
<xs:complexType name="empty"/>
</xs:element>
<xs:element name="requestPolicyUri">
<xs:complexType name="empty"/>
</xs:element>
<xs:element name="policyUri" type="xs:anyURI"/>
<xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema>
</xs:schema>
Figure 2: XML Schema for the Policy URI Extension
图2：策略URI扩展的XML模式
The URI carried in a "policyUri" element refers to the common access control policy for location URIs in the location response. The URI MUST be a policy URI as described in Section 3. A policy URI MUST use the "http:" or "https:" scheme, and the Location Server MUST support the specified operations on the URI.
“policyUri”元素中包含的URI引用位置响应中位置URI的公共访问控制策略。URI必须是第3节中描述的策略URI。策略URI必须使用“http:”或“https:”方案，并且位置服务器必须支持URI上的指定操作。
A HELD request MAY contain an explicit request for a policy URI. The presence of the "requestPolicyUri" element in a location request indicates that a policy URI is desired.
保留的请求可能包含对策略URI的显式请求。位置请求中存在“requestPolicyUri”元素表示需要策略URI。
It is possible that this document will be updated to allow the use of policy URIs that use protocols other than the HTTP-based protocol described above. To ensure that they fail safely when presented with such a URI, clients implementing this specification MUST verify that a policy URI received from HELD uses either the "http:" or "https:" scheme. If the URI does not match those schemes, then the client MUST discard the URI and behave as if no policy URI was provided.
本文档可能会更新，以允许使用使用上述基于HTTP的协议以外的协议的策略URI。为了确保它们在使用这样的URI时安全地失败，实现此规范的客户端必须验证从HOLD接收的策略URI是否使用“http:”或“https:”方案。如果URI与这些方案不匹配，则客户端必须放弃URI，并表现为没有提供策略URI。
In this section, we provide some brief illustrations of how policy URIs are delivered to target hosts and used by those hosts to manage policy.
在本节中，我们将简要说明策略URI是如何传递到目标主机并由这些主机用于管理策略的。
A HELD request that explicitly requests the creation of a policy URI has the following form:
显式请求创建策略URI的保留请求具有以下形式：
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>
A HELD response providing a single "locationUriSet", containing two URIs under a common policy, would have the following form:
提供单个“LocationURI集”（包含公共策略下的两个URI）的保留响应将具有以下形式：
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>
Consider a client that gets the policy URI <https:// ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the above LCP example. The first thing this allows the client to do is inspect the default policy that the LS has assigned to this URI:
考虑在上面的LCP示例中获得一个客户端的策略URI：http://ls。示例.com：9768 /策略/357Lp6f6PRLBVHL5NK3B>。这允许客户端做的第一件事是检查LS分配给此URI的默认策略：
GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388
HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
<gp:set-retransmission-allowed>
false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations>
</rule>
</ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
<gp:set-retransmission-allowed>
false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations>
</rule>
</ruleset>
This policy allows any requester to obtain location information, as long as they know the location URI. If the user disagrees with this policy, and prefers for example, to only provide location to one friend, at a city level of granularity, then the client can install this policy on the Location Server:
此策略允许任何请求者获取位置信息，只要他们知道位置URI。如果用户不同意此策略，并倾向于（例如）仅向一个朋友提供城市级别粒度的位置，则客户端可以在位置服务器上安装此策略：
PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
Content-type: application/auth-policy+xml
Content-length: 462
PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
Content-type: application/auth-policy+xml
Content-length: 462
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:friend@example.com"/>
</identity>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>city</lp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:friend@example.com"/>
</identity>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>city</lp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
HTTP/1.1 200 OK
HTTP/1.1200ok
Finally, after using the URI for a period, the user wishes to permanently invalidate the URI.
最后，在使用URI一段时间后，用户希望永久地使URI无效。
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
HTTP/1.1200ok
This document requires several IANA registrations, detailed below.
本文件需要几次IANA注册，详情如下。
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:geopriv:hold:policy”。
URI: urn:ietf:params:xml:ns:geopriv:held:policy
URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx).
注册人联系人：IETF、GEOPRIV工作组、(geopriv@ietf.org)，理查德·巴恩斯(rlb@ipv.sx).
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Policy URI Extension</title>
</head>
<body>
<h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7199.txt">
RFC 7199</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Policy URI Extension</title>
</head>
<body>
<h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7199.txt">
RFC 7199</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:schema:geopriv:held:policy
URI: urn:ietf:params:xml:schema:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx)
注册人联系人：IETF、GEOPRIV工作组(geopriv@ietf.org)，理查德·巴恩斯(rlb@ipv.sx)
Schema: The XML for this schema can be found in Section 4.1.
模式：该模式的XML可在第4.1节中找到。
There are two main classes of risks associated with access control policy management: The risk of unauthorized grants or denial of access to the protected resource via manipulation of the policy management process, and the risk of disclosure of policy information itself.
与访问控制策略管理相关的风险主要有两类：通过操纵策略管理过程而未经授权授予或拒绝访问受保护资源的风险，以及策略信息本身的披露风险。
Protecting the policy management process from manipulation entails two primary requirements. First, the policy URI has to be faithfully and confidentially transmitted to the client; second, the policy document has to be faithfully and confidentially transmitted to the Location Server. The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy.
保护策略管理过程不受操纵需要两个主要要求。首先，策略URI必须忠实地、机密地传输给客户端；第二，策略文档必须忠实且保密地传输到位置服务器。该机制还需要确保只有经授权的实体才能获取或修改政策。
Each LCP ensures integrity and confidentiality through different means (see [RFC5985]). These measures ensure that a policy URI is conveyed to the client without modification or interception.
每个LCP通过不同的方式确保完整性和保密性（见[RFC5985]）。这些措施确保策略URI在不进行修改或拦截的情况下传送到客户端。
In general, the requirements for TLS on policy transactions are the same as for the dereference transactions they set policy for [RFC6753]. To protect the integrity and confidentiality of policy data during management, the Location Server SHOULD provide policy URIs with the "https:" scheme and require the use of HTTP over TLS [RFC2818]. The cipher suites required by TLS [RFC5246] provide both integrity protection and confidentiality. If other means of protection are available, an "http:" URI MAY be used, but location servers SHOULD reject PUT and DELETE requests for policy URIs that use the "http:" URI scheme.
通常，TLS对策略事务的要求与它们为[RFC6753]设置策略的取消引用事务的要求相同。为了在管理期间保护策略数据的完整性和机密性，位置服务器应使用“https:”方案提供策略URI，并要求使用HTTP over TLS[RFC2818]。TLS[RFC5246]要求的密码套件提供完整性保护和机密性。如果有其他保护手段可用，则可以使用“http:”URI，但位置服务器应拒绝对使用“http:”URI方案的策略URI的PUT和DELETE请求。
Access control for the policy resource is based on knowledge of its URI. The URI of a policy resource operates under the same constraints as a possession model location URI [RFC5808] and is subject to the same constraints:
策略资源的访问控制基于其URI的知识。策略资源的URI在与占有模型位置URI[RFC5808]相同的约束条件下运行，并受到相同的约束：
o Knowledge of a policy URI MUST be restricted to authorized Rule Makers. Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol and in the requests that are used to inspect, change, or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network thus relying on lower-layer security
o 策略URI的知识必须限于授权的规则制定者。在位置配置协议和用于检查、更改或删除策略资源的请求中传递策略URI时，应使用机密性和完整性保护。请注意，在某些协议（如DHCP）中，这些保护可能是由于将协议的使用限制在本地网络上，从而依赖于较低层的安全性而产生的
mechanisms. When neither application-layer nor network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods.
机制。如果既不提供应用层也不提供网络层安全性，位置服务器必须使用PUT和DELETE方法拒绝请求。
o The Location Server MUST ensure that it is not practical for an attacker to guess a policy URI value, even if the attacker has requested many policy URIs from the Location Server over time. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of 128 bits or more of random entropy is RECOMMENDED to make it infeasible for a third party to guess a policy URI.
o 位置服务器必须确保攻击者猜测策略URI值是不切实际的，即使攻击者在一段时间内从位置服务器请求了许多策略URI。策略URI不能仅从可能是公共的信息派生，包括目标标识或任何位置URI。建议添加128位或更多的随机熵，以使第三方无法猜测策略URI。
o Servers SHOULD apply rate limits in order to make brute-force guessing infeasible. If a server allocates location URIs that include N bits of entropy with a lifetime of T seconds, then the server should limit clients to (2^(N/2))/T queries per second. (The lifetime T of a location URI set is specified by the "expires" attribute in HELD.)
o 服务器应该应用速率限制，以使暴力猜测不可行。如果服务器分配的位置URI包含N位熵，生存期为T秒，则服务器应将客户端限制为每秒（2^（N/2））/T次查询。（位置URI集的生存期T由HOLD中的“expires”属性指定。）
One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is described in Appendix A.
附录a中描述了为位置URI集生成适当的不可预测策略URI的一种可能算法。
The goal of the above recommendation on rate limiting is to bound the probability that an attacker can guess a policy URI during its lifetime. If an attacker is limited to (2^(N/2))/T queries per second, then he will be able to make at most 2^(N/2) guesses over the lifetime of the URI. Assuming these guesses are distinct, the probability of the attacker guessing any given URI is (2^(N/2))/(2^N), so the probability of compromise over the T-second lifetime of the URI is at most 2^(-N/2). (Of course, if the attacker guesses the URI after the policy URI has expired, then there is no risk.) With N=128, the probability of compromise is 5.4e-20 under this rate-limiting scheme. Operators should choose values for N so that the corresponding risk of compromise presents an acceptable level of risk.
上述速率限制建议的目标是限制攻击者在其生存期内猜测策略URI的概率。如果攻击者每秒只能进行（2^（N/2））/T次查询，那么在URI的生命周期内，他最多可以进行2^（N/2）次猜测。假设这些猜测是不同的，攻击者猜测任何给定URI的概率为（2^（N/2））/（2^ N），因此在URI的T秒生存期内的泄露概率最多为2^（-N/2）。（当然，如果攻击者在策略URI过期后猜测URI，则不存在风险。）N=128时，在该速率限制方案下，妥协的概率为5.4e-20。操作员应选择N值，以便相应的危害风险呈现可接受的风险水平。
If M distinct URIs are issued within the same namespace, then the probability of any of the M URIs being compromised is M*2^(N/2). The example algorithm for generating policy URIs (see Appendix A) places them in independent namespaces (i.e., below the corresponding location URIs), so this compounding does not occur.
如果M个不同的uri在同一名称空间中发出，则任何M个uri被破坏的概率为M*2^（N/2）。生成策略URI的示例算法（参见附录A）将它们放置在独立的名称空间中（即，位于相应位置URI的下方），因此不会发生这种复合。
Note that the chosen entropy level will also affect how quickly legitimate clients can query a given URI, especially for very long-lived URIs. If the default lifetime T is greater than 2^(N/2), then clients will have to wait multiple seconds between queries. Operators should choose entropy and lifetime values that result in
请注意，选择的熵级别还将影响合法客户端查询给定URI的速度，特别是对于非常长寿命的URI。如果默认生存期T大于2^（N/2），则客户端在查询之间必须等待多秒。运算符应选择导致
acceptable high maximum query rates and acceptably low probability of compromise. For example, with 32 bits of entropy (much less than recommended above), the one-query-per-second policy URI lifetime is around 18 hours.
可接受的高最大查询率和可接受的低妥协概率。例如，使用32位的熵（远小于上面推荐的值），每秒一个查询的策略URI生存期约为18小时。
A policy URI enables the authorization by access control lists model [RFC5808] for associated location URIs. Under this model, it might be possible to more widely distribute a location URI, relying on the authorization policy to constrain access to location information.
策略URI通过访问控制列表模型[RFC5808]为相关位置URI启用授权。在这个模型下，可能会更广泛地分发位置URI，依赖授权策略来限制对位置信息的访问。
To allow for wider distribution, authorization by access control lists places additional constraints on the construction of location URIs.
为了允许更广泛的分发，访问控制授权列表对位置URI的构造施加了额外的限制。
If multiple Targets share a location URI, an unauthorized location recipient that acquires location URIs for the Targets can determine that the Targets are at the same location by comparing location URIs. With shared policy URIs, Targets are able to see and modify authorization policy for other Targets.
如果多个目标共享一个位置URI，则获取目标位置URI的未经授权位置收件人可以通过比较位置URI来确定目标位于同一位置。使用共享策略URI，目标可以查看和修改其他目标的授权策略。
To allow for the creation of Target-specific authorization policies that are adequately privacy protected, each location URI and policy URI that is issued to a different Target MUST be different from other location URIs and policy URIs. That is, two clients MUST NOT receive the same location URI or the same policy URI.
为了允许创建具有充分隐私保护的特定于目标的授权策略，发布给不同目标的每个位置URI和策略URI必须不同于其他位置URI和策略URI。也就是说，两个客户端不能接收相同的位置URI或相同的策略URI。
In some deployments, it is not always apparent to an LCP server that two clients are different. In particular, where a middlebox [RFC3234] exists, two or more clients might appear as a single client. An example of a deployment scenario of this nature is described in [RFC5687]. An LCP server MUST create a different location URI and policy URI for every request, unless the requests can be reliably identified as being from the same client.
在某些部署中，对于LCP服务器来说，两个客户端不同并不总是显而易见的。特别是，在存在中间盒[RFC3234]的情况下，两个或多个客户端可能会显示为单个客户端。[RFC5687]中描述了此类部署场景的示例。LCP服务器必须为每个请求创建不同的位置URI和策略URI，除非可以可靠地将请求标识为来自同一客户端。
Although servers may choose to implement access controls on policy URIs, by default, any holder of a policy URI is authorized to access and modify the referenced policy document and, thus, to control access to the associated location resources. Because policy URIs function as shared secrets, clients SHOULD protect them as they would passwords. For example, policy URIs SHOULD NOT be transmitted to other hosts or stored in plaintext.
尽管服务器可以选择对策略URI实施访问控制，但默认情况下，策略URI的任何持有者都有权访问和修改引用的策略文档，从而控制对关联位置资源的访问。因为策略URI的功能是共享机密，所以客户端应该像保护密码一样保护它们。例如，策略URI不应传输到其他主机或以明文形式存储。
It should be noted that one of the benefits of the policy URI construct is that in most cases, there is not a policy URI to leave the client device to which it is provided. Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and location URIs must be conveyed to another entity in order to be useful. With policy URIs, location URIs can have more nuanced access controls, and the shared secret used to authenticate the client (i.e., the policy URI) can simply be stored on the client and used to set the access control policy on the location URI. So while policy URIs do use a default model of authorization by possession, they reduce the overall risk to location privacy posed by leakage of shared secret URIs.
应该注意的是，策略URI构造的好处之一是，在大多数情况下，没有策略URI可以离开提供它的客户端设备。如果没有策略URI，位置URI将服从服务器单方面设置的默认策略，并且位置URI必须传递给另一个实体才能发挥作用。使用策略URI，位置URI可以具有更细微的访问控制，用于验证客户端的共享机密（即策略URI）可以简单地存储在客户端上，并用于设置位置URI上的访问控制策略。因此，虽然策略URI使用默认的占有授权模型，但它们降低了共享机密URI泄漏对位置隐私造成的总体风险。
Thanks to Mary Barnes and Alissa Cooper for providing critical commentary and input on the ideas described in this document. Also, thanks to Ted Hardie and Adam Roach for helping clarify the relationships between policy URIs, policy documents, and location resources. Thanks to Stephen Farrell for a helpful discussion on security and privacy challenges.
感谢Mary Barnes和Alissa Cooper对本文档中描述的想法提供了批评性评论和意见。另外，感谢Ted Hardie和Adam Roach帮助澄清策略URI、策略文档和位置资源之间的关系。感谢Stephen Farrell就安全和隐私挑战进行了有益的讨论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4745] 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.
[RFC4745]Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，Polk，J.，和J.Rosenberg，“共同政策：表达隐私偏好的文件格式”，RFC 47452007年2月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009.
[RFC5606]Peterson，J.，Hardie，T.，和J.Morris，“SIP位置传输的‘允许重传’影响”，RFC 5606，2009年8月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687]Tschofenig，H.和H.Schulzrinne，“GEOPRIV第7层位置配置协议：问题陈述和要求”，RFC 5687，2010年3月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808]Marshall，R.，“通过参考机制定位的要求”，RFC 5808，2010年5月。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6155]Winterbottom，J.，Thomson，M.，Tschofenig，H.，和R.Barnes，“在支持HTTP的位置交付中使用设备标识（保留）”，RFC 61552011年3月。
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6225]Polk，J.，Linsner，M.，Thomson，M.，和B.Aboba，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 62252011年7月。
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)", RFC 6753, October 2012.
[RFC6753]Winterbottom，J.，Tschofenig，H.，Schulzrinne，H.，和M.Thomson，“使用支持HTTP的位置传递的位置解引用协议（HOLD）”，RFC 67532012年10月。
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
[RFC6772]Schulzrinne，H.，Tschofenig，H.，Cuellar，J.，Polk，J.，Morris，J.，和M.Thomson，“地理位置政策：表达位置信息隐私偏好的文档格式”，RFC 6772，2013年1月。
One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is as follows:
为位置URI集生成适当的不可预测策略URI的一种可能算法如下：
1. Choose parameters:
1. 选择参数：
* A cryptographic hash function H, e.g., SHA256
* 加密散列函数H，例如SHA256
* A number N of bits of entropy to add, such that N is no more than the length of the output of the hash function
* 要相加的N个熵位，使得N不超过散列函数输出的长度
2. On allocation of a location URI, generate a policy URI in the following way:
2. 在分配位置URI时，按以下方式生成策略URI：
1. Generate a random value NONCE at least N/8 bytes long
1. 生成长度至少为N/8字节的随机值NONCE
2. Compute hash = H( Location-URI-Set || NONCE ) using some cryptographic hash function H and some serialization of the location URI set (e.g., the XML from a HELD response)
2. 使用一些加密哈希函数H和位置URI集的一些序列化（例如，保留响应中的XML）计算hash=H（位置URI集| | NONCE）
3. Form the policy URI by appending the base64url-encoded form of the hash [RFC4648] to one of the location URIs, e.g., as a query parameter: "http://example.com/loc/ foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE"
3. 通过将哈希[RFC4648]的base64url编码形式附加到一个位置URI（例如，作为查询参数）来形成策略URI：http://example.com/loc/ foo？policy=j3WTGUb3smxcZA6eKIqmqdV3ALE“
Authors' Addresses
作者地址
Richard Barnes Mozilla 331 E. Evelyn Ave. Mountain View, CA 94041 US
Richard Barnes Mozilla美国加利福尼亚州山景城伊夫林大道东331号，邮编94041
EMail: rlb@ipv.sx
EMail: rlb@ipv.sx
Martin Thomson Mozilla Suite 300 331 E Evelyn Street Mountain View, CA 94041 US
美国加利福尼亚州伊夫林街东331号马丁·汤姆森·莫兹拉套房，邮编94041
EMail: martin.thomson@gmail.com
EMail: martin.thomson@gmail.com
James Winterbottom Unaffiliated AU
詹姆斯·温特巴顿非附属非盟
EMail: a.james.winterbottom@gmail.com
EMail: a.james.winterbottom@gmail.com
Hannes Tschofenig Hall in Tirol 6060 Austria
奥地利蒂罗尔的汉内斯·茨霍芬尼大厅6060
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at