Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6753 Commscope
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Schulzrinne
Columbia University
M. Thomson
Microsoft
October 2012
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6753 Commscope
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Schulzrinne
Columbia University
M. Thomson
Microsoft
October 2012
A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
使用启用HTTP的位置传递（保留）的位置解引用协议
Abstract
摘要
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target.
本文档描述了如何使用传输层安全性（TLS）上的超文本传输协议（HTTP）作为解引用协议来解析对状态信息数据格式位置对象（PIDF-LO）的引用。本文档假设位置接收者拥有一个URI，该URI可与支持HTTP的位置传递（HOLD）协议结合使用，以请求目标的位置。
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/rfc6753.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6753.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix B. Compliance to Location Reference Requirements . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 21
B.2. Requirements for a Location Dereference Protocol . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix B. Compliance to Location Reference Requirements . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 21
B.2. Requirements for a Location Dereference Protocol . . . . . 23
A location URI [RFC5808] identifies a resource that contains the location of an entity. This document specifies how a holder of an "http:" or "https:" location URI uses that URI to retrieve location information using a subset of HELD functionality or an HTTP GET request.
位置URI[RFC5808]标识包含实体位置的资源。本文档指定了“http:”或“https:”位置URI的持有者如何使用该URI使用保留功能的子集或http GET请求检索位置信息。
A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [DHCP-URI-OPT].
可以使用位置配置协议获取位置URI，例如启用HTTP的位置传递（保持）[RFC5985]或动态主机配置协议（DHCP）位置URI选项[DHCP-URI-OPT]。
A Location Recipient that dereferences a location URI acquires location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow for specifying the type of location information, though some constraints are placed on allowable parameters.
取消引用位置URI的位置接收者以存在信息数据格式-位置对象（PIDF-LO）文档[RFC4119]的形式获取位置信息。保留参数允许指定位置信息的类型，但对允许的参数设置了一些约束。
Location URIs compatible with HELD dereferencing use the "https:" or "http:" scheme. HELD can be used by Location Recipients that are aware of the fact that the URI is a location URI. Mandatory support for an HTTP GET request ensures that the URI can be used even if it is not recognized as a location URI.
与保留解除引用兼容的位置URI使用“https:”或“http:”方案。HOLD可由知道URI是位置URI的位置收件人使用。对HTTP GET请求的强制支持确保即使URI未被识别为位置URI，也可以使用该URI。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses key terminology from several sources:
本文件使用了多个来源的关键术语：
o The terms for the GEOPRIV reference model defined are in [RFC6280].
o [RFC6280]中定义了GEOPRIV参考模型的术语。
o The term "Location Information Server (LIS)", from [RFC5687], is a node in the access network that provides location information to an endpoint. A LIS provides location URIs.
o 术语“位置信息服务器（LIS）”，来自[RFC5687]，是接入网络中向端点提供位置信息的节点。LIS提供位置URI。
o The term "Location Server (LS)", from [RFC6280], is used to identify the role that responds to a location dereference request. A Location Server might be the same entity as the LIS, but the model in [RFC5808] allows for the existence of separate -- but related -- entities.
o [RFC6280]中的术语“位置服务器（LS）”用于标识响应位置取消引用请求的角色。位置服务器可能是与LIS相同的实体，但[RFC5808]中的模型允许存在独立但相关的实体。
o The term "location URI" is coined in [RFC5808].
o 术语“位置URI”是在[RFC5808]中创造的。
This section describes how HELD can be used to dereference a location URI. This process can be applied when a Location Recipient is in possession of a location URI with an "https:" or "http:" URI scheme.
本节描述如何使用HOLD解除对位置URI的引用。当位置收件人拥有具有“https:”或“http:”URI方案的位置URI时，可以应用此过程。
This document does not describe a specific authentication mechanism. This means that authorization policies are unable to specifically identify authorized Location Recipients.
本文档不描述特定的身份验证机制。这意味着授权策略无法专门标识授权位置收件人。
A Location Recipient that wishes to dereference an "https:" or "http:" URI performs a HELD request on HTTP to the identified resource.
希望取消引用“https:”或“http:”URI的位置收件人在http上对标识的资源执行保留请求。
Note: In many cases, an "http:" URI does not provide sufficient security for location URIs. The absence of the security mechanisms provided by TLS means that the Rule Maker has no control over who receives location information, and the Location Recipient has no assurance that the information is correct.
注意：在许多情况下，“http:”URI不能为位置URI提供足够的安全性。TLS提供的安全机制的缺失意味着规则制定者无法控制谁接收位置信息，并且位置接收者无法保证信息是正确的。
The Location Recipient establishes a connection to the LS, as described in [RFC2818].
位置接收者建立与LS的连接，如[RFC2818]所述。
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction. Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference requests, unless confidentiality and integrity protection are provided by some other mechanism. For example, the server might only accept requests from clients within a trusted network or via an IPsec-protected channel. When TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be authenticated [RFC6125] to ensure that the correct server is contacted.
位置URI的方案确定是否在给定的取消引用事务上使用TLS。必须将位置服务器配置为仅发出HTTPS URI并仅响应HTTPS取消引用请求，除非其他机制提供机密性和完整性保护。例如，服务器可能只接受来自受信任网络内或通过受IPsec保护的通道的客户端的请求。使用TLS时，不得使用TLS密码套件TLS_NULL_WITH_NULL_NULL，并且必须对LS进行身份验证[RFC6125]，以确保联系到正确的服务器。
A Location Server MAY reject a request and ask that a Location Recipient provide authentication credentials if authorization is dependent on the Location Recipient identity. Future specifications could define an authentication mechanism and a means by which Location Recipients are identified in authorization policies. This document does not provide definitions for either item.
如果授权依赖于位置收件人身份，则位置服务器可以拒绝请求并要求位置收件人提供身份验证凭据。未来的规范可以定义身份验证机制和在授权策略中标识位置收件人的方法。本文件不提供任何一项的定义。
Use of HELD as a location dereference protocol is largely the same as its use as a location configuration protocol. Aside from the restrictions noted in this document, HELD semantics do not differ from those established in [RFC5985].
HOLD作为位置解引用协议的使用与作为位置配置协议的使用基本相同。除了本文件中指出的限制外，保持语义与[RFC5985]中确定的语义没有区别。
The HELD "locationRequest" is the only request permitted by this specification. Similarly, request parameters other than the following MUST NOT be accepted by the LS: "responseTime" and "locationType" (including the associated "exact" attribute).
保留的“定位请求”是本规范允许的唯一请求。类似地，LS不能接受除以下参数以外的请求参数：“responseTime”和“locationType”（包括相关的“exact”属性）。
Parameters and requests that do not have known behavior for dereference requests MUST NOT be used. The LS MUST ignore any parameters that it does not understand unless it knows the parameters to be invalid. If parameters are understood by the LS and known to be invalid, the LS MAY generate a HELD error response. For instance, those defined in [RFC6155] are always invalid and can be rejected.
对于解引用请求，不能使用没有已知行为的参数和请求。LS必须忽略其不了解的任何参数，除非它知道这些参数无效。如果LS理解参数且已知参数无效，则LS可能会生成保留错误响应。例如，[RFC6155]中定义的内容总是无效的，可以拒绝。
The LS MUST NOT generate location URIs or provide a "locationUriSet" in response to a dereference request. If the location request contains a "locationType" element that includes "locationURI", this parameter is either ignored or rejected as appropriate, based on the associated "exact" attribute.
LS不得生成位置URI或提供“LocationURI集”以响应取消引用请求。如果位置请求包含包含“locationURI”的“locationType”元素，则会根据相关的“exact”属性忽略或拒绝此参数。
GET is the method assumed by generic HTTP user agents; therefore, unless context identifies an "https:" URI as a HELD URI, such a user agent might simply send an HTTP GET. Rather than providing an HTTP 405 (Method Not Allowed) response indicating that POST is the only permitted method, a LIS MUST provide a HELD location response if it receives an HTTP GET request.
GET是通用HTTP用户代理采用的方法；因此，除非上下文将“https:”URI标识为保留URI，否则这样的用户代理可能只发送HTTP GET。如果LIS接收到HTTP GET请求，则必须提供保留位置响应，而不是提供HTTP 405（不允许方法）响应，指示POST是唯一允许的方法。
An HTTP GET request to a HELD URI produces a HELD response as if the following HELD request had been sent using HTTP POST:
对保留URI的HTTP GET请求会生成保留响应，就像使用HTTP POST发送了以下保留请求一样：
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>
Figure 1: GET Request Equivalent Location Request
图1:GET请求等效位置请求
HTTP GET requests MUST be safe and idempotent [RFC2616] -- that is, there are no side effects of making the request, and a repeated request has no more effect than a single request. Repeating a HELD request might result in a different location, but only as a result of a change in the state of the resource: the location of the Target.
HTTP GET请求必须是安全且幂等的[RFC2616]——也就是说，发出请求没有副作用，重复请求的效果不比单个请求大。重复挂起的请求可能会导致不同的位置，但仅是由于资源状态的更改：目标位置。
Only the creation of a location URI as a result of receiving a request causes a HELD request to have side effects. A request to a location URI can be both safe and idempotent, since a location URI cannot be produced in response to a request to a location URI. A
只有作为接收请求的结果而创建位置URI才会导致保留的请求产生副作用。对位置URI的请求既可以是安全的，也可以是幂等的，因为不能生成位置URI来响应对位置URI的请求。A.
Location Recipient MAY infer from a response containing the HELD content type "application/held+xml" that a URI references a resource that supports HELD.
位置接收者可以从包含保留内容类型“application/hold+xml”的响应推断URI引用支持保留的资源。
Content negotiation MAY be supported to produce a presence document in place of a HELD location response. Where the presence document would otherwise be included in a "locationResponse" document, it can be included in the body of the HTTP response directly by including an "Accept" header that includes "application/pidf+xml".
可以支持内容协商以生成存在文档来代替保留的位置响应。如果存在文档将包含在“locationResponse”文档中，则可以通过包含包含“application/pidf+xml”的“Accept”头，将其直接包含在HTTP响应的主体中。
This section discusses two extreme types of authorization models for dereferencing with HELD URIs, namely "Authorization by Possession" and "Authorization by Access Control". In the subsequent subsections, we discuss the properties of these two models. Figure 2, from [RFC5808], shows the model applicable to location configuration, conveyance, and dereference.
本节讨论两种极端类型的授权模型，用于解除对持有URI的引用，即“占有授权”和“访问控制授权”。在随后的小节中，我们将讨论这两个模型的特性。[RFC5808]中的图2显示了适用于位置配置、传输和解引用的模型。
+---------+--------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+--------+ (3) +-----+-----+
| `. |
| Policy `. |
Location | Exchange `. |
Configuration | (*) | |
Protocol | +----+----+ |
(1) | | Rule | Location |
| | Maker | Conveyance |
+-----+----+ +---------+ Protocol |
| | (2) |
| Target +------------------------------+
| |
+----------+
+---------+--------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+--------+ (3) +-----+-----+
| `. |
| Policy `. |
Location | Exchange `. |
Configuration | (*) | |
Protocol | +----+----+ |
(1) | | Rule | Location |
| | Maker | Conveyance |
+-----+----+ +---------+ Protocol |
| | (2) |
| Target +------------------------------+
| |
+----------+
Figure 2: Communication Model
图2：通信模型
It is important to note that this document does not mandate a specific authorization model. It is possible to combine aspects of both models. However, no authentication framework is provided, which limits the policy options available when the "Authorization by Access Control" model is used.
需要注意的是，本文档并不强制要求特定的授权模型。可以将两种模型的各个方面结合起来。但是，没有提供身份验证框架，这限制了使用“访问控制授权”模型时可用的策略选项。
For either authorization model, the overall process is similar. The following steps are followed, with minor alterations:
对于任何一种授权模型，整个过程都是类似的。按照以下步骤进行操作，但有一些小改动：
1. The Target acquires a location URI from the LIS. This uses a location configuration protocol (LCP), such as HELD or DHCP.
1. 目标从LIS获取位置URI。这使用位置配置协议（LCP），如HOLD或DHCP。
2. The Target then conveys the location URI to a third party, the Location Recipient (for example, using SIP as described in [RFC6442]). This step is shown in (2) of Figure 2.
2. 然后，目标将位置URI传递给第三方，即位置接收者（例如，使用[RFC6442]中所述的SIP）。该步骤如图2的（2）所示。
3. The Location Recipient then needs to dereference the location URI in order to obtain the Location Object (3). An "https:" or "http:" URI is dereferenced as described in this document; other URI schemes might be dereferenced using another method.
3. 然后，位置接收者需要取消对位置URI的引用，以获得位置对象（3）。“https:”或“http:”URI被解除引用，如本文档所述；其他URI方案可能使用另一种方法取消引用。
In this final step, the Location Server (LS) or LIS makes an authorization decision. How this decision is reached depends on the authorization model.
在最后一步中，位置服务器（LS）或LIS做出授权决策。如何做出此决定取决于授权模型。
In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI.
在这个模型中，位置URI的拥有权（或知识）用于控制对位置信息的访问。位置URI的构造可以使其难以猜测（参见[RFC5808]的C8），并且可以限制其公开的实体集。LS需要的唯一身份验证是拥有URI的证据。LS可以立即授权指示此URI的任何请求。
Authorization by possession does not require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
占有授权不需要与规则制定者直接互动；假设规则制定者能够控制位置URI的分布。因此，LIS可以在规则制定者有限的策略输入下运行。
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers.
有限披露是该授权模型的一个重要方面。位置URI是一个秘密；因此，确保对手无法获取此信息至关重要。TLS[RFC5246]或S/MIME[RFC5751]可能提供的加密保护信息不被窃听。
Use of authorization by possession location URIs in a hop-by-hop protocol such as SIP [RFC3261] adds the possibility of on-path adversaries. Depending on the usage of the location URI for certain location-based applications (e.g., emergency services and location-based routing), specific treatment is important, as discussed in [RFC6442].
在逐跳协议（如SIP[RFC3261]）中使用占有位置URI授权增加了路径上对手的可能性。根据某些基于位置的应用程序（如紧急服务和基于位置的路由）对位置URI的使用情况，具体处理很重要，如[RFC6442]中所述。
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
使用占有权作为授权的基础意味着，一旦授予，授权就不能轻易撤销。取消位置URI可确保合法用户也受到影响；附加政策的应用在理论上是可行的，但在技术上可能是不可行的。位置URI的过期限制了位置URI的可用时间，要求攻击者继续学习新的位置URI以保留对当前位置信息的访问。
A very simple policy might be established at the time that a location URI is created. This policy specifies that the location URI expires after a certain time, which limits any inadvertent exposure of location information to adversaries. The expiration time of the location URI might be negotiated at the time of its creation, or it might be unilaterally set by the LIS.
在创建位置URI时，可能会建立一个非常简单的策略。此策略指定位置URI在特定时间后过期，这将限制位置信息意外暴露给对手。位置URI的过期时间可以在创建时协商，也可以由LIS单方面设置。
Use of explicit access control provides a Rule Maker greater control over the behavior of an LS. In contrast to authorization by possession, possession of this form of location URI does not imply authorization. Since an explicit policy is used to authorize access to location information, the location URI can be distributed to many potential Location Recipients.
使用显式访问控制可以让规则制定者更好地控制LS的行为。与占有授权不同，占有这种形式的位置URI并不意味着授权。由于显式策略用于授权对位置信息的访问，因此可以将位置URI分发给许多潜在的位置收件人。
Either before creation or dissemination of the location URI, the Rule Maker establishes an authorization policy with the LS. In reference to Figure 2, authorization policies might be established at creation (Step 1) and need to be established before the location URI is published (Step 2) to ensure that the policy grants access to the desired Location Recipients. Depending on the mechanism used, it might also be possible to change authorization policies at any time.
在创建或传播位置URI之前，规则制定者会与LS建立授权策略。参考图2，授权策略可能在创建时建立（步骤1），并且需要在发布位置URI之前建立（步骤2），以确保策略将访问权授予所需的位置收件人。根据使用的机制，还可以随时更改授权策略。
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [GEOPRIV-POLICY]. Additional constraints might be established by other means.
GEOPRIV通用策略[RFC4745]和地理定位策略[GEOPRIV-Policy]提供了这些授权策略的可能格式。可以通过其他方式建立附加约束。
The LS enforces the authorization policy when a Location Recipient dereferences the URI. Explicit authorization policies allow a Rule Maker to specify how location information is provided to Location Recipients.
当位置收件人取消对URI的引用时，LS强制执行授权策略。显式授权策略允许规则制定者指定如何向位置收件人提供位置信息。
This document does not describe a specific authentication mechanism; therefore, the authorization by access control model is not an option. Instead, this document assumes the authorization by possession model.
本文件未描述具体的认证机制；因此，访问控制授权模型不是一个选项。相反，本文档采用占有授权模式。
Other policy mechanisms, such as those described in [GEOPRIV-POLICY], can be applied for different Location Recipients if each recipient is given a different location URI. Each location URI can be assigned a different authorization policy. Selective disclosure used in this fashion can be used in place of identity-based authorization.
如果为每个收件人提供了不同的位置URI，则可以对不同的位置收件人应用其他策略机制，如[GEOPRIV-policy]中所述。可以为每个位置URI分配不同的授权策略。以这种方式使用的选择性公开可以代替基于身份的授权。
How policy is associated with a location URI is not defined by this document. [GEOPRIV-POLICY-URI] describes one possible mechanism.
本文档未定义策略与位置URI的关联方式。[GEOPRIV-POLICY-URI]描述了一种可能的机制。
Use of an identity-based authorization policy is not precluded. A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used. Future specifications might define means of identifying recipients.
不排除使用基于身份的授权策略。位置服务器可以支持能够使用基于身份的授权策略的认证机制。未来的规范可能会定义识别收件人的方法。
Note: Policy frameworks like [RFC4745] degrade in a way that protects privacy if features are not supported. If a policy specifies a rule that is conditional on the identity of a recipient and the protocol does not (or cannot) provide an assertion identity of the recipient, the rule has no effect, and the policy defaults to providing less information.
注意：如果不支持功能，像[RFC4745]这样的策略框架会以保护隐私的方式降级。如果策略指定了以收件人身份为条件的规则，并且协议没有（或不能）提供收件人的断言身份，则该规则无效，并且策略默认提供较少的信息。
An example scenario envisioned by this document is shown in Figure 3.
This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it.
+-------------+
+------------+ | Location | +-----------+
| End Device | | Information | | Location |
| (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
An example scenario envisioned by this document is shown in Figure 3.
This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it.
+-------------+
+------------+ | Location | +-----------+
| End Device | | Information | | Location |
| (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
Figure 3: Example of Dereference Protocol Exchange
图3：解引用协议交换示例
The example in Figure 4 shows the simplest form of dereferencing request using HELD to the location URI "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that this differs from the example in Section 10.1 of [RFC5985] is in the request URI and the source of the URI.
图4中的示例显示了使用“保留到位置URI”解除引用请求的最简单形式https://ls.example.com:49152/uri/w3g61nf5n66p0". 与[RFC5985]第10.1节中的示例不同的唯一方式是请求URI和URI的源。
POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Content-Type: application/held+xml
Content-Length: 87
POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Content-Type: application/held+xml
Content-Length: 87
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 4: Minimal Dereferencing Request
图4：最小解引用请求
Figure 5 shows the response to the previous request listing both civic and geodetic location information of the Target's location. Again, this is identical to the response in Section 10.1 of [RFC5985] -- unless policy specifies otherwise, the Location Recipient receives the same information as the Device.
图5显示了对前面请求的响应，其中列出了目标位置的civic和geodetic位置信息。同样，这与[RFC5985]第10.1节中的响应相同——除非政策另有规定，否则位置接收者接收到的信息与设备相同。
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 676
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 676
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<gbp:retransmission-allowed>
false</gbp:retransmission-allowed>
<gbp:retention-expiry>
2011-01-11T03:42:29+00:00</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<gbp:retransmission-allowed>
false</gbp:retransmission-allowed>
<gbp:retention-expiry>
2011-01-11T03:42:29+00:00</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
Figure 5: Response with Location Information
图5：带有位置信息的响应
The following GET request is treated in an equivalent fashion. The LS treats this request as though it were a location request of the form shown in Figure 1. The same response might be provided.
以下GET请求以等效方式处理。LS将此请求视为图1所示形式的位置请求。可能会提供同样的答复。
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
Figure 6: GET Request
图6:GET请求
The following GET request uses content negotiation to indicate a preference for a presence document.
下面的GET请求使用内容协商来表示对状态文档的偏好。
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
Figure 7: GET Request with Content Negotiation
图7：使用内容协商获取请求
The response only differs from a normal HELD location response to a POST request in that the "locationResponse" element is omitted and the "Content-Type" header reflects the changed content.
该响应与对POST请求的正常保留位置响应的不同之处在于，“locationResponse”元素被省略，“Content Type”标头反映了更改的内容。
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<!-- PIDF contents are identical to the previous example -->
</presence>
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<!-- PIDF contents are identical to the previous example -->
</presence>
Figure 8: GET Response with PIDF-LO
图8：使用PIDF-LO获取响应
Privacy of location information is the most important security consideration for this document. Two measures in particular are used to protect privacy: TLS and authorization policies. TLS provides a means of ensuring confidentiality of location information through encryption and mutual authentication. An authorization policy allows a Rule Maker to explicitly control how location information is provided to Location Recipients.
位置信息的隐私是本文档最重要的安全考虑因素。有两种措施特别用于保护隐私：TLS和授权策略。TLS提供了一种通过加密和相互认证确保位置信息机密性的方法。授权策略允许规则制定者明确控制如何向位置收件人提供位置信息。
The process by which a Rule Maker establishes an authorization policy is not covered by this document; several methods are possible, for instance, [GEOPRIV-POLICY-URI] and [RFC4825].
本文件不包括规则制定者制定授权策略的过程；有几种方法是可能的，例如，[GEOPRIV-POLICY-URI]和[RFC4825]。
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
TLS必须用于解除对位置URI的引用，除非其他机制提供机密性和完整性，如第3节所述。位置收件人必须使用位置URI中包含的域名，使用[RFC2818]第3.1节中描述的程序验证主机身份。本地策略确定在身份验证失败或无法尝试身份验证时位置收件人的操作。
The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
占有授权模型（第4.1节）在传输位置URI时进一步依赖TLS，以保护URI的保密性。拥有这样一个URI意味着与拥有该URI引用的PIDF-LO文档相同的隐私考虑。
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI.
位置URI只能披露给授权的位置收件人。GEOPRIV体系结构[RFC6280]指定规则制定者授权披露URI。
Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
保护位置URI是必要的，因为附加到此类位置URI的策略允许拥有该URI的任何人查看关联的位置信息。位置传输协议规范（如[RFC6442]）更详细地介绍了安全性的这一方面。
According to the requirements in [RFC5808] the LS MUST NOT provide any information about the Target except its location, unless policy from a Rule Maker allows otherwise. Thus, the Location Server MUST only provide an unlinked pseudonym in the "entity" attribute of the PIDF-LO document unless the Rule Maker policy allows for identity disclosure.
根据[RFC5808]中的要求，除非规则制定者的政策允许，否则LS不得提供目标位置以外的任何有关目标的信息。因此，位置服务器必须仅在PIDF-LO文档的“实体”属性中提供未链接的笔名，除非规则制定者策略允许公开身份。
Further security considerations and requirements relating to the use of location URIs are described in [RFC5808].
[RFC5808]中描述了与位置URI使用相关的更多安全注意事项和要求。
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Rohan Mahy for constructive comments on the scope and format of the document. Thanks to Ted Hardie for his strawman proposal that provided assistance with the security section of this document. Richard Barnes made helpful observations on the application of authorization policy. Bernard Aboba and Julian Reschke contributed constructive reviews.
感谢芭芭拉·斯塔克和盖伊·卡伦提供的早期评论。感谢Rohan Mahy对文件的范围和格式提出的建设性意见。感谢Ted Hardie的strawman提案，该提案为本文件的安全部分提供了帮助。Richard Barnes对授权策略的应用进行了有益的观察。伯纳德·阿博巴（Bernard Aboba）和朱利安·雷什克（Julian Reschke）提供了建设性的评论。
The participants of the GEOPRIV interim meeting 2008 provided significant feedback on this document.
2008年GEOPRIV临时会议的与会者就本文件提供了重要反馈。
James Polk provided input on security in June 2008.
詹姆斯·波尔克于2008年6月就安全问题提供了意见。
Martin Dawson was an original author of this document. Sadly, he passed away prior to its publication.
马丁·道森是这份文件的原始作者。不幸的是，他在该书出版之前就去世了。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491]Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年3月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[DHCP-URI-OPT] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, May 2012.
[DHCP-URI-OPT]Polk，J.，“位置统一资源标识符（URI）的动态主机配置协议（DHCP）IPv4和IPv6选项”，正在进行的工作，2012年5月。
[GEOPRIV-POLICY] 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", Work in Progress, August 2012.
[GEOPRIV-POLICY]Schulzrinne，H.，Tschofenig，H.，Cuellar，J.，Polk，J.，Morris，J.，和M.Thomson，“地理位置政策：表达位置信息隐私偏好的文件格式”，正在进行的工作，2012年8月。
[GEOPRIV-POLICY-URI] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", Work in Progress, November 2011.
[GEOPRIV-POLICY-URI]巴恩斯，R.，汤姆森，M.，温特巴顿，J.，和H.Tschofenig，“策略管理的位置配置扩展”，正在进行的工作，2011年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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月。
[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月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[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月。
[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月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[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月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，RFC 6442，2011年12月。
This section describes how use of HELD as a location dereference protocol complies with the GEOPRIV requirements described in [RFC3693].
本节描述了HOLD作为位置解引用协议的使用如何符合[RFC3693]中描述的GEOPRIV要求。
Req. 1. (Location Object generalities):
请求。1.（位置对象概述）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
该要求与PIDF-LO[RFC4119]文件有关，HOLD使用该文件。这些要求由[RFC4119]和[RFC5491]提出。
Req. 2. (Location Object fields):
请求。2.（位置对象字段）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
该要求与PIDF-LO[RFC4119]文件有关，HOLD使用该文件。这些要求由[RFC4119]和[RFC5491]提出。
Req. 3. (Location Data Types):
请求。3.（位置数据类型）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
该要求与PIDF-LO[RFC4119]文件有关，HOLD使用该文件。这些要求由[RFC4119]和[RFC5491]提出。
Section 7.2 of [RFC3693] details the requirements of a "Using Protocol". These requirements are restated, followed by a statement of compliance:
[RFC3693]第7.2节详细说明了“使用协议”的要求。对这些要求进行了重申，随后是合规性声明：
Req. 4. "The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO".
请求。4.“使用协议必须遵守位置对象中编码的隐私和安全说明以及与LO传输和存储相关的相应规则”。
Compliant: This specification describes the use of HTTP over TLS for carrying the PIDF-LO from the LS to the Location Recipient. The sending and receiving parties are expected to comply with the instructions carried inside the object.
兼容：该规范描述了如何使用HTTP over TLS将PIDF-LO从LS传输到位置接收方。发送方和接收方应遵守对象内部的指示。
Though discouraged, using unsecured "http:" URIs is permitted. Using unsecured HTTP is likely to result in non-compliance with this requirement.
尽管不鼓励，但允许使用不安全的“http:”URI。使用不安全的HTTP可能会导致不符合此要求。
Req. 5. "The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol".
请求。5.“使用协议通常将有助于将与凭证相关联的密钥传输到各当事方，即，密钥建立是使用协议的责任”。
Compliant: This document specifies that authentication of the LS uses the established public key infrastructure used by HTTP over TLS [RFC2818]. Authentication of Location Recipients is based on distribution of a secret (the location URI) using a conveyance protocol (for instance, [RFC6442]), allowances are made for later work to define alternative methods.
合规性：本文件规定LS的认证使用HTTP over TLS使用的已建立公钥基础设施[RFC2818]。位置接收者的身份验证基于使用传输协议（例如，[RFC6442]）的秘密（位置URI）的分发，允许以后定义替代方法的工作。
Req. 6. "(Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction".
请求。6.“（单一信息传输）特别是，对于跟踪小型目标设备，设计应允许将位置的单一信息/数据包传输为完整事务”。
Not Compliant: The XML encoding specified in [RFC4119] is not suited to single packet transfers. Use of compressed content encoding [RFC2616] might allow this condition to be met.
不符合：在[RFC4119]中指定的XML编码不适用于单数据包传输。使用压缩内容编码[RFC2616]可能会满足此条件。
Section 7.3 of [RFC3693] details the requirements of a "Rule based Location Data Transfer". These requirements are restated where they are applicable to this document:
[RFC3693]第7.3节详细说明了“基于规则的位置数据传输”的要求。如果这些要求适用于本文件，则对其进行重述：
Req. 7. "(LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules".
请求。7.“（LS规则）位置服务器提供位置接收者访问位置信息的决定必须基于规则制定者定义的隐私规则”。
Compliant: This document describes two alternative methods by which a Rule Maker is able to control access to location information. Rule Maker policy is enforced by the LS when a location URI is dereferenced. However, this document does not describe how a location URI is created or how a Rule Maker associates policy with a location URI. These are covered by other specifications.
合规性：本文档描述了规则制定者控制位置信息访问的两种可选方法。当取消引用位置URI时，LS将强制执行规则制定者策略。但是，本文档不描述如何创建位置URI，也不描述规则制定者如何将策略与位置URI关联。这些都包含在其他规范中。
Req. 8. (LG Rules) Not Applicable: This relationship between LS and the source of its information (be that Location Generator (LG) or LIS) is out of the scope of this document.
请求。8.（LG规则）不适用：LS与其信息来源（即位置生成器（LG）或LIS）之间的关系不在本文件范围内。
Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance
请求。9“（查看者规则）查看者不需要知道规则制定者定义的完整规则（因为查看者不应重新传输位置信息），因此，查看者只应收到查看者按照规则处理LO所需的隐私规则子集
with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained)".
有完整的隐私规则（例如，关于可以保留LO的时间段的说明）”。
Compliant: The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities. For instance, if [RFC4745] is used to convey authorization policies from Rule Maker to LS, this is possible using the parameters specified in [GEOPRIV-POLICY].
符合：规则制定者可以定义（通过本文档范围之外的机制）哪些策略规则被披露给其他实体。例如，如果使用[RFC4745]将授权策略从规则制定者传送到LS，则可以使用[GEOPRIV-POLICY]中指定的参数。
In order to comply with these rules, a Location Recipient MUST NOT redistribute a location URI without express permission. Depending on the access control model, the location URI might be secret (see Section 3.3 of [RFC5808]).
为了遵守这些规则，未经明确许可，位置收件人不得重新分发位置URI。根据访问控制模型，位置URI可能是机密的（参见[RFC5808]第3.3节）。
Req. 10. (Full Rule language) Not Applicable: Note, however, that GEOPRIV has defined a rule language capable of expressing a wide range of privacy rules (see [RFC4745] and [GEOPRIV-POLICY].
请求。10（完整规则语言）不适用：但是，请注意，GEOPRIV定义了一种能够表达广泛隐私规则的规则语言（请参见[RFC4745]和[GEOPRIV-POLICY]。
Req. 11. (Limited Rule language) Not Applicable: This requirement applies to (and is addressed by) PIDF-LO [RFC4119].
请求。11（有限规则语言）不适用：此要求适用于（并由）PIDF-LO[RFC4119]解决。
Section 7.4 of [RFC3693] details the requirements of "Location Object Privacy and Security". These requirements are restated where they are applicable to this document:
[RFC3693]第7.4节详细说明了“位置对象隐私和安全”的要求。如果这些要求适用于本文件，则对其进行重述：
Req. 12. (Identity Protection) Compliant: Identity protection of the Target is provided as long as both of the following conditions are true:
请求。12（身份保护）兼容：只要满足以下两个条件，就可以提供目标的身份保护：
(a) the location URI is not associated with the identity of the Target in any context, and
(a) 位置URI在任何上下文中都与目标的标识不关联，并且
(b) the PIDF-LO does not contain information about the identity of the Target.
(b) PIDF-LO不包含有关目标身份的信息。
For instance, this requirement is complied with if the protocol that conveys the location URI does not link the identity of the Target to the location URI and the LS doesn't include meaningful identification information in the PIDF-LO document. Section 6 recommends that an unlinked pseudonym is used by the LS.
例如，如果传送位置URI的协议没有将目标的标识链接到位置URI，并且LS在PIDF-LO文档中没有包含有意义的标识信息，则符合此要求。第6节建议LS使用未链接的笔名。
Req. 13. (Credential Requirements) Compliant: The primary security mechanism specified in this document is Transport Layer Security. TLS offers the ability to use different types of credentials, including symmetric, asymmetric, or a combination of them.
请求。13（凭据要求）兼容：本文档中指定的主要安全机制是传输层安全。TLS提供了使用不同类型凭据的能力，包括对称、非对称或它们的组合。
Req. 14. (Security Features) Compliant: GEOPRIV defines a few security requirements for the protection of Location Objects such as mutual endpoint authentication, data object integrity, data object confidentiality, and replay protection. The ability to use Transport Layer Security fulfills most of these requirements. Authentication of Location Recipients in this document relies on proof of a shared secret -- the location URI. This does not preclude the addition of more robust authentication procedures.
请求。14（安全功能）兼容：GEOPRIV定义了一些保护位置对象的安全要求，如相互端点身份验证、数据对象完整性、数据对象机密性和重播保护。使用传输层安全性的能力满足了大多数这些要求。此文档中位置收件人的身份验证依赖于共享秘密的证明——位置URI。这并不排除添加更健壮的身份验证过程。
Req. 15. (Minimal Crypto) Compliant: The mandatory-to-implement ciphersuite is provided in the TLS layer security specification [RFC5246].
请求。15（最小加密）兼容：TLS层安全规范[RFC5246]中提供了实现密码套件的强制要求。
This section describes how HELD complies to the location reference requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the Location Configuration Protocol is included.
本节描述了HOLD如何符合[RFC5808]中规定的位置参考要求。包括[RFC5985]对位置配置协议的符合性。
Note: Use of HELD as a location dereference protocol does not necessarily imply that HELD is the corresponding LCP. This document is still applicable to HTTP location URIs that are acquired by other means.
注：使用HOLD作为位置解引用协议并不一定意味着HOLD是相应的LCP。本文档仍然适用于通过其他方式获取的HTTP位置URI。
C1. "Location URI support: The location configuration protocol MUST support a location reference in URI form".
C1。“位置URI支持：位置配置协议必须支持URI形式的位置引用”。
Compliant: HELD only provides location references in URI form.
Compliant:Hold仅以URI形式提供位置引用。
C2. "Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated".
C2。“位置URI过期：当位置URI的有效期间隔有限时，必须指示其生存期”。
Compliant: HELD indicates the expiry time of location URIs using the "expires" attribute. [GEOPRIV-POLICY-URI] provides a way to control expiration of a location URI.
Compliant:Hold表示使用“expires”属性的位置URI的过期时间。[GEOPRIV-POLICY-URI]提供了一种控制位置URI过期的方法。
C3. "Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI".
C3。“位置URI取消：位置配置协议必须支持请求取消特定位置URI的功能”。
Compliant with Extension: [GEOPRIV-POLICY-URI] describes how a location URI can be canceled through the application of policy. Without extensions, HELD does not provide a method for canceling location URIs.
符合扩展：[GEOPRIV-POLICY-URI]描述了如何通过应用策略取消位置URI。如果没有扩展，HOLD不提供取消位置URI的方法。
C4. "Location Information Masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location information specific components".
补体第四成份。“位置信息屏蔽：默认情况下，位置URI必须通过随机化和唯一性确保位置URI不包含特定于位置信息的组件”。
Compliant: The HELD specification [RFC5985] explicitly references this requirement in providing guidance on the format of the location URI.
符合：保留规范[RFC5985]在提供位置URI格式指南时明确引用了此要求。
C5. "Target Identity Protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device)".
C5。“目标身份保护：位置URI不得包含标识目标的信息（例如，用户或设备）”。
Compliant: The HELD specification [RFC5985] provides specific guidance on the anonymity of the Target with regards to the generation of location URIs. Section 6 expands on this guidance.
符合：保留的规范[RFC5985]提供了有关生成位置URI的目标匿名性的具体指导。第6节详述了本指南。
C6. "Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only, or multiple times".
C6。“重用指示符：应该有一种方法允许目标控制位置URI是只能解析一次，还是可以解析多次”。
Not Compliant: Specific extensions to the protocol or authorization policy formats are needed to alter the default behavior, which allows unlimited resolution of the location URI.
不兼容：需要协议或授权策略格式的特定扩展来更改默认行为，这允许无限解析位置URI。
C7. "Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target".
C7。“选择性披露：位置配置协议必须提供一种机制，允许规则制定者控制披露的目标信息”。
Compliant with Extension: Use of policy mechanisms and [GEOPRIV-POLICY-URI] enable this capability. Note that this document recommends that only location information be provided.
与扩展兼容：使用策略机制和[GEOPRIV-policy-URI]启用此功能。请注意，本文件建议仅提供位置信息。
C8. "Location URI Not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128-bits of randomness is RECOMMENDED".
C8。“位置URI不可猜测：默认情况下，位置配置协议必须返回在指定生命周期内随机且唯一的位置URI。建议使用具有128位随机性的位置URI”。
Compliant: HELD specifies that location URIs conform to this requirement. The amount of randomness is not specifically identified since it depends on a number of factors that change over time, such as the number of valid location URIs, the validity period of those URIs, and the rate that guesses can be made.
Compliant:Hold指定位置URI符合此要求。由于随机性的数量取决于随时间变化的许多因素，例如有效位置URI的数量、这些URI的有效期以及可以猜测的比率，因此没有具体确定随机性的数量。
C9. "Location URI Options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server, (e.g., embedded location information within the location URI)".
C9。“位置URI选项：在用户提供的授权策略的情况下，如果不保证匿名或不可猜测的位置URI，则位置配置协议可能支持目标向位置配置服务器请求的各种可选位置URI约定，（例如，位置URI中嵌入的位置信息）”。
Not Compliant: HELD does not support Device-specified location URI forms.
不兼容：HOLD不支持设备指定的位置URI表单。
D1. "Location URI support: The location dereference protocol MUST support a location reference in URI form".
D1。“位置URI支持：位置解除引用协议必须支持URI形式的位置引用”。
Compliant: HELD only provides location references in URI form.
Compliant:Hold仅以URI形式提供位置引用。
D2. "Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server".
D2。“身份验证：位置解除引用协议必须包括对客户端和服务器进行身份验证的机制”。
Partially Compliant: TLS provides means for mutual authentication. This document only specifies the required mechanism for server authentication. Client authentication is not precluded.
部分兼容：TLS提供了相互认证的方法。本文档仅指定服务器身份验证所需的机制。不排除客户端身份验证。
D3. "Dereferenced Location Form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document".
D3。“解引用位置表单：解引用协议返回的值必须包含格式良好的PIDF-LO文档”。
Compliant: HELD requires that Location Objects are in the form of a PIDF-LO that complies with [RFC5491].
符合：保持要求位置对象采用符合[RFC5491]的PIDF-LO形式。
D4. "Location URI Repeated Use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration".
D4。“位置URI重复使用：位置解除引用协议必须支持根据解除引用服务器配置多次解析同一位置URI的功能”。
Compliant: A Location Recipient may access and use a location URI as many times as desired until URI expiration results in the URI being invalidated. Authorization policies might include rules that modify this behavior.
兼容：位置收件人可以根据需要多次访问和使用位置URI，直到URI过期导致URI无效为止。授权策略可能包括修改此行为的规则。
D5. "The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server".
D5。“位置解除引用协议必须支持位置收件人和位置服务器之间发送的消息的机密性保护”。
Compliant: This document strongly recommends the use of TLS for confidentiality, and HELD mandates its implementation. Unsecured HTTP is permitted: the associated risks are described in Section 3.
合规性：本文件强烈建议使用TLS进行保密，并要求其实施。允许使用不安全的HTTP：第3节描述了相关风险。
Authors' Addresses
作者地址
James Winterbottom Commscope Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
James Winterbottom康普安德鲁大厦（39）新南威尔士州卧龙岗大学校园北田大道2522号
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304 USA
美国加利福尼亚州帕洛阿尔托波特大道3210号马丁·汤姆森微软公司，邮编94304
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net