Internet Engineering Task Force (IETF) M. Barnes, Ed.
Request for Comments: 5985 Polycom
Category: Standards Track September 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Barnes, Ed.
Request for Comments: 5985 Polycom
Category: Standards Track September 2010
ISSN: 2070-1721
HTTP-Enabled Location Delivery (HELD)
启用HTTP的位置传递（保留）
Abstract
摘要
This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer.
本文档定义了第7层位置配置协议（L7 LCP），并描述了HTTP和HTTP/TLS作为L7 LCP传输的使用。L7 LCP用于从接入网络内的服务器检索位置信息。它包括两种形式的位置信息检索选项：按值和按引用。该协议是独立于会话层的可扩展应用层协议。
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/rfc5985.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5985.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 6
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 6
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 7
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 15
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring That the Proper LIS Has Been Contacted . . . . . 23
9.2. Protecting Responses from Modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Examples of HTTPS Messages . . . . . . . . . . . . . . . . 25
10.2. Example of a Simple Location Request . . . . . . . . . . . 26
10.3. An Example of a Location Request for Multiple Location
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 6
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 6
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 7
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 15
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring That the Proper LIS Has Been Contacted . . . . . 23
9.2. Protecting Responses from Modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Examples of HTTPS Messages . . . . . . . . . . . . . . . . 25
10.2. Example of a Simple Location Request . . . . . . . . . . . 26
10.3. An Example of a Location Request for Multiple Location
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. HELD Compliance to IETF LCP Requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
Appendix A. HELD Compliance to IETF LCP Requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
The location of a Device is information that is useful for a number of applications. The L7 Location Configuration Protocol (LCP) problem statement and requirements document [RFC5687] provides some scenarios in which a Device might rely on its access network to provide location information. The Location Information Server (LIS) service applies to access networks employing both wired technology (e.g., DSL, cable) and wireless technology (e.g., WiMAX) with varying degrees of Device mobility. This document describes a protocol that can be used to acquire Location Information (LI) from a LIS within an access network.
设备的位置是对许多应用有用的信息。L7位置配置协议（LCP）问题声明和要求文档[RFC5687]提供了一些场景，其中设备可能依赖其接入网络提供位置信息。位置信息服务器（LIS）服务适用于采用有线技术（例如DSL、电缆）和无线技术（例如WiMAX）的接入网络，具有不同程度的设备移动性。本文档描述了一种可用于从接入网络内的LIS获取位置信息（LI）的协议。
This specification identifies two types of location information that may be retrieved from the LIS. Location may be retrieved from the LIS by value; that is, the Device may acquire a literal location object describing the location of the Device. The Device may also request that the LIS provide a location reference in the form of a Location URI or set of Location URIs, allowing the Device to distribute its LI by reference. Both of these methods can be provided concurrently from the same LIS to accommodate application requirements for different types of location information.
本规范确定了可从LIS检索的两种类型的位置信息。可通过值从LIS检索位置；也就是说，设备可以获取描述设备位置的文字位置对象。设备还可以请求LIS以位置URI或一组位置URI的形式提供位置引用，从而允许设备通过引用分发其LI。这两种方法可以从同一个LIS中同时提供，以适应不同类型位置信息的应用程序需求。
This specification defines an extensible XML-based protocol that enables the retrieval of LI from a LIS by a Device. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport. This document describes the use of HTTP and HTTP/TLS as transports for the protocol.
本规范定义了一个可扩展的基于XML的协议，该协议允许设备从LIS检索LI。该协议可以绑定到任何会话层协议，特别是那些能够进行MIME传输的协议。本文档描述了HTTP和HTTP/TLS作为协议传输的使用。
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 the terms (and their acronym forms): Access Provider (AP), Location Information (LI), Location Object (LO), Device, Target, Location Generator (LG), Location Recipient (LR), and Rule Maker (RM) and Rule Holder (RH) as defined in GEOPRIV Requirements [RFC3693]. The terms Location Information Server (LIS), Access Network, Access Provider (AP), and Access Network Provider are used in the same context as defined in the L7 LCP Problem statement and Requirements document [RFC5687]. The usage of the terms Civic Location/Address and Geodetic Location follows the usage in many of the referenced documents.
本文件使用的术语（及其首字母缩写形式）：访问提供者（AP）、位置信息（LI）、位置对象（LO）、设备、目标、位置生成器（LG）、位置接收者（LR）以及规则制定者（RM）和规则持有人（RH），如GEOPRIV要求[RFC3693]中所定义。术语位置信息服务器（LIS）、接入网络、接入提供商（AP）和接入网络提供商在L7 LCP问题声明和需求文件[RFC5687]中定义的相同上下文中使用。城市位置/地址和大地测量位置这两个术语的用法与许多参考文件中的用法相同。
In describing the protocol, the terms "attribute" and "element" are used according to their context in XML. The term "parameter" is used in a more general protocol context and can refer to either an XML "attribute" or "element".
在描述协议时，术语“属性”和“元素”是根据它们在XML中的上下文使用的。术语“参数”用于更一般的协议上下文，可以指XML“属性”或“元素”。
This document describes an interface between a Device and a Location Information Server (LIS). This document assumes that the LIS is present within the same administrative domain as the Device (e.g., the access network). The LIS exists because not all Devices are capable of determining LI, and because, even if a Device is able to determine its own LI, it may be more efficient with assistance. This document does not specify how LI is determined. An Access Provider (AP) operates the LIS so that Devices (and Targets) can retrieve their LI. This document assumes that the Device and Access Provider have no prior relationship other than what is necessary for the Device to obtain network access.
本文档描述了设备和位置信息服务器（LIS）之间的接口。本文档假设LIS与设备位于同一管理域内（例如，接入网络）。LIS的存在是因为并非所有设备都能够确定LI，并且因为即使设备能够确定其自己的LI，在帮助下也可能更有效。本文件未规定如何确定LI。接入提供商（AP）操作LIS，以便设备（和目标）能够检索其LI。本文档假设设备和访问提供商之间没有任何优先关系，只有设备获得网络访问所必需的关系。
This document is based on the attribution of the LI to a Device and not specifically a person (end user) or Target, based on the premise that location determination technologies are generally designed to locate a Device and not a person. It is expected that, for most applications, LI for the Device can be used as an adequate substitute for the end user's LI. Since revealing the location of the Device almost invariably reveals some information about the location of the user of the Device, the same level of privacy protection demanded by a user is required for the Device. This approach may require either some additional assurances about the link between Device and target, or an acceptance of the limitation that unless the Device requires active user authentication, there is no guarantee that any particular individual is using the Device at that instant.
本文件基于LI归属于设备，而非特定的个人（最终用户）或目标，前提是位置确定技术通常设计用于定位设备而非个人。预计在大多数应用中，设备的LI可作为终端用户LI的适当替代品。由于揭示设备的位置几乎总是揭示关于设备的用户的位置的一些信息，因此对设备要求用户要求的相同级别的隐私保护。该方法可能需要关于设备和目标之间的链接的一些额外保证，或者接受限制，即除非设备需要主动用户认证，否则不能保证任何特定个人在该时刻使用该设备。
The following diagram shows the logical configuration of some of the functional elements identified in [RFC3693] and the LIS defined in [RFC5687]. It also shows where this protocol applies, with the Rule
下图显示了[RFC3693]中确定的一些功能元件和[RFC5687]中定义的LIS的逻辑配置。它还显示了该协议适用的位置以及规则
Maker and Target represented by the role of the Device. Note that only the interfaces relevant to the Device are identified in the diagram.
由设备角色表示的制造商和目标。请注意，图中仅标识了与设备相关的接口。
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|-------------------------------+ |
+----------|----------------------------------+
|
|
HELD
|
Rule Maker - - _ +-----------+ +-----------+
o - - | Device | | Location |
<U\ | | - - - - | Recipient |
/ \ _ - - | | APP | |
Target - - +-----------+ +-----------+
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|-------------------------------+ |
+----------|----------------------------------+
|
|
HELD
|
Rule Maker - - _ +-----------+ +-----------+
o - - | Device | | Location |
<U\ | | - - - - | Recipient |
/ \ _ - - | | APP | |
Target - - +-----------+ +-----------+
Figure 1: Significant Roles
图1：重要角色
The interface between the Location Recipient (LR) and the Device and/or LIS is application specific, as indicated by the APP annotation in the diagram and it is outside the scope of the document. An example of an APP interface between a Device and LR can be found in the SIP Location Conveyance document [LOC-CONVEY].
如图中的应用程序注释所示，位置接收者（LR）与设备和/或LIS之间的接口是特定于应用程序的，不在本文档的范围内。设备和LR之间的应用程序接口示例可在SIP位置传输文档[LOC-TRANSFER]中找到。
A Device uses the HTTP-Enabled Location Delivery (HELD) protocol to retrieve its location either directly in the form of a Presence Information Data Format Location Object (PIDF-LO) document (by value) or indirectly as a Location URI (by reference). The security necessary to ensure the accuracy, privacy, and confidentiality of the Device's location is described in the Security Considerations (Section 9).
设备使用支持HTTP的位置传递（HOLD）协议直接以状态信息数据格式位置对象（PIDF-LO）文档的形式（通过值）或间接地作为位置URI（通过引用）检索其位置。安全注意事项（第9节）中描述了确保设备位置的准确性、隐私性和机密性所需的安全性。
As described in the L7 LCP problem statement and requirements document [RFC5687], the Device MUST first discover the URI for the LIS for sending the HELD protocol requests. The URI for the LIS SHOULD be obtained from an authorized and authenticated entity. The details for ensuring that an appropriate LIS is contacted are
如L7 LCP问题声明和要求文档[RFC5687]中所述，设备必须首先发现LIS的URI，以便发送保留的协议请求。LIS的URI应从经授权和验证的实体处获取。确保联系适当LIS的详细信息如下：
provided in Section 9 and in particular Section 9.1. The LIS discovery protocol details are out of scope of this document and are specified in [RFC5986]. The type of URI provided by LIS discovery is RECOMMENDED to be an HTTPS URI.
第9节，特别是第9.1节规定。LIS发现协议的详细信息不在本文档的范围内，请参见[RFC5986]。建议LIS发现提供的URI类型为HTTPS URI。
The LIS requires an identifier for the Device in order to determine the appropriate location to include in the location response message. In this document, the IP address of the Device, as reflected by the source IP address in the location request message, is used as the identifier. Other identifiers are possible, but are beyond the scope of this document.
LIS需要设备的标识符，以确定要包含在位置响应消息中的适当位置。在本文档中，设备的IP地址（由位置请求消息中的源IP地址反映）用作标识符。其他标识符是可能的，但超出了本文档的范围。
Use of the HELD protocol is subject to the viability of the identifier used by the LIS to determine location. This document describes the use of the source IP address sent from the Device as the identifier used by the LIS. When Network Address Translation (NAT), a Virtual Private Network (VPN), or other forms of address modification occur between the Device and the LIS, the location returned could be inaccurate.
保留协议的使用取决于LIS用于确定位置的标识符的可行性。本文档介绍如何使用从设备发送的源IP地址作为LIS使用的标识符。当设备和LIS之间发生网络地址转换（NAT）、虚拟专用网络（VPN）或其他形式的地址修改时，返回的位置可能不准确。
Not all cases of NATs introduce inaccuracies in the returned location. For example, a NAT used in a residential Local Area Network (LAN) is typically not a problem. The external IP address used on the Wide Area Network (WAN) side of the NAT is an acceptable identifier for all of the Devices in the residence (on the LAN side of the NAT), since the covered geographical area is small.
并非所有NAT都会在返回的位置引入不精确性。例如，住宅局域网（LAN）中使用的NAT通常不是问题。NAT的广域网（WAN）侧使用的外部IP地址是住宅（NAT的LAN侧）中所有设备的可接受标识符，因为覆盖的地理区域很小。
On the other hand, if there is a VPN between the Device and the LIS (for example, for a teleworker), then the IP address seen by a LIS inside the enterprise network might not be the right address to identify the location of the Device. Section 4.1.2 provides recommendations to address this issue.
另一方面，如果设备和LIS之间存在VPN（例如，对于远程工作者），则LIS在企业网络内看到的IP地址可能不是识别设备位置的正确地址。第4.1.2节提供了解决该问题的建议。
To minimize the impact of connections or tunnels setup for security purposes or for traversing middleboxes, Devices that connect to servers such as VPN servers, SOCKS servers, and HTTP proxy servers should perform their HELD query on the LIS prior to establishing a connection to other servers. It is RECOMMENDED that discovery [RFC5986] and an initial query be performed before establishing any connections to other servers. If a Device performs the HELD query after establishing a connection to another server, the Device may receive inaccurate location information.
为了最大限度地减少出于安全目的或为了穿越中间盒而设置的连接或隧道的影响，连接到服务器（如VPN服务器、SOCKS服务器和HTTP代理服务器）的设备应在建立到其他服务器的连接之前在LIS上执行其保留查询。建议在建立与其他服务器的任何连接之前执行发现[RFC5986]和初始查询。如果设备在与另一台服务器建立连接后执行保留查询，则该设备可能会收到不准确的位置信息。
Devices that establish VPN connections for use by other Devices inside a LAN or other closed network could serve as a LIS, that implements the HELD protocol, for those other Devices. Devices within the closed network are not necessarily able to detect the presence of the VPN. In this case, a VPN Device should provide the address of the LIS server it provides, in response to discovery queries, rather than passing such queries through the VPN tunnel. Otherwise, the other Devices would be totally unaware that they could receive inaccurate location information.
建立VPN连接以供LAN或其他封闭网络内的其他设备使用的设备可以用作实现这些其他设备的保留协议的LIS。封闭网络中的设备不一定能够检测到VPN的存在。在这种情况下，VPN设备应提供其提供的LIS服务器的地址，以响应发现查询，而不是通过VPN隧道传递此类查询。否则，其他设备将完全不知道它们可能接收到不准确的位置信息。
It could also be useful for a VPN Device to serve as a LIS for other location configuration options such as Dynamic Host Configuration Protocol (DHCP) [RFC3825] or Link Layer Discovery Protocol - Media Endpoint Discovery [LLDP-MED]. For this case, the VPN Device that serves as a LIS may first acquire its own location using HELD.
VPN设备用作其他位置配置选项的LIS也很有用，例如动态主机配置协议（DHCP）[RFC3825]或链路层发现协议-媒体端点发现[LLDP-MED]。对于这种情况，用作LIS的VPN设备可以首先使用HOLD获取其自己的位置。
In the cases where the Device connects to the LIS through a VPN or a NAT that serves a large geographic area or multiple geographic locations (for example, a NAT used by an enterprise to connect their private network to the Internet), the LIS might not be able to return accurate LI. If the LIS cannot determine LI for the Device, it should provide an error response to the requesting Device. The LIS needs to be configured to recognize identifiers that represent these conditions.
在设备通过VPN或NAT连接到LIS的情况下，LIS可能无法返回准确的LI，该VPN或NAT服务于大地理区域或多个地理位置（例如，企业用于将其专用网络连接到Internet的NAT）。如果LIS无法确定设备的LI，则应向请求设备提供错误响应。LIS需要配置为识别表示这些条件的标识符。
LIS operators have a large role in ensuring the best possible environment for location determination. The LIS operator needs to ensure that the LIS is properly configured with identifiers that indicate Devices on the remote side of a NAT or VPN. In order to serve the Devices on the remote side of a NAT or VPN, a LIS needs to have a presence on the side of the NAT or VPN nearest the Device.
LIS操作员在确保位置确定的最佳环境方面发挥着重要作用。LIS操作员需要确保LIS正确配置了标识符，这些标识符指示NAT或VPN远程侧的设备。为了服务于NAT或VPN远程侧的设备，LIS需要在距离设备最近的NAT或VPN侧存在。
Where a Device requires LI directly, it can request that the LIS create a PIDF-LO document. This approach fits well with a configuration whereby the Device directly makes use of the provided PIDF-LO document. The details on the information that may be included in the PIDF-LO MUST follow the subset of those rules relating to the construction of the "location-info" element in the PIDF-LO Usage Clarification, Considerations, and Recommendations document [RFC5491]. Further detail is included in "Protocol Parameters" (Section 6).
如果设备直接需要LI，它可以请求LIS创建PIDF-LO文档。这种方法非常适合设备直接使用提供的PIDF-LO文档的配置。PIDF-LO中可能包含的信息详情必须遵循PIDF-LO使用说明、注意事项和建议文件[RFC5491]中与“位置信息”元素构造相关的规则子集。更多详情见“协议参数”（第6节）。
Requesting location directly does not always address the requirements of an application. A Device can request a Location URI instead of literal location. A Location URI is a URI [RFC3986] of any scheme, which a Location Recipient (LR) can use to retrieve LI. A Location URI provided by a LIS can be assumed to be globally addressable; that is, anyone in possession of the URI can access the LIS.
直接请求位置并不总是满足应用程序的要求。设备可以请求位置URI而不是文字位置。位置URI是任何方案的URI[RFC3986]，位置接收者（LR）可以使用它来检索LI。可以假设LIS提供的位置URI是全局可寻址的；也就是说，任何拥有URI的人都可以访问LIS。
However, possession of the URI does not in any way suggest that the LIS indiscriminately reveals the location associated with the Location URI. The specific requirements associated with the dereference of the location are specified in [RFC5808]. The location dereference protocol details are out of scope of this document. As such, many of the requirements in [RFC5808] (e.g., canceling of location references) are not intended to be supported by this specification. It is anticipated that future specifications may address these requirements.
然而，拥有URI并不意味着LIS不加区别地显示与位置URI关联的位置。[RFC5808]中规定了与位置取消参考相关的具体要求。位置解除引用协议的详细信息超出了本文档的范围。因此，本规范不支持[RFC5808]中的许多要求（例如，取消位置参考）。预计未来的规范可能会满足这些要求。
As discussed in Section 4, the HELD protocol provides for the retrieval of the Device's location in the form of a PIDF-LO document and/or Location URI(s) from a LIS. Three messages are defined to support the location retrieval: locationRequest, locationResponse, and error.
如第4节所述，HOLD协议规定以PIDF-LO文档和/或位置URI的形式从LIS检索设备的位置。定义了三条消息来支持位置检索：locationRequest、locationResponse和error。
The Location Request (locationRequest) message is described in Section 5.1. A Location Request message from a Device indicates whether location should be returned in the form of a PIDF-LO document (with specific type(s) of location) and/or Location URI(s). In case of success, the LIS replies with a locationResponse message, including a PIDF-LO document and/or one or more Location URIs. In the case of an error, the LIS replies with an error message.
第5.1节描述了位置请求（locationRequest）消息。来自设备的位置请求消息指示是否应以PIDF-LO文档（具有特定类型的位置）和/或位置URI的形式返回位置。如果成功，LIS将使用locationResponse消息进行回复，包括PIDF-LO文档和/或一个或多个位置URI。如果出现错误，LIS会回复错误消息。
The HELD protocol messages are defined as XML documents that MUST be encoded in UTF-8. A MIME type "application/held+xml" is registered in Section 11.3 to distinguish HELD messages from other XML document bodies. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. The 'charset' parameter MUST be included with the XML document.
保留的协议消息定义为必须用UTF-8编码的XML文档。在第11.3节中注册了MIME类型“application/hold+xml”，以区分持有的消息与其他xml文档体。本规范遵循[RFC3023]中描述的建议和约定，包括类型（“+xml”后缀）的命名约定和“charset”参数的使用。XML文档中必须包含“charset”参数。
Section 6 contains a more thorough description of the protocol parameters, valid values, and how each should be handled. Section 7 contains a more specific definition of the structure of these messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
第6节更全面地描述了协议参数、有效值以及应如何处理每个参数。第7节以XML模式的形式对这些消息的结构进行了更具体的定义[W3C.REC-xmlschema-1-20041028]。
Section 8 describes the use of a combination of HTTP [RFC2616], TLS [RFC5246], and TCP [RFC0793] for transporting the HELD messages.
第8节描述了使用HTTP[RFC2616]、TLS[RFC5246]和TCP[RFC0793]的组合来传输保留的消息。
A location request message is sent from the Device to the LIS when the Device requires its own LI. The type of LI that a Device requests is determined by the type of LI that is included in the "locationType" element.
当设备需要自己的LI时，会从设备向LIS发送位置请求消息。设备请求的LI类型由“locationType”元素中包含的LI类型确定。
The location request is made by sending a document formed of a "locationRequest" element. The LIS uses the source IP address of the location request message as the primary source of identity for the requesting Device or target. It is anticipated that other Device identities may be provided through schema extensions.
通过发送由“locationRequest”元素组成的文档来发出位置请求。LIS使用位置请求消息的源IP地址作为请求设备或目标的主要标识源。预计可通过模式扩展提供其他设备标识。
The LIS MUST ignore any part of a location request message that it does not understand, except the document element. If the document element of a request is not supported, the LIS MUST return an error with the unsupportedMessage error code.
LIS必须忽略其不理解的位置请求消息的任何部分，文档元素除外。如果请求的文档元素不受支持，LIS必须返回一个带有unsupportedMessage错误代码的错误。
A successful response to a location request MUST contain a PIDF-LO and/or Location URI(s). The response SHOULD contain location information of the requested "locationType". The cases whereby a different type of location information MAY be returned are described in Section 6.2.
对位置请求的成功响应必须包含PIDF-LO和/或位置URI。响应应包含请求的“locationType”的位置信息。第6.2节描述了返回不同类型位置信息的情况。
If the LIS is unable to provide location information based on the received locationRequest message, it MUST return an error message. The LIS may return an error message in response to requests for any "locationType".
如果LIS无法根据收到的locationRequest消息提供位置信息，则必须返回错误消息。LIS可能会返回错误消息以响应任何“locationType”请求。
An error indication document consists of an "error" element. The "error" element MUST include a "code" attribute that indicates the type of error. A set of predefined error codes are included in Section 6.3.
错误指示文档由“错误”元素组成。“error”元素必须包含指示错误类型的“code”属性。第6.3节包含一组预定义的错误代码。
Error responses MAY also include a "message" attribute that can include additional information. This information SHOULD be for diagnostic purposes only and MAY be in any language. The language of the message SHOULD be indicated with an "xml:lang" attribute.
错误响应还可能包括一个“消息”属性，该属性可以包括附加信息。此信息仅用于诊断目的，可以使用任何语言。消息的语言应该用“xml:lang”属性表示。
This section describes in detail the parameters that are used for this protocol. Table 1 lists the top-level components used within the protocol and where they are mandatory (m) or optional (o) for each of the messages.
本节详细介绍用于此协议的参数。表1列出了协议中使用的顶级组件，以及它们对于每个消息是必需的（m）或可选的（o）。
+----------------+-----------+------------+------------+------------+
| Parameter | Section | Location | Location | Error |
| | | Request | Response | |
+----------------+-----------+------------+------------+------------+
| responseTime | 6.1 | o | | |
| | | | | |
| locationType | 6.2 | o | | |
| | | | | |
| code | 6.3 | | | m |
| | | | | |
| message | 6.4 | | | o |
| | | | | |
| locationUriSet | 6.5 | | o | |
| | | | | |
| Presence | 6.6 | | o | |
| (PIDF-LO) | | | | |
+----------------+-----------+------------+------------+------------+
+----------------+-----------+------------+------------+------------+
| Parameter | Section | Location | Location | Error |
| | | Request | Response | |
+----------------+-----------+------------+------------+------------+
| responseTime | 6.1 | o | | |
| | | | | |
| locationType | 6.2 | o | | |
| | | | | |
| code | 6.3 | | | m |
| | | | | |
| message | 6.4 | | | o |
| | | | | |
| locationUriSet | 6.5 | | o | |
| | | | | |
| Presence | 6.6 | | o | |
| (PIDF-LO) | | | | |
+----------------+-----------+------------+------------+------------+
Table 1: Message Parameter Usage
表1：消息参数用法
The "responseTime" attribute MAY be included in a location request message. The "responseTime" attribute includes a time value indicating to the LIS how long the Device is prepared to wait for a response or a purpose for which the Device needs the location.
“responseTime”属性可以包含在位置请求消息中。“responseTime”属性包括一个时间值，向LIS指示设备准备等待响应或设备需要定位的目的的时间。
In the case of emergency services, the purpose of obtaining the LI could be either for routing a call to the appropriate Public Safety Answering Point (PSAP) or indicating the location to which responders should be dispatched. The values defined for the purpose, "emergencyRouting" and "emergencyDispatch", will likely be governed by jurisdictional policies and should be configurable on the LIS.
在紧急服务的情况下，获取LI的目的可以是将呼叫路由到适当的公共安全应答点（PSAP），或者指示应将应答者派遣到的位置。为此目的定义的值“emergencyRouting”和“emergencyDispatch”很可能受管辖政策的管辖，并且应在LIS上进行配置。
The time value in the "responseTime" attribute is expressed as a non-negative integer in units of milliseconds. The time value is indicative only, and the LIS is under no obligation to strictly adhere to the time limit implied; any enforcement of the time limit is left to the requesting Device. The LIS provides the most accurate LI that can be determined within the specified interval for the specific service.
“responseTime”属性中的时间值以毫秒为单位表示为非负整数。时间价值仅供参考，LIS没有义务严格遵守暗示的时间限制；时间限制的任何强制执行都留给请求设备。LIS提供最准确的LI，可在特定服务的指定间隔内确定。
The LIS may use the value of the time in the "responseTime" attribute as input when selecting the method of location determination, where multiple such methods exist. If the "responseTime" attribute is absent, then the LIS should return the most precise LI it is capable of determining, with the time interval being implementation dependent.
当选择位置确定方法时，LIS可以使用“responseTime”属性中的时间值作为输入，其中存在多个这样的方法。如果缺少“responseTime”属性，则LIS应返回其能够确定的最精确的LI，时间间隔取决于实现。
The "locationType" element MAY be included in a location request message. It contains a list of LI types that are requested by the Device. The following list describes the possible values:
“locationType”元素可以包含在位置请求消息中。它包含设备请求的LI类型列表。以下列表描述了可能的值：
any: The LIS SHOULD attempt to provide LI in all forms available to it.
任何：LIS应尝试以其可用的所有形式提供LI。
geodetic: The LIS SHOULD return a location by value in the form of a geodetic location for the Target.
大地测量：LIS应以目标的大地测量位置的形式按值返回位置。
civic: The LIS SHOULD return a location by value in the form of a civic address for the Target.
思域：LIS应以目标的思域地址的形式按值返回位置。
locationURI: The LIS SHOULD return a set of Location URIs for the Target.
locationURI:LIS应该为目标返回一组位置URI。
The LIS SHOULD return the requested location type or types. The location types the LIS returns also depend on the setting of the optional "exact" attribute. If the "exact" attribute is set to "true", then the LIS MUST return either the requested location type or provide an error response. The "exact" attribute does not apply (is ignored) for a request for a location type of "any". Further detail of the "exact" attribute processing is provided in the following Section 6.2.1.
LIS应返回请求的位置类型。LIS返回的位置类型还取决于可选“精确”属性的设置。如果“精确”属性设置为“true”，则LIS必须返回请求的位置类型或提供错误响应。“精确”属性不适用于（忽略）位置类型为“任意”的请求。下文第6.2.1节提供了“精确”属性处理的进一步详细信息。
When there is a request for specific locationType(s) and the "exact" attribute is "false", the LIS MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type. The "SHOULD"-strength requirements on this parameter for specific location types are included to allow for soft-failover. This enables a fixed client configuration that prefers a specific location type without causing location requests to fail when that location type is unavailable. For example, a notebook computer could be configured to retrieve civic addresses, which is usually available from typical home or work situations. However, when using a wireless modem, the LIS might be unable to provide a civic address and thus provides a geodetic address.
当有特定位置类型的请求且“精确”属性为“false”时，LIS可提供额外的位置类型，或者如果无法满足请求的位置类型，则可提供替代类型。包括针对特定位置类型的此参数的“应”强度要求，以允许软故障切换。这将启用固定客户端配置，该配置首选特定位置类型，而不会在该位置类型不可用时导致位置请求失败。例如，笔记本电脑可以配置为检索公民地址，这通常可以从典型的家庭或工作环境中获得。但是，当使用无线调制解调器时，LIS可能无法提供公民地址，因此无法提供大地测量地址。
The LIS SHOULD return location information in a form that is suited for routing and responding to an emergency call in its jurisdiction, specifically by value. The LIS MAY alternatively or additionally return a Location URI. If the "locationType" element is absent, a value of "any" MUST be assumed as the default. A Location URI provided by the LIS is a reference to the most current available LI and is not a stable reference to a specific location.
LIS应以适合在其管辖范围内路由和响应紧急呼叫的形式返回位置信息，特别是通过值。LIS可替代地或附加地返回位置URI。如果缺少“locationType”元素，则必须假定“any”值为默认值。LIS提供的位置URI是对最新可用LI的引用，而不是对特定位置的稳定引用。
It should be noted that the protocol does not support a request to just receive one of a subset of location types. For example, in the case where a Device has a preference for just "geodetic" or "civic", it is necessary to make the request without an "exact" attribute, including both location types. In this case, if neither is available, a LIS SHOULD return a locationURI if available.
应该注意，该协议不支持仅接收位置类型子集之一的请求。例如，在设备仅偏好“大地测量”或“公民”的情况下，有必要在没有“精确”属性的情况下发出请求，包括两种位置类型。在这种情况下，如果两者都不可用，LIS应该返回locationURI（如果可用）。
The LIS SHOULD provide the locations in the response in the same order in which they were included in the "locationType" element in the request. Indeed, the primary advantage of including specific location types in a request when the "exact" attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a locationRequest for "civic" could yield any of the following location types in the response:
LIS应按照请求中“locationType”元素中包含位置的相同顺序提供响应中的位置。实际上，当“exact”属性设置为“false”时，在请求中包含特定位置类型的主要优点是确保以特定顺序接收可用位置。例如，“civic”的locationRequest可以在响应中生成以下任意位置类型：
o civic
o 公民的
o civic, geodetic
o 大地测量学
o civic, locationURI
o 思域
o civic, geodetic, locationURI
o 城市、大地测量、位置
o civic, locationURI, geodetic
o civic、locationURI、大地测量
o geodetic, locationURI (only if civic is not available)
o 大地测量，位置URI（仅当civic不可用时）
o locationURI, geodetic (only if civic is not available)
o 位置URI，大地测量（仅当civic不可用时）
o geodetic (only if civic is not available)
o 大地测量（仅当civic不可用时）
o locationURI (only if civic is not available)
o locationURI（仅当civic不可用时）
For the example above, if the "exact" attribute was "true", then the only possible response is either a "civic" location or an error message.
对于上面的示例，如果“exact”属性为“true”，则唯一可能的响应是“civic”位置或错误消息。
The "exact" attribute MAY be included in a location request message when the "locationType" element is included. When the "exact" attribute is set to "true", it indicates to the LIS that the contents of the "locationType" parameter MUST be strictly followed. The default value of "false" allows the LIS the option of returning something beyond what is specified, such as a set of Location URIs when only a civic location was requested.
当包含“locationType”元素时，“精确”属性可以包含在位置请求消息中。当“精确”属性设置为“真”时，它向LIS指示必须严格遵守“locationType”参数的内容。默认值“false”允许LIS选择返回超出指定范围的内容，例如仅请求civic位置时返回一组位置URI。
A value of "true" indicates that the LIS MUST provide a location of the requested type or types or MUST provide an error. The LIS MUST provide the requested types only. The LIS MUST handle an exact request that includes a "locationType" element set to "any" as if the "exact" attribute were set to "false".
值“true”表示LIS必须提供所请求类型的位置，或者必须提供错误。LIS必须仅提供请求的类型。LIS必须处理包含设置为“any”的“locationType”元素的确切请求，就像“exact”属性设置为“false”一样。
All "error" responses MUST contain a response code. All errors are application-level errors and MUST only be provided in successfully processed transport-level responses. For example, where HTTP/HTTPS is used as the transport, HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
所有“错误”响应必须包含响应代码。所有错误都是应用程序级错误，只能在成功处理的传输级响应中提供。例如，当使用HTTP/HTTPS作为传输时，持有的错误消息必须由200OK HTTP/HTTPS响应携带。
The value of the response code MUST be an IANA-registered value. The following tokens are registered by this document:
响应代码的值必须是IANA注册值。本文档注册了以下令牌：
requestError: This code indicates that the request was badly formed in some fashion (other than the XML content).
requestError：此代码表示请求以某种方式（XML内容除外）格式错误。
xmlError: This code indicates that the XML content of the request was either badly formed or invalid.
xmlError：此代码表示请求的XML内容格式错误或无效。
generalLisError: This code indicates that an unspecified error occurred at the LIS.
GeneralError：此代码表示LIS发生未指定的错误。
locationUnknown: This code indicates that the LIS could not determine the location of the Device. The same request can be sent by the Device at a later time. Devices MUST limit any attempts to retry requests.
locationUnknown：此代码表示LIS无法确定设备的位置。设备可以在以后发送相同的请求。设备必须限制重试请求的任何尝试。
unsupportedMessage: This code indicates that an element in the XML document for the request was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver.
unsupportedMessage：此代码表示LIS不支持或不理解请求的XML文档中的元素。当保留的请求包含接收方不支持的文档元素时，将使用此错误代码。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
超时：此代码表示LIS无法在“responseTime”参数中指定的时间内满足请求。
cannotProvideLiType: This code indicates that the LIS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true".
CannotProviderType：此代码表示LIS无法提供请求类型的LI。当“locationType”参数上的“exact”属性设置为“true”时，使用此代码。
notLocatable: This code indicates that the LIS is unable to locate the Device and that the Device MUST NOT make further attempts to retrieve LI from this LIS. This error code is used to indicate that the Device is outside the access network served by the LIS, for instance, the VPN and NAT scenarios discussed in Section 4.1.2.
notLocatable：此代码表示LIS无法定位设备，并且设备不得进一步尝试从此LIS检索LI。此错误代码用于指示设备位于LIS服务的接入网络之外，例如，第4.1.2节中讨论的VPN和NAT场景。
The "error" message MAY include one or more "message" attributes to convey some additional, human-readable information about the result of the request. The message MAY be included in any language, which SHOULD be indicated by the "xml:lang", attribute. The default language is assumed to be English ("en") [RFC5646].
“错误”消息可以包括一个或多个“消息”属性，以传达关于请求结果的一些附加的、人类可读的信息。消息可以包含在任何语言中，该语言应该由“xml:lang”属性表示。默认语言假定为英语（“en”）[RFC5646]。
The "locationUriSet" element received in a "locationResponse" message MAY contain any number of "locationURI" elements. It is RECOMMENDED that the LIS allocate a Location URI for each scheme that it supports and that each scheme is present only once. URI schemes and their secure variants, such as HTTP and HTTPS, MUST be regarded as two separate schemes.
在“locationResponse”消息中接收的“LocationUriste”元素可以包含任意数量的“locationURI”元素。建议LIS为其支持的每个方案分配一个位置URI，并且每个方案只存在一次。URI方案及其安全变体（如HTTP和HTTPS）必须被视为两个独立的方案。
If a "locationUriSet" element is received in a "locationResponse" message, it MUST contain an "expires" attribute, which defines the length of time for which the set of "locationURI" elements are valid.
如果在“locationResponse”消息中接收到“LocationUrSet”元素，则该元素必须包含“expires”属性，该属性定义“locationURI”元素集有效的时间长度。
The "locationURI" element includes a single Location URI. In order for a URI of any particular scheme to be included in a response, there MUST be a specification that defines how that URI can be used to retrieve location information. The details of the protocol for dereferencing must meet the location dereference protocol requirements as specified in [RFC5808] and are outside the scope of this base HELD specification.
“locationURI”元素包含一个位置URI。为了在响应中包含任何特定方案的URI，必须有一个规范来定义如何使用该URI检索位置信息。解引用协议的细节必须满足[RFC5808]中规定的位置解引用协议要求，并且不在本基本规范的范围内。
Each Location URI that is allocated by the LIS is unique to the Device that is requesting it. At the time the Location URI is provided in the response, there is no binding to a specific location
LIS分配的每个位置URI对于请求它的设备都是唯一的。在响应中提供位置URI时，没有绑定到特定位置
type and the Location URI is totally independent of the specific type of location it might reference. The specific location type is determined at the time of dereference.
类型和位置URI完全独立于它可能引用的特定位置类型。具体位置类型在取消引用时确定。
A "locationURI" SHOULD NOT contain any information that could be used to identify the Device or Target. Thus, it is RECOMMENDED that the "locationURI" element contain a public address for the LIS and an anonymous identifier, such as a local identifier or unlinked pseudonym.
“locationURI”不应包含可用于标识设备或目标的任何信息。因此，建议“locationURI”元素包含LIS的公共地址和匿名标识符，例如本地标识符或未链接的假名。
When a LIS returns a "locationURI" element to a Device, the policy on the "locationURI" is set by the LIS alone. This specification does not include a mechanism for the HELD client to set access control policies on a "locationURI". Conversely, there is no mechanism, in this protocol as defined in this document, for the LIS to provide a Device the access control policy to be applied to a "locationURI". Since the Device is not aware of the access controls to be applied to (subsequent) requests to dereference a "locationURI", the client SHOULD protect a "locationURI" as if it were a Location Object -- i.e., the Device SHOULD send a "locationURI" over encrypted channels and only to entities that are authorized to have access to the location.
当LIS向设备返回“locationURI”元素时，“locationURI”上的策略由LIS单独设置。本规范不包括被保留客户端在“locationURI”上设置访问控制策略的机制。相反，在本文件中定义的协议中，没有机制让LIS向设备提供应用于“locationURI”的访问控制策略。由于设备不知道将应用于（后续）取消引用“locationURI”的请求的访问控制，因此客户端应保护“locationURI”，就像它是位置对象一样——即，设备应通过加密通道发送“locationURI”，并且仅发送给有权访问该位置的实体。
Further guidelines to ensure the privacy and confidentiality of the information contained in the "locationResponse" message, including the "locationURI", are included in Section 9.3.
第9.3节提供了进一步的指南，以确保“locationResponse”消息中包含的信息（包括“locationURI”）的隐私和保密性。
The "expires" attribute is only included in a "locationResponse" message when a "locationUriSet" element is included. The "expires" attribute indicates the date/time at which the Location URIs provided by the LIS will expire. The "expires" attribute does not define the length of time a location received by dereferencing the Location URI will be valid. The "expires" attribute is RECOMMENDED not to exceed 24 hours and SHOULD be a minimum of 30 minutes.
当包含“LocationUrSet”元素时，“expires”属性仅包含在“locationResponse”消息中。“expires”属性表示LIS提供的位置URI将过期的日期/时间。“expires”属性未定义通过取消引用位置URI接收的位置有效的时间长度。“expires”属性建议不超过24小时，并且至少应为30分钟。
All date-time values used in HELD MUST be expressed in Universal Coordinated Time (UTC) using the Gregorian calendar. The XML schema allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used with HELD. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values.
HOLD中使用的所有日期时间值必须使用公历以世界协调时间（UTC）表示。XML模式允许使用时区标识符来指示从零子午线的偏移，但此选项不得与HOLD一起使用。必须使用[W3C.REC-xmlschema-2-20041028]中定义的使用大写“T”和“Z”字符的扩展日期时间表单来表示日期时间值。
Location responses that contain a "locationUriSet" element MUST include the expiry time in the "expires" attribute. If a Device dereferences a Location URI after the expiry time, the dereference SHOULD fail.
包含“LocationUrSet”元素的位置响应必须在“expires”属性中包含过期时间。如果设备在到期时间后取消对位置URI的引用，则取消引用应失败。
A single "presence" parameter MAY be included in the "locationResponse" message when specific locationTypes (e.g., "geodetic" or "civic") are requested or a "locationType" of "any" is requested. The LIS MUST follow the subset of the rules relating to the construction of the "location-info" element in the PIDF-LO Usage Clarification, Considerations, and Recommendations document [RFC5491] in generating the PIDF-LO for the presence parameter.
当请求特定位置类型（例如，“大地测量”或“公民”）或请求“任何”的“位置类型”时，“位置响应”消息中可能包含单个“存在”参数。LIS在生成存在参数的PIDF-LO时，必须遵循PIDF-LO使用说明、注意事项和建议文档[RFC5491]中与“位置信息”元素构造相关的规则子集。
The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used.
LIS不得在PIDF-LO中包含任何识别设备的方法，除非其能够验证标识符是否正确，并且规则制定者明确允许包含标识。因此，包含标识的PIDF参数要么被忽略，要么包含未链接的假名[RFC3693]。LIS应为PIDF文档的强制存在“实体”属性生成唯一的、未链接的存在实体URI。不使用可选参数，如“触点”和“设备ID”元素[RFC4479]。
Note that the presence parameter is not explicitly shown in the XML schema in Section 7 for a location response message, due to XML schema constraints, since PIDF is already defined and registered separately. Thus, the "##other" namespace serves as a placeholder for the presence parameter in the schema.
注意，由于XML模式约束，第7节中的XML模式中没有明确显示位置响应消息的presence参数，因为PIDF已经单独定义和注册。因此，“##other”名称空间充当模式中presence参数的占位符。
This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/held+xml" format. This is presented as a formal definition of the "application/held+xml" format. Note that the XML Schema Definition is not intended to be used with on-the-fly validation of the presence XML document. Whitespaces are included in the schema to conform to the line length restrictions of the RFC format without having a negative impact on the readability of the document. Any conforming processor should remove leading and trailing white spaces.
本节给出了“application/hold+XML”格式的XML模式定义[W3C.REC-xmlschema-1-20041028][W3C.REC-xmlschema-2-20041028]。这是“application/hold+xml”格式的正式定义。请注意，XML模式定义不打算用于对状态XML文档进行动态验证。模式中包括空格，以符合RFC格式的行长度限制，而不会对文档的可读性产生负面影响。任何合格的处理器都应删除前导和尾随空格。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
This document (RFC 5985) defines HELD messages.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation>
This document (RFC 5985) defines HELD messages.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<!-- Return Location -->
<xs:complexType name="returnLocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="expires" type="xs:dateTime"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Return Location -->
<xs:complexType name="returnLocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="expires" type="xs:dateTime"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- responseTime Type -->
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- responseTime Type -->
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- Location Type -->
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="held:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<!-- Location Type -->
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="held:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
<xs:enumeration value="locationURI"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
<xs:enumeration value="locationURI"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Message Definitions -->
<xs:complexType name="baseRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Message Definitions -->
<xs:complexType name="baseRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence/>
<xs:attribute name="responseTime" type="held:responseTimeType"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="message" type="held:errorMsgType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="code" type="xs:token"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="message" type="held:errorMsgType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="code" type="xs:token"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="errorMsgType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="errorMsgType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="error" type="held:errorType"/>
<xs:element name="error" type="held:errorType"/>
<!-- Location Response -->
<xs:complexType name="locationResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet"
type="held:returnLocationType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Location Response -->
<xs:complexType name="locationResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet"
type="held:returnLocationType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationResponse"
type="held:locationResponseType"/>
<xs:element name="locationResponse"
type="held:locationResponseType"/>
<!-- Location Request -->
<xs:complexType name="locationRequestType">
<xs:complexContent>
<!-- Location Request -->
<xs:complexType name="locationRequestType">
<xs:complexContent>
<xs:extension base="held:baseRequestType">
<xs:sequence>
<xs:element name="locationType"
type="held:locationTypeType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:extension base="held:baseRequestType">
<xs:sequence>
<xs:element name="locationType"
type="held:locationTypeType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationRequest"
type="held:locationRequestType"/>
<xs:element name="locationRequest"
type="held:locationRequestType"/>
</xs:schema>
</xs:schema>
This section describes the use of HTTP [RFC2616] and HTTP over TLS [RFC2818] as transport mechanisms for the HELD protocol, which a conforming LIS and Device MUST support.
本节描述了HTTP[RFC2616]和HTTP over TLS[RFC2818]作为HOLD协议传输机制的使用，一致性LIS和设备必须支持该协议。
Although HELD uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a LIS is not a fully compliant HTTP server. It is intended that a LIS can easily be built using an HTTP server with extensibility mechanisms and that a HELD Device can trivially use existing HTTP libraries. This subset of requirements helps implementors avoid ambiguity with the many options that the full HTTP protocol offers.
虽然HOLD使用HTTP作为传输，但它使用HTTP功能的严格子集，并且由于某些功能的限制，LIS不是完全兼容的HTTP服务器。其目的是使用具有可扩展性机制的HTTP服务器可以轻松构建LIS，并且保持的设备可以轻松地使用现有的HTTP库。此需求子集有助于实现者避免对完整HTTP协议提供的许多选项产生歧义。
A Device that conforms to this specification MAY choose not to support HTTP authentication [RFC2617] or cookies [RFC2965]. Because the Device and the LIS may not necessarily have a prior relationship, the LIS SHOULD NOT require a Device to authenticate, either using the above HTTP authentication methods or TLS client authentication. Unless all Devices that access a LIS can be expected to be able to authenticate in a certain fashion, denying access to location information could prevent a Device from using location-dependent services, such as emergency calling. Extensions to this protocol might result in the addition of request parameters that a LIS might use to decide to request Device authentication.
符合本规范的设备可以选择不支持HTTP身份验证[RFC2617]或Cookie[RFC2965]。因为设备和LIS可能不一定具有优先关系，所以LIS不应该要求设备进行身份验证，无论是使用上述HTTP身份验证方法还是TLS客户端身份验证。除非所有访问LIS的设备都能够以某种方式进行身份验证，否则拒绝访问位置信息可能会阻止设备使用位置相关服务，例如紧急呼叫。此协议的扩展可能会导致添加请求参数，LIS可能会使用这些参数来决定请求设备身份验证。
A HELD request is carried in the body of an HTTP POST request. The Device MUST include a Host header in the request.
保留的请求在HTTP POST请求的主体中进行。设备必须在请求中包含主机标头。
The MIME type of HELD request and response bodies is "application/held+xml". LIS and Device MUST provide this value in the HTTP Content-Type and Accept header fields. If the LIS does not receive the appropriate Content-Type and Accept header fields, the LIS SHOULD fail the request, returning a 406 (not acceptable) response. HELD responses SHOULD include a Content-Length header.
保留请求和响应主体的MIME类型为“application/hold+xml”。LIS和设备必须在HTTP内容类型和接受标头字段中提供此值。如果LIS没有收到适当的内容类型和接受标头字段，则LIS应使请求失败，并返回406（不可接受）响应。保留的响应应包括内容长度标题。
Devices MUST NOT use the "Expect" header or the "Range" header in HELD requests. The LIS MAY return 501 (not implemented) errors if either of these HTTP features are used. In the case that the LIS receives a request from the Device containing an If-* (conditional) header, the LIS SHOULD return a 412 (precondition failed) response.
设备不得在保留的请求中使用“Expect”标头或“Range”标头。如果使用这些HTTP功能之一，LIS可能会返回501（未实现）错误。如果LIS从包含If-*（条件）报头的设备接收到请求，则LIS应返回412（前提条件失败）响应。
The POST method is the only method REQUIRED for HELD. If a LIS chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a HELD Device only uses a POST method, the GET or HEAD MUST be either an escaped URL (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody doing testing/debugging. The LIS could provide information in the HELD response indicating that the URL corresponds to a LIS server and only responds to HELD POST requests, or the LIS could instead try to avoid any leak of information by returning a very generic HTTP error message such as 404 (not found).
POST方法是HOLD所需的唯一方法。如果一个LIS选择支持get或Head，它应该考虑执行get的应用程序类型。由于保留的设备仅使用POST方法，因此GET或HEAD必须是转义URL（例如，有人在协议跟踪或日志文件中找到URL并将其馈送到浏览器中）或进行测试/调试的人。LIS可以在保留的响应中提供信息，指示URL对应于LIS服务器，并且只响应保留的POST请求，或者LIS可以通过返回非常通用的HTTP错误消息（如404（未找到））来尝试避免任何信息泄漏。
The LIS populates the HTTP headers of responses so that they are consistent with the contents of the message. In particular, the "CacheControl" header SHOULD be set to disable caching of any PIDF-LO document or Location URIs by HTTP intermediaries. Otherwise, there is the risk of stale locations and/or the unauthorized disclosure of the LI. This also allows the LIS to control any caching with the HELD "expires" parameter. The HTTP status code MUST indicate a 2xx series response for all HELD locationResponse and HELD error messages.
LIS填充响应的HTTP头，使其与消息内容一致。特别是，“CacheControl”标头应设置为禁用HTTP中介对任何PIDF-LO文档或位置URI的缓存。否则，存在位置陈旧和/或未经授权披露LI的风险。这还允许LIS使用保留的“expires”参数控制任何缓存。HTTP状态代码必须指示所有保持的locationResponse和保持的错误消息的2xx系列响应。
The LIS MAY redirect a HELD request. A Device MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the server that returns the redirect response before following the redirect, if a Device requires that the server is authenticated. A Device SHOULD authenticate the LIS indicated in a redirect.
LIS可以重定向保留的请求。设备必须使用服务器在3xx响应中提供的位置头来处理重定向。重定向时，设备必须遵守Retry After标头指示的延迟。如果设备要求对服务器进行身份验证，则在执行重定向之前，设备必须对返回重定向响应的服务器进行身份验证。设备应验证重定向中指示的LIS。
The LIS SHOULD support persistent connections and request pipelining. If pipelining is not supported, the LIS MUST NOT allow persistent connections. The Device MUST support termination of a response by the closing of a connection.
LIS应支持持久连接和请求管道。如果不支持管道，LIS不得允许持续连接。设备必须支持通过关闭连接来终止响应。
Implementations of HELD that implement HTTP transport MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the Device and LIS. The Device MUST implement the server authentication method described in Section 3.1 of [RFC2818], with an exception in how wildcards are handled. The leftmost label MAY contain the wildcard string "*", which matches any single domain name label. Additional characters in this leftmost label are invalid (that is, "f*.example.com" is not a valid name and does not match any domain name).
实现HTTP传输的HOLD实现必须通过TLS实现传输[RFC2818]。TLS在设备和LIS之间提供消息完整性和机密性。设备必须实现[RFC2818]第3.1节中描述的服务器身份验证方法，但处理通配符的方式除外。最左边的标签可能包含通配符字符串“*”，它与任何单个域名标签匹配。此最左侧标签中的其他字符无效（即，“f*.example.com”不是有效名称，并且与任何域名都不匹配）。
The Device uses the URI obtained during LIS discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD fail a request if server authentication fails, except in the event of an emergency.
设备使用在LIS发现期间获得的URI对服务器进行身份验证。HTTPS[RFC2818]的第3.1节提供了此身份验证方法的详细信息。使用TLS时，如果服务器身份验证失败，则设备应使请求失败，紧急情况除外。
HELD is a location acquisition protocol whereby the client requests its location from a LIS. Specific requirements and security considerations for location acquisition protocols are provided in [RFC5687]. An in-depth discussion of the security considerations applicable to the use of Location URIs and by-reference provision of LI is included in [RFC5808].
HOLD是一种位置获取协议，客户端通过该协议向LIS请求其位置。[RFC5687]中提供了位置采集协议的具体要求和安全注意事项。[RFC5808]中深入讨论了适用于位置URI使用的安全注意事项以及LI的参考条款。
By using the HELD protocol, the client and the LIS expose themselves to two types of risk:
通过使用HOLD协议，客户和LIS将面临两种类型的风险：
Accuracy: The client receives incorrect location information.
准确性：客户收到错误的位置信息。
Privacy: An unauthorized entity receives location information.
隐私：未经授权的实体接收位置信息。
The provision of an accurate and privacy- and confidentiality-protected location to the requestor depends on the success of five steps:
向请求者提供准确且受隐私和保密保护的位置取决于五个步骤的成功：
1. The client must determine the proper LIS.
1. 客户必须确定适当的LIS。
2. The client must connect to the proper LIS.
2. 客户端必须连接到适当的LIS。
3. The LIS must be able to identify the Device by its identifier (IP address).
3. LIS必须能够通过其标识符（IP地址）识别设备。
4. The LIS must be able to return the desired location.
4. LIS必须能够返回所需的位置。
5. HELD messages must be transmitted unmodified between the LIS and the client.
5. 保留的消息必须在LIS和客户端之间不经修改地传输。
Of these, only steps 2, 3, and 5 are within the scope of this document. Step 1 is based on either manual configuration or on the LIS discovery defined in [RFC5986], in which appropriate security considerations are already discussed. Step 4 is dependent on the specific positioning capabilities of the LIS and is thus outside the scope of this document.
其中，只有步骤2、3和5在本文档的范围内。步骤1基于手动配置或[RFC5986]中定义的LIS发现，其中已经讨论了适当的安全注意事项。步骤4取决于LIS的具体定位能力，因此不在本文件范围内。
This document assumes that the LIS to be contacted is identified either by an IP address or a domain name, as is the case for a LIS discovered as described in LIS Discovery [RFC5986]. When the HELD transaction is conducted using TLS [RFC5246], the LIS can authenticate its identity, either as a domain name or as an IP address, to the client by presenting a certificate containing that identifier as a subjectAltName (i.e., as an iPAddress or dNSName, respectively). In the case of the HTTP binding described above, this is exactly the authentication described by TLS [RFC2818]. If the client has external information as to the expected identity or credentials of the proper LIS (e.g., a certificate fingerprint), these checks MAY be omitted. Any binding of HELD MUST be capable of being transacted over TLS so that the client can request the above authentication, and a LIS implementation for a binding MUST include this feature. Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the LIS certificate itself.
本文档假设要联系的LIS通过IP地址或域名进行标识，如LIS发现[RFC5986]中所述发现的LIS。当使用TLS[RFC5246]执行持有的交易时，LIS可以通过将包含该标识符的证书作为subjectAltName（即分别作为IP地址或dNSName）提供给客户机，从而将其身份验证为域名或IP地址。在上述HTTP绑定的情况下，这正是TLS[RFC2818]所描述的身份验证。如果客户机具有关于适当LIS的预期身份或凭证（例如证书指纹）的外部信息，则可以省略这些检查。HOLD的任何绑定必须能够通过TLS进行交易，以便客户端可以请求上述身份验证，并且绑定的LIS实现必须包含此功能。请注意，为了使提供的证书在客户端有效，客户端必须能够验证证书。特别是，证书的验证路径必须以客户端的一个信任锚点结束，即使该信任锚点是LIS证书本身。
In order to prevent that response from being modified en route, messages must be transmitted over an integrity-protected channel. When the transaction is being conducted over TLS (a required feature per Section 9.1), the channel will be integrity protected by appropriate ciphersuites. When TLS is not used, this protection will vary depending on the binding; in most cases, without protection from TLS, the response will not be protected from modification en route.
为了防止在途中修改响应，必须通过完整性保护通道传输消息。当通过TLS（第9.1节要求的功能）进行交易时，通道将由适当的密码套件进行完整性保护。当不使用TLS时，该保护将根据绑定情况而变化；在大多数情况下，如果没有TLS的保护，响应将不会在途中受到修改的保护。
Location information returned by the LIS must be protected from access by unauthorized parties, whether those parties request the location from the LIS or intercept it en route. As in Section 9.2, transactions conducted over TLS with appropriate ciphersuites are protected from access by unauthorized parties en route. Conversely, in most cases, when not conducted over TLS, the response will be accessible while en route from the LIS to the requestor.
必须保护LIS返回的位置信息不被未授权方访问，无论这些方是向LIS请求位置还是在途中拦截位置。如第9.2节所述，使用适当密码套件通过TLS进行的交易受到保护，防止未经授权方在途中访问。相反，在大多数情况下，当不通过TLS进行时，响应将在从LIS到请求者的途中可访问。
Because HELD is an LCP and identifies clients and targets by IP addresses, a requestor is authorized to access location for an IP address only if it is the holder of that IP address. The LIS MUST verify that the client is the target of the returned location, i.e., the LIS MUST NOT provide location to other entities than the target. Note that this is a necessary, but not sufficient, criterion for authorization. A LIS MAY deny requests according to any local policy.
因为HOLD是一个LCP，通过IP地址标识客户机和目标，所以只有当请求者是IP地址的持有者时，才有权访问该IP地址的位置。LIS必须验证客户是返回位置的目标，即LIS不得向目标以外的其他实体提供位置。请注意，这是一个必要但不充分的授权标准。LIS可以根据任何本地策略拒绝请求。
A prerequisite for meeting this requirement is that the LIS must have some assurance of the identity of the client. Since the target of the returned location is identified by an IP address, simply sending the response to this IP address will provide sufficient assurance in many cases. This is the default mechanism in HELD for assuring that location is given only to authorized clients; LIS implementations MUST support a mode of operation in which this is the only client authentication.
满足这一要求的先决条件是，LIS必须对客户的身份有一定的保证。由于返回位置的目标由IP地址标识，因此在许多情况下，只需将响应发送到此IP地址即可提供足够的保证。这是Hold中的默认机制，用于确保仅向授权客户提供位置；LIS实施必须支持一种操作模式，在这种模式下，这是唯一的客户端身份验证。
Using IP return routability as an authenticator means that location information is vulnerable to exposure through IP address spoofing attacks. A temporary spoofing of an IP address could mean that when a Device requests a Location Object or Location URI, it receives another Device's location because the attacker is able to receive packets sent to the spoofed address. In addition, in cases where a Device drops off the network for various reasons, the re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. These exposures are limited by the following:
将IP返回路由能力用作身份验证程序意味着位置信息容易通过IP地址欺骗攻击暴露。IP地址的临时欺骗可能意味着当一个设备请求位置对象或位置URI时，它会接收另一个设备的位置，因为攻击者能够接收发送到欺骗地址的数据包。此外，在设备由于各种原因退出网络的情况下，重复使用设备的IP地址可能导致另一个设备接收原始设备的位置，而不是其自身的位置。这些风险敞口受到以下限制：
o Location URIs MUST have a limited lifetime, as reflected by the value for the "expires" element in Section 6.5.2. The lifetime of Location URIs necessarily depends on the nature of the access.
o 位置URI必须具有有限的生存期，如第6.5.2节中“expires”元素的值所反映的。位置URI的生存期必然取决于访问的性质。
o The LIS and network SHOULD be configured so that the LIS is made aware of Device movement within the network and addressing changes. If the LIS detects a change in the network that results in it no longer being able to determine the location of the Device, then all Location URIs for that Device SHOULD be invalidated.
o 应配置LIS和网络，以便LIS了解网络内的设备移动和寻址更改。如果LIS检测到网络发生变化，导致其无法确定设备的位置，则该设备的所有位置URI都应无效。
The above measures are dependent on network configuration, which SHOULD be considered. For instance, in a fixed Internet access, providers may be able to restrict the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, additional measures may not be necessary.
上述措施取决于网络配置，应予以考虑。例如，在固定互联网接入中，提供商可以将IP地址分配限制在单个物理线路上，以确保不可能进行欺骗；在这种环境下，可能不需要采取额外的措施。
The following sections provide examples of basic HTTP/HTTPS, a simple location request, and a location request for multiple location types, along with the relevant location responses. To focus on important portions of messages, the examples in Sections 10.2 and 10.3 do not show HTTP/HTTPS headers or the XML prologue. In addition, sections of XML not relevant to the example are replaced with comments.
以下各节提供了基本HTTP/HTTPS、简单位置请求和多个位置类型的位置请求的示例，以及相关的位置响应。为了关注消息的重要部分，第10.2节和第10.3节中的示例没有显示HTTP/HTTPS头或XML序言。此外，与示例无关的XML部分将替换为注释。
The examples in this section show complete HTTP/HTTPS messages that include the HELD request or response document.
本节中的示例显示了完整的HTTP/HTTPS消息，其中包括保留的请求或响应文档。
This example shows the most basic request for a LO. The POST includes an empty "locationRequest" element.
此示例显示了LO的最基本请求。POST包含一个空的“locationRequest”元素。
POST /location HTTP/1.1
Host: lis.example.com:49152
Content-Type: application/held+xml;charset=utf-8
Content-Length: 87
POST /location HTTP/1.1
Host: lis.example.com:49152
Content-Type: application/held+xml;charset=utf-8
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"/>
Since the above request does not include a "locationType" element, the successful response to the request may contain any type of location. The following shows a response containing a minimal PIDF-LO.
由于上述请求不包含“locationType”元素，因此对请求的成功响应可能包含任何类型的位置。下面显示了包含最小PIDF-LO的响应。
HTTP/1.1 200 OK
Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 856
HTTP/1.1 200 OK
Server: Example LIS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 856
<?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">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<?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">
<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
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retention-expiry>2006-01-11T03:42:28+00:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retention-expiry>2006-01-11T03:42:28+00:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
The error response to the request is an error document. The following response shows an example error response.
对请求的错误响应是一个错误文档。下面的响应显示了一个示例错误响应。
HTTP/1.1 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 182
HTTP/1.1 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 182
<?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Unable to determine location
</message>
</error>
<?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Unable to determine location
</message>
</error>
The location request shown below doesn't specify any location types or response time.
下面显示的位置请求没有指定任何位置类型或响应时间。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of Location URIs.
此位置请求的示例响应包含位置URI的列表。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
</locationResponse>
</locationURI>
</locationUriSet>
</locationResponse>
An error response to this location request is shown below:
对此位置请求的错误响应如下所示：
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Location not available
</message>
</error>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Location not available
</message>
</error>
The following Location Request message includes a request for geodetic, civic, and any Location URIs.
以下位置请求消息包括对大地测量URI、civic URI和任何位置URI的请求。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
geodetic
civic
locationURI
</locationType>
</locationRequest>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">
geodetic
civic
locationURI
</locationType>
</locationRequest>
The corresponding Location Response message includes the requested location information, including two Location URIs.
相应的位置响应消息包括请求的位置信息，包括两个位置URI。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<gs:Circle xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<gs:Circle xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407242 150.882518</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30
</gs:radius>
</gs:Circle>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2007-05-25T12:35:02+10:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</locationResponse>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
<usage-rules
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy">
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2007-05-25T12:35:02+10:00
</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple>
</presence>
</locationResponse>
IANA has made the registrations detailed in the following sections.
IANA已在以下章节中进行了详细登记。
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:geopriv:hold”。
URI: urn:ietf:params:xml:ns:geopriv:held
URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF、GEOPRIV工作组、(geopriv@ietf.org)，玛丽·巴恩斯。barnes@gmail.com).
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 Messages</title>
</head>
<body>
<h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2>
<p>See RFC 5985</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 Messages</title>
</head>
<body>
<h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2>
<p>See RFC 5985</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
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF、GEOPRIV工作组、(geopriv@ietf.org)，玛丽·巴恩斯。barnes@gmail.com).
Schema: The XML for this schema can be found as the entirety of Section 7 of this document.
模式：此模式的XML可以作为本文档第7节的全部内容找到。
This section registers the "application/held+xml" MIME type.
本节注册“application/hold+xml”MIME类型。
To: ietf-types@iana.org
致：ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml
Subject: Registration of MIME media type application/held+xml
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: held+xml
MIME子类型名称：HOLD+xml
Required parameters: (none)
所需参数：（无）
Optional parameters: charset Same as the charset parameter of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
可选参数：字符集与RFC 3023[RFC3023]第3.2节中指定的“应用程序/xml”的字符集参数相同。
Encoding considerations: Same as the encoding considerations of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
编码注意事项：与RFC 3023[RFC3023]第3.2节中规定的“应用程序/xml”的编码注意事项相同。
Security considerations: This content type is designed to carry protocol data related to the location of an entity, which could include information that is considered private. Appropriate precautions should be taken to limit disclosure of this information.
安全注意事项：此内容类型旨在承载与实体位置相关的协议数据，其中可能包括被视为私有的信息。应采取适当的预防措施来限制该信息的披露。
Interoperability considerations: This content type provides a basis for a protocol. There are multiple interoperable implementations of this protocol.
互操作性注意事项：此内容类型为协议提供了基础。此协议有多个可互操作的实现。
Published specification: RFC 5985
已发布规范：RFC 5985
Applications which use this media type: Location information providers and consumers.
使用此媒体类型的应用程序：位置信息提供者和使用者。
Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT"
Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Mary Barnes <mary.ietf.barnes@gmail.com>
Person & email address to contact for further information:
Mary Barnes <mary.ietf.barnes@gmail.com>
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller: The IETF
作者/变更控制者：IETF
Other information: This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/held+xml.
其他信息：此媒体类型是application/xml[RFC3023]的一种专门化，其中描述的许多注意事项也适用于application/hold+xml。
As defined in this document, IANA created a new registry for the HELD protocol including an initial registry for error codes. The error codes are included in HELD error messages as described in Section 6.3 and defined in the schema in the 'codeType' token in the XML schema in Section 7.
根据本文件的定义，IANA为保留协议创建了一个新的注册表，包括错误代码的初始注册表。如第6.3节所述，错误代码包含在保留的错误消息中，并在第7节XML模式中“codeType”标记的模式中定义。
The following is a summary of the registry:
以下为注册处摘要：
Related Registry: Geopriv HELD Registries, Error codes for HELD
相关注册表：Geopriv HOLD注册表，HOLD的错误代码
Defining RFC: RFC 5985
定义RFC:RFC 5985
Registration/Assignment Procedures: Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the Error codes for HELD is Standards Action: Values are assigned only for Standards Track RFCs approved by the IESG.
注册/分配程序：按照[RFC5226]中概述的政策，IANA为保留的is标准操作的错误代码分配新值的政策：仅为IESG批准的标准跟踪RFC分配值。
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).
注册人联系人：IETF、GEOPRIV工作组、(geopriv@ietf.org)，玛丽·巴恩斯。barnes@gmail.com).
This section registers the following eight initial error codes as described in Section 6.3:
本节登记了第6.3节所述的以下八个初始错误代码：
requestError: This code indicates that the request was badly formed in some fashion.
requestError：此代码表示请求以某种方式格式错误。
xmlError: This code indicates that the XML content of the request was either badly formed or invalid.
xmlError：此代码表示请求的XML内容格式错误或无效。
generalLisError: This code indicates that an unspecified error occurred at the LIS.
GeneralError：此代码表示LIS发生未指定的错误。
locationUnknown: This code indicates that the LIS could not determine the location of the Device.
locationUnknown：此代码表示LIS无法确定设备的位置。
unsupportedMessage: This code indicates that the request was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver.
unsupportedMessage：此代码表示LIS不支持或不理解该请求。当保留的请求包含接收方不支持的文档元素时，将使用此错误代码。
timeout: This code indicates that the LIS could not satisfy the request within the time specified in the "responseTime" parameter.
超时：此代码表示LIS无法在“responseTime”参数中指定的时间内满足请求。
cannotProvideLiType: This code indicates that the LIS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true".
CannotProviderType：此代码表示LIS无法提供请求类型的LI。当“locationType”参数上的“exact”属性设置为“true”时，使用此代码。
notLocatable: This code indicates that the LIS is unable to locate the Device and that the Device MUST NOT make further attempts to retrieve LI from this LIS. This error code is used to indicate that the Device is outside the access network served by the LIS; for instance, the VPN and NAT scenarios discussed in Section 4.1.2.
notLocatable：此代码表示LIS无法定位设备，并且设备不得进一步尝试从此LIS检索LI。该错误代码用于指示设备位于LIS服务的接入网络之外；例如，第4.1.2节中讨论的VPN和NAT场景。
James Winterbottom, Martin Thomson and Barbara Stark are the authors of the original document, from which this WG document was derived. Their contact information is included below. They made additional contributions to the WG document, including the XML schema.
James Winterbottom、Martin Thomson和Barbara Stark是原始文档的作者，本工作组文档就是从原始文档中衍生出来的。他们的联系方式如下。他们对工作组文档做出了其他贡献，包括XML模式。
James Winterbottom Andrew Andrew Building (39) University of Wollongong Northfields Avenue Wollongong, NSW 2522 AU
杰姆斯温特波顿安得烈安得烈大楼（39）卧龙岗大学北菲尔德大道伍伦贡，新南威尔士2522 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Martin Thomson Andrew Andrew Building (39) University of Wollongong Northfields Avenue Wollongong, NSW 2522 AU
马丁汤姆逊安得烈安得烈大厦（39）卧龙岗大学北菲尔德大道伍伦贡，新南威尔士2522 AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark BellSouth Room 7A43 725 W Peachtree St. Atlanta, GA 30308 US
美国佐治亚州亚特兰大桃树街西7A43 725室Barbara Stark BellSouth 30308
EMail: barbara.stark@att.com
EMail: barbara.stark@att.com
The author and contributors would like to thank the participants in the GEOPRIV WG and the following people for their constructive input and feedback on this document (in alphabetical order): Nadine Abbott, Bernard Aboba, Eric Arolick, Richard Barnes (in particular, the security considerations section), Peter Blatherwick, Ben Campbell,
作者和撰稿人感谢GEOPRIV工作组的参与者和以下人员对本文件的建设性意见和反馈（按字母顺序）：Nadine Abbott、Bernard Aboba、Eric Arolick、Richard Barnes（特别是安全考虑部分）、Peter Blatherwick、Ben Campbell、，
Guy Caron, Eddy Corbett, Martin Dawson, Lisa Dusseault, Robins George, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Alexey Melnikov, Roger Marshall, Tim Polk, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Dan Romascanu, Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig, and Karl Heinz Wolf.
盖伊·卡隆、艾迪·科贝特、马丁·道森、丽莎·杜肖特、罗宾斯·乔治、杰罗姆·格雷尼尔、泰德·哈迪、卡伦·詹宁斯、尼尔·贾斯图森、塔林、马克·林纳、帕蒂·麦卡蒙特、阿列克西·梅尔尼科夫、罗杰·马歇尔、蒂姆·波尔克、佩里·普罗泽纽克、卡尔·里德、朱利安·雷什克、埃里克·雷斯考拉、丹·斯坎罗莫、布赖恩·罗森、约翰·施尼兹林、希达·舒伯特、，亨宁·舒尔兹林内、埃德·施拉姆、道格·斯图尔德、汉内斯·茨霍芬尼和卡尔·海因茨·沃尔夫。
[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月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965]Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC 29652000年10月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[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月。
[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月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月。
[W3C.REC-xmlschema-1-20041028] Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028]Thompson，H.，Mendelsohn，N.，Beech，D.，和M.Maloney，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[LLDP-MED] TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint Discovery".
[LLDP-MED]TIA，“ANSI/TIA-1057链路层发现协议-媒体端点发现”。
[LOC-CONVEY] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, July 2010.
[LOC-Transfer]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，正在进行的工作，2010年7月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[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月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825]Polk，J.，Schnizlein，J.，和M.Linsner，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 38252004年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
This appendix describes HELD's compliance to the requirements specified in [RFC5687].
本附录描述了HOLD对[RFC5687]中规定要求的遵守情况。
"The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement. Regarding the latter aspect, such an identifier is only appropriate if it is from the same realm as the one for which the location information service maintains identifier to location mapping."
L7 LCP必须能够携带不同的标识符，或者必须定义一个必须实现的标识符。关于后一个方面，只有当该标识符与位置信息服务维护标识符到位置映射的域来自同一个域时，该标识符才适用
COMPLY
遵守
HELD uses the IP address of the location request message as the primary source of identity for the requesting Device or target. This identity can be used with other contextual network information to provide a physical location for the Target for many network deployments. There may be network deployments where an IP address alone is insufficient to identify a Target in a network. However, any necessary identity extensions for these networks is beyond the scope of this document.
HOLD使用位置请求消息的IP地址作为请求设备或目标的主要标识源。此标识可与其他上下文网络信息一起使用，为许多网络部署的目标提供物理位置。可能存在仅IP地址不足以识别网络中目标的网络部署。但是，这些网络的任何必要身份扩展都超出了本文档的范围。
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a broad range of mobility from Devices that can only move between reboots, to Devices that can change attachment points with the impact that their IP address is changed, to Devices that do not change their IP address while roaming, to Devices that continuously move by being attached to the same network attachment point."
“GEOPRIV Layer 7 Location Configuration Protocol必须支持广泛的移动性，从只能在重新启动之间移动的设备，到可以在IP地址更改的影响下更改连接点的设备，到漫游时不更改IP地址的设备，再到通过连接连续移动的设备到同一网络连接点。“
COMPLY
遵守
Mobility support is inherently a characteristic of the access network technology, and HELD is designed to be access network agnostic. Consequently, HELD complies with this requirement. In addition, HELD provides specific support for mobile environments by providing an optional responseTime attribute in location request messages. Wireless networks often have several different mechanisms at their disposal for position determination (e.g., assisted GPS versus determining the location based on the identity of the serving base station), each providing different degrees of accuracy and taking different amounts of time to yield a result. The responseTime parameter provides the LIS with a criterion which it can use to select a location determination technique.
移动性支持是接入网技术的固有特征，HOLD被设计为接入网不可知。因此，HOLD符合此要求。此外，HOLD通过在位置请求消息中提供可选的responseTime属性，为移动环境提供了特定的支持。无线网络通常有几种不同的定位机制（例如，辅助GPS和基于服务基站的身份确定位置），每种机制都提供不同的准确度，并花费不同的时间来产生结果。responseTime参数为LIS提供了一个可用于选择位置确定技术的标准。
"The design of the L7 LCP MUST NOT assume a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Requirements for resolving a reference to location information are not discussed in this document."
“L7 LCP的设计不得假定应用程序服务提供商（ASP）和访问网络提供商之间存在业务或信任关系。本文档中不讨论解析位置信息引用的要求。”
COMPLY
遵守
HELD describes a location acquisition protocol between a Device and a LIS. In the context of HELD, the LIS is within the Access Network. Thus, HELD is independent of the business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Location acquisition using HELD is subject to the restrictions described in Section 9.
HOLD描述了设备和LIS之间的位置获取协议。在HOLD的上下文中，LIS位于接入网络内。因此，HOLD独立于应用程序服务提供商（ASP）和接入网络提供商之间的业务或信任关系。使用HOLD的位置获取受第9节所述限制的约束。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that there is a trust and business relationship between the L2 and the L3 provider. The L3 provider operates the LIS and needs to obtain location information from the L2 provider since this one is closest to the end host. If the L2 and L3 provider for the same host are different entities, they cooperate for the purposes needed to determine end system locations."
“GEOPRIV第7层位置配置协议的设计必须假设二级和三级提供程序之间存在信任和业务关系。三级提供程序操作LIS，需要从二级提供程序获取位置信息，因为二级提供程序最接近终端主机。如果同一主机的二级和三级提供程序在不同的实体之间，它们为确定终端系统位置所需的目的进行合作。”
COMPLY
遵守
HELD was specifically designed with this model in mind and readily allows itself to chaining requests between operators without a change in protocol being required. HELD is a webservices protocol which can be bound to transports other than HTTP, such as BEEP. Using a protocol such as BEEP offers the option of high request throughput over a dedicated connection between an L3 provider and an L2 provider without incurring the serial restriction imposed by HTTP. This is less easy to do with protocols that do not decouple themselves from the transport.
HOLD是专门为这个模型设计的，它允许自己在操作员之间链接请求，而不需要更改协议。HOLD是一个webservices协议，可以绑定到HTTP以外的传输，如BEEP。使用诸如BEEP之类的协议，可以在L3提供程序和L2提供程序之间的专用连接上提供高请求吞吐量选项，而不会引起HTTP施加的串行限制。对于不将自身与传输分离的协议来说，这是不容易做到的。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST consider legacy residential NAT Devices and Network Termination Equipment (NTE) in an DSL environment that cannot be upgraded to support additional protocols, for example to pass additional information through DHCP."
“GEOPRIV层7位置配置协议的设计必须考虑传统的住宅NAT设备和网络终端设备（NTE）在DSL环境中不能升级以支持附加协议，例如通过DHCP传递附加信息。
COMPLY
遵守
HELD is an application protocol and operates on top of IP. A HELD request from a host behind a residential NAT will traverse the NAT acquiring the external address of the home router. The location provided to the host therefore will be the address of the home router in this circumstance. No changes are required to the home router in order to support this function, HELD was designed specifically to address this deployment scenario.
HOLD是一种应用程序协议，在IP上运行。来自住宅NAT后面的主机的保留请求将通过NAT获取家庭路由器的外部地址。因此，在这种情况下，提供给主机的位置将是家庭路由器的地址。为了支持此功能，不需要对家庭路由器进行任何更改，HOLD是专门为解决此部署场景而设计的。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that at least one end of a VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel."
“GEOPRIV第7层位置配置协议的设计必须假设VPN的至少一端知道VPN功能。在企业场景中，企业端将提供客户端使用的LIS，从而可以检测LIS请求是否通过VPN隧道发起。”
COMPLY
遵守
HELD does not preclude a LIS on the far end of a VPN tunnel from being aware that the client request is occurring over that tunnel. It also does not preclude a client Device from accessing a LIS serving the local physical network and subsequently using the location information with an application that is accessed over a VPN tunnel.
HOLD不排除VPN隧道远端的LIS知道客户端请求正在该隧道上发生。它还不排除客户端设备访问服务于本地物理网络的LIS，并随后使用通过VPN隧道访问的应用程序的位置信息。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume prior network access authentication."
“GEOPRIV第7层位置配置协议的设计不得采用事先的网络访问身份验证。”
COMPLY
遵守
HELD makes no assumptions about prior network access authentication. HELD strongly recommends the use of TLS with server-side certificates for communication between the endpoint and the LIS. There is no requirement for the endpoint to authenticate with the LIS.
Hold对之前的网络访问身份验证不做任何假设。Hold强烈建议使用带有服务器端证书的TLS在端点和LIS之间进行通信。端点不需要向LIS进行身份验证。
"The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume end systems being aware of the access network topology. End systems are, however, able to determine their public IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
GEOPRIV第7层位置配置协议的设计不得假定终端系统知道接入网络拓扑。但是，终端系统能够通过STUN或NSIS NATFW NSLP等机制确定其公共IP地址
COMPLY
遵守
HELD makes no assumption about the network topology. HELD doesn't require that the Device know its external IP address, except where that is required for discovery of the LIS.
Hold对网络拓扑结构不作任何假设。HOLD不要求设备知道其外部IP地址，除非发现LIS需要知道。
"The L7 LCP MUST define a single mandatory to implement discovery mechanism."
“L7 LCP必须定义一个强制项以实现发现机制。”
COMPLY
遵守
HELD uses the discovery mechanism in [RFC5986].
HOLD使用[RFC5986]中的发现机制。
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the <geopriv> element into the <device> element of the presence document (see RFC 4479). This ensures that the resulting PIDF-LO document, which is subsequently distributed to other entities, conforms to the rules outlined in [now RFC 5941]."
“当LIS根据RFC 4119创建PIDF-LO时，它必须将<geopriv>元素放入状态文档的<device>元素中（参见RFC 4479）。这确保生成的PIDF-LO文档（随后分发给其他实体）符合[现在的RFC 5941]中概述的规则。”
COMPLY
遵守
HELD protocol overview (Section 4) describes the requirements on the LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated by the LIS MUST conform to [RFC5491].
保留协议概述（第4节）描述了创建PIDF-LO时对LIS的要求，并规定LIS生成的PIDF-LO必须符合[RFC5491]。
Author's Address
作者地址
Mary Barnes (editor) Polycom
玛丽·巴恩斯（编辑）宝利通
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com