Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6155 M. Thomson
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
March 2011
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6155 M. Thomson
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
March 2011
Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
在启用HTTP的位置传递中使用设备标识（保留）
Abstract
摘要
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
当位置信息服务器接收到位置信息请求（使用locationRequest消息）时（如基本HTTP启用位置传递（HOLD）规范中所述），它将使用到达消息的源IP地址作为指向位置确定过程的指针。在可以根据IP地址确定设备位置的环境中，这就足够了。
Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
本文档还介绍了另外两个用例。在第一种情况下，位置配置需要来自请求中提供的源IP地址的附加或替代标识符。在第二种情况下，设备以外的实体请求设备的位置。
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted.
本文档扩展了HOLD协议，允许位置请求消息携带设备标识符。隐私和安全注意事项描述了允许包含标识符的请求的条件。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6155.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6155.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
2.1.3. Network Interfaces and Devices . . . . . . . . . . . . 9
2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Targets Requesting Their Own Location . . . . . . . . . . 18
5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 22
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
2.1.3. Network Interfaces and Devices . . . . . . . . . . . . 9
2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Targets Requesting Their Own Location . . . . . . . . . . 18
5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 22
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Protocols for requesting and providing location information require a way for the requestor to specify the location that should be returned. In a Location Configuration Protocol (LCP), the location being requested is the requestor's location. This fact can make the problem of identifying the Device simple, since IP datagrams that carry the request already carry an identifier for the Device -- namely, the source IP address of an incoming request. Existing LCPs, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP ([RFC3825], [RFC4776]) rely on the source IP address or other information present in protocol datagrams to identify a Device.
请求和提供位置信息的协议要求请求者指定应该返回的位置。在位置配置协议（LCP）中，被请求的位置是请求者的位置。这一事实可以简化识别设备的问题，因为承载请求的IP数据报已经包含设备的标识符——即传入请求的源IP地址。现有LCP，如启用HTTP的位置传递（保持）[RFC5985]和DHCP（[RFC3825]，[RFC4776]）依赖于源IP地址或协议数据报中存在的其他信息来识别设备。
Aside from the datagrams that form a request, a Location Information Server (LIS) does not necessarily have access to information that could further identify the Device. In some circumstances, as shown in [RFC5687], additional identification information can be included in a request to identify a Device.
除了形成请求的数据报之外，位置信息服务器（LIS）不一定能够访问能够进一步识别设备的信息。在某些情况下，如[RFC5687]所示，可以在识别设备的请求中包含额外的识别信息。
This document extends the HELD protocol to support the inclusion of additional identifiers for the Device in HELD location requests. An XML schema is defined that provides a structure for including these identifiers in HELD requests.
本文档扩展了保持协议，以支持在保持位置请求中包含设备的附加标识符。定义了一个XML模式，该模式提供了一种结构，用于在保留的请求中包含这些标识符。
An important characteristic of this addition is that the HELD protocol with identity extensions implemented is not considered an LCP. The scope of an LCP is limited to the interaction between a Device and a LIS, and LCPs can guarantee the identity of Devices without additional authorization checks. A LIS identifies the Device making the LCP request using the source addressing on the request packets, using return routability to ensure that these identifiers are not spoofed.
此添加的一个重要特征是，实现了标识扩展的HOLD协议不被视为LCP。LCP的范围仅限于设备和LIS之间的交互，LCP可以保证设备的身份，而无需额外的授权检查。LIS使用请求数据包上的源地址识别发出LCP请求的设备，并使用返回路由能力确保这些标识符不会被伪造。
HELD with identity extensions allows a requestor to explicitly provide identification details in the body of a location request. This means that location requests can be made in cases where additional Device identity checks are necessary, and in cases where the requestor is not the Device itself. Third-party Location Recipients (LRs) are able to make requests that include identifiers to retrieve location information about a particular Device.
使用标识扩展保持允许请求者在位置请求的主体中显式提供标识详细信息。这意味着，在需要额外的设备身份检查的情况下，以及在请求者不是设备本身的情况下，可以发出位置请求。第三方位置接收者（LR）能够发出包含标识符的请求，以检索特定设备的位置信息。
The usage of identifiers in HELD introduces a new set of privacy concerns. In an LCP, the requestor can be implicitly authorized to access the requested location information, because it is their own location. In contrast, a third-party LR must be explicitly authorized when requesting the location of a Device. Establishing appropriate authorization and other related privacy concerns are discussed in Section 4.
在Hold中使用标识符引入了一组新的隐私问题。在LCP中，请求者可以被隐式授权访问请求的位置信息，因为它是他们自己的位置。相反，在请求设备位置时，必须明确授权第三方LR。第4节讨论了建立适当授权和其他相关隐私问题。
This document defines a means to explicitly include Device identity information in the body of a HELD location request. This identity information is used to identify the Device that is the subject (or Target) of the location request. If Device identity is present, the identity of the requestor in the form of the source IP address is not used to identify the subject of the request.
本文档定义了一种在保留位置请求正文中显式包含设备标识信息的方法。此标识信息用于标识作为位置请求主体（或目标）的设备。如果存在设备标识，则不使用源IP地址形式的请求者标识来标识请求的主体。
Device identifiers in HELD can be used for two purposes:
HOLD中的设备标识符可用于两个目的：
Location configuration: A Device can use these parameters to identify itself to a LIS. Identification information other than an IP address might be needed to determine the location of a Device.
位置配置：设备可以使用这些参数向LIS标识自身。可能需要IP地址以外的标识信息来确定设备的位置。
A LIS can authorize location configuration requests using a policy that allows Devices to acquire their own location (see Section 4.1). If an unauthorized third party falsifies addressing on request packets to match the provided Device identity, the request might be erroneously authorized under this policy. Requests containing Device identity MUST NOT be authorized using this policy unless specific measures are taken to prevent this type of attack.
LIS可以使用允许设备获取自己位置的策略来授权位置配置请求（参见第4.1节）。如果未经授权的第三方伪造请求数据包的寻址以匹配所提供的设备标识，则根据此策略可能会错误地授权该请求。除非采取具体措施防止此类攻击，否则不得使用此策略授权包含设备标识的请求。
This document describes a mechanism that provides assurances that the requestor and included Device identity are the same for the Network Access Identifier (NAI) in a WiMAX network. The LIS MUST treat requests containing other identifiers as third-party requests, unless it is able to ensure that the provided Device identity is uniquely attributable to the requestor.
本文档描述了一种机制，该机制确保WiMAX网络中的网络访问标识符（NAI）的请求者和包含的设备标识相同。LIS必须将包含其他标识符的请求视为第三方请求，除非它能够确保提供的设备标识可唯一归属于请求者。
Third-party requests: A third-party Location Recipient can be granted authorization to make requests for a given Device. In particular, network services can be permitted to retrieve location for a Device that is unable to acquire location information for itself (see Section 6.3 of [EMERGENCY-CALLING]). This allows use of location-dependent applications -- particularly essential services like emergency calling -- where Devices do not support a location configuration protocol or they are unable to successfully retrieve location information.
第三方请求：可以向第三方位置收件人授予对给定设备进行请求的授权。特别是，可以允许网络服务为无法获取自身位置信息的设备检索位置（见[紧急呼叫]第6.3节）。这允许在设备不支持位置配置协议或无法成功检索位置信息的情况下使用位置相关应用程序，特别是紧急呼叫等基本服务。
This document does not describe how a third party acquires an identifier for a Device, nor how that third party is authorized by a LIS. It is critical that these issues are resolved before permitting a third-party request. A pre-arranged contract between the third party, a Rule Maker, and the LIS operator is necessary to use Device identifiers in this fashion. This contract must
本文档不描述第三方如何获取设备标识符，也不描述该第三方如何获得LIS授权。在允许第三方请求之前解决这些问题至关重要。第三方、规则制定者和LIS运营商之间的预先安排的合同对于以这种方式使用设备标识符是必要的。本合同必须
include how the request is authenticated and the set of identifiers (and types of identifiers) that the third party is authorized to use in requests.
包括如何对请求进行身份验证，以及授权第三方在请求中使用的标识符集（和标识符类型）。
Automated mechanisms to ensure that privacy constraints are respected are possible. For instance, a policy rules document could be used to express the agreed policy. Formal policy documents, such as the common policy [RFC4745], can be applied in an automated fashion by a LIS.
可以使用自动化机制确保隐私约束得到尊重。例如，可以使用策略规则文档来表示商定的策略。正式的策略文档，例如公共策略[RFC4745]，可以由LIS自动应用。
This document uses the term Location Information Server (LIS) and Location Configuration Protocol (LCP) as described in [RFC5687] and [GEOPRIV-ARCH].
本文件使用[RFC5687]和[GEOPRIV-ARCH]中所述的术语位置信息服务器（LIS）和位置配置协议（LCP）。
The term Device is used specifically as the subject of an LCP, consistent with [RFC5985]. This document also uses the term Target to refer to any entity that might be a subject of the same location information. Target is used in a more general sense, including the Device, but also any nearby entity, such as the user of a Device.
术语设备专门用作LCP的主题，符合[RFC5985]。本文档还使用术语Target来指代可能是相同位置信息的主体的任何实体。目标是在更一般的意义上使用的，包括设备，但也包括任何附近的实体，如设备的用户。
A Target has a stake in setting authorization policy on the use of location information. A Rule Maker is the term used for the role that makes policy decisions about authorization, determining what entities are permitted to receive location and how that information is provided.
目标公司在设置使用位置信息的授权策略方面有利害关系。规则制定者是一个用于角色的术语，该角色制定有关授权的策略决策，确定允许哪些实体接收位置以及如何提供该信息。
Device, Target, and Rule Maker are defined in [GEOPRIV-ARCH].
设备、目标和规则制定者在[GEOPRIV-ARCH]中定义。
The term "requestor" is used in this document to refer to the entity making a HELD request.
本文件中的术语“请求者”是指提出保留请求的实体。
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]中所述进行解释。
Identifiers are used as the starting point in location determination. Identifiers might be associated with a different Device over time, but their purpose is to identify the Device, not to describe its environment or network attachment.
标识符用作位置确定的起点。标识符可能随着时间的推移与不同的设备相关联，但其目的是识别设备，而不是描述其环境或网络连接。
Use of any identifier MUST only be allowed if it identifies a single Device at the time that location is determined. The LIS is responsible for ensuring that location information is correct for the Device, which includes ensuring that the identifier is uniquely attributable to the Device.
只有在确定位置时识别单个设备时，才允许使用任何标识符。LIS负责确保设备的位置信息正确，包括确保标识符可唯一归属于设备。
Some identifiers can be either temporary or could potentially identify multiple Devices. Identifiers that are transient or ambiguous could be exploited by an attacker to either gain information about another Device or to coerce the LIS into producing misleading information.
一些标识符可以是临时的，也可以潜在地标识多个设备。攻击者可以利用暂时性或不明确的标识符获取其他设备的信息，或强迫LIS生成误导性信息。
The identifiers described in this document MUST only be used where that identifier is used as the basis for location determination. Considerations relating to the use of identifiers for a Device requesting its own location are discussed in Section 5 of [RFC5687]; this section discusses use of identifiers for authorized third-party requests.
本文件中描述的标识符只能在该标识符用作位置确定基础的情况下使用。[RFC5687]第5节讨论了与请求其自身位置的设备使用标识符有关的注意事项；本节讨论对授权的第三方请求使用标识符。
It is tempting for a LIS implementation to allow alternative identifiers for convenience or some other perceived benefit. The LIS is responsible for ensuring that the identifier used in the request does not refer to a Device other than the one for which it determines location.
对于LIS实现来说，为了方便或其他一些可感知的好处，允许使用替代标识符是很有诱惑力的。LIS负责确保请求中使用的标识符不涉及除其确定位置的设备以外的其他设备。
Some identifiers are always uniquely attributable to a single Device. However, other identifiers can have a different meaning to different entities on a network. This is especially true for IP addresses [RFC2101], but this can be true for other identifiers to varying degrees. Non-uniqueness arises from both topology (all network entities have a subjective view of the network) and time (the network changes over time).
某些标识符总是唯一地归属于单个设备。然而，对于网络上的不同实体，其他标识符可能具有不同的含义。这对于IP地址[RFC2101]来说尤其如此，但对于其他标识符来说，这可能在不同程度上是正确的。非唯一性源于拓扑（所有网络实体都有网络的主观视图）和时间（网络随时间变化）。
Subjective views of the network mean that the identifier a requestor uses to refer to one physical entity could actually apply to a different physical entity when used in a different network context. Unless an authorized third-party requestor and LIS operate in the same network context, each could have a different subjective view of the meaning of the identifier.
网络的主观视图意味着请求者用来指代一个物理实体的标识符在不同的网络上下文中使用时实际上可以应用于不同的物理实体。除非经授权的第三方请求者和LIS在同一网络环境中运行，否则每个人对标识符的含义都可能有不同的主观看法。
Where subjective views differ, the third party receives information that is correct only within the network context of the LIS. The location information provided by the LIS is probably misleading: the requestor believes that the information relates to a different entity than it was generated for.
如果主观观点不同，则第三方仅在LIS的网络环境中接收正确的信息。LIS提供的位置信息可能具有误导性：请求者认为该信息与生成该信息的目的不同。
Authorization policy can be affected by a subjective network view if it is applied based on an identifier or if its application depends on identifiers. The subjective view presented to the LIS and Rule Maker need to agree for the two entities to understand policy on the same terms. For instance, it is possible that the LIS could apply the incorrect authorization policy if it selects the policy using a subjective identifier. Alternatively, it may use the correct policy but apply it incorrectly if subjective identifiers are used.
如果基于标识符应用授权策略或其应用依赖于标识符，则授权策略可能会受到主观网络视图的影响。向LIS和规则制定者提出的主观观点需要两个实体同意以相同的条款理解政策。例如，如果LIS使用主观标识符选择策略，则可能会应用错误的授权策略。或者，它可能使用正确的策略，但如果使用主观标识符，则可能会错误地应用该策略。
In IP networks, network address translation (NAT) and other forms of address modification create network contexts. Entities on either side of the point where modification occurs have a different view of the network. Private use addresses [RFC1918] are the most easily recognizable identifiers that have limited scope.
在IP网络中，网络地址转换（NAT）和其他形式的地址修改会创建网络上下文。发生修改的点两侧的实体具有不同的网络视图。专用地址[RFC1918]是范围有限的最容易识别的标识符。
A LIS can be configured to recognize scenarios where the subjective view of a requestor or Rule Maker might not coincide with the view of the LIS. The LIS can either provide location information that takes the view of the requestor into account, or it can reject the request.
可以将LIS配置为识别请求者或规则制定者的主观视图可能与LIS视图不一致的场景。LIS可以提供考虑请求者视图的位置信息，也可以拒绝请求。
For instance, a LIS might operate within a network that uses a private address space, with NAT between that network and other networks. A third-party request that originates in an external network with an IP address from the private address space might not be valid -- it could be identifying an entity within another address space. The LIS can be configured to reject such requests, unless it knows by other means that the request is valid.
例如，LIS可能在使用专用地址空间的网络中运行，NAT位于该网络和其他网络之间。来自外部网络的第三方请求（其IP地址来自专用地址空间）可能无效——它可能在另一个地址空间中标识实体。LIS可以配置为拒绝此类请求，除非它通过其他方式知道请求有效。
In the same example, the requestor might include an address from the external space in an attempt to identify a host within the network. The LIS could use knowledge about how the external address is mapped to a private address, if that mapping is fixed, to determine an appropriate response.
在同一示例中，请求者可能包括来自外部空间的地址，以尝试识别网络中的主机。LIS可以使用关于外部地址如何映射到私有地址的知识（如果该映射是固定的）来确定适当的响应。
The residential gateway scenario in Section 3.1 of [RFC5687] is a particular example of where a subjective view is permitted. The LIS knowingly provides Devices on the remote side of the residential gateway with location information. The LIS provides location information with appropriate uncertainty to allow for the fact that the residential gateway serves a small geographical area.
[RFC5687]第3.1节中的住宅网关场景是允许主观视图的一个特定示例。LIS故意为住宅网关远程侧的设备提供位置信息。LIS提供具有适当不确定性的位置信息，以考虑住宅网关服务于小地理区域的事实。
Some identifiers are temporary and can, over the course of time, be assigned to different physical entities. An identifier that is reassigned between the time that a request is formulated by a requestor and when the request is received by the LIS causes the LIS to locate a different entity than the requestor intended. The response from the LIS might be accurate, but the request incorrectly associates this information with the wrong subject.
一些标识符是临时的，随着时间的推移，可以分配给不同的物理实体。在请求者提出请求和LIS收到请求之间重新分配的标识符，该标识符使LIS找到与请求者预期不同的实体。LIS的响应可能是准确的，但请求将此信息与错误的主题错误地关联。
A LIS should be configured with information about any potentially temporary identifiers. It can use this information to identify when changes have occurred. A LIS must not provide location information if the identifier it uses might refer to a different Device. If an identifier might have been reassigned recently, or it is likely to be reassigned, it is not suitable as an identifier.
LIS应配置有关任何潜在临时标识符的信息。它可以使用此信息来识别何时发生了更改。如果LIS使用的标识符可能引用其他设备，则LIS不得提供位置信息。如果某个标识符最近可能被重新分配，或者可能被重新分配，则该标识符不适合用作标识符。
It's possible that some degree of uncertainty could persist where identifiers are reassigned frequently; the extent to which errors arising from using transient identifiers are tolerated is a matter for local policy.
在频繁重新分配标识符的情况下，可能存在一定程度的不确定性；允许使用临时标识符产生的错误的程度取决于当地政策。
Several of the identifiers in this document are used to identify a network interface. A Device can have multiple network interfaces. Uniquely identifying any network interface is assumed to be sufficient to identify the Device. When a network interface is identified, the goal is to identify the Device that is immediately attached to the network interface.
本文档中的几个标识符用于标识网络接口。一个设备可以有多个网络接口。唯一标识任何网络接口被认为足以标识设备。识别网络接口时，目标是识别立即连接到网络接口的设备。
Most network interfaces remain physically attached to a particular Device, though a network interface might be physically separable from the Device. By identifying a network interface, any Device that is intended to be identified could change.
大多数网络接口保持物理连接到特定设备，尽管网络接口可能在物理上与设备分离。通过识别网络接口，任何要识别的设备都可能发生变化。
XML elements are used to express the Device identity. The "device" element is used as a general container for identity information. This document defines a basic set of identifiers. An example HELD request, shown in Figure 1, includes an IP version 4 address.
XML元素用于表示设备标识。“设备”元素用作标识信息的通用容器。本文档定义了一组基本标识符。图1所示的一个示例保持请求包括一个IP版本4地址。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip>
</device>
</locationRequest>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip>
</device>
</locationRequest>
Figure 1: HELD Request with Device Identity
图1：具有设备标识的保留请求
A LIS that supports this specification echoes the "device" element in a successful HELD response, including the identifiers that were used as the basis for location determination. Absence of this indication means that the location information was generated using the source IP address in the request.
支持此规范的LIS在成功保持的响应中回显“设备”元素，包括用作位置确定基础的标识符。缺少此指示意味着位置信息是使用请求中的源IP地址生成的。
A "badIdentifier" HELD error code indicates that the requestor is not authorized to use that identifier or that the request contains an identifier that is badly formatted or not supported by the LIS. This code is registered in Section 7.3.
“badIdentifier”保留的错误代码表示请求者无权使用该标识符，或者请求包含格式错误或LIS不支持的标识符。该代码在第7.3节中注册。
If the LIS requires an identifier that is not provided in the request, the desired identifiers MAY be identified in the HELD error response, using the "requiredIdentifiers" element. This element contains a list of XML qualified names [W3C.REC-xml-names11-20060816] that identify the identifier elements required by the LIS. Namespace prefix bindings for the qualified names are taken from document context. Figure 2 shows an example error indicating that the requestor needs to include a media access control (MAC) address (Section 3.2) and IP address (Section 3.1) if the request is to succeed.
如果LIS需要在请求中未提供的标识符，则可以使用“requireIdentifiers”元素在保留的错误响应中标识所需的标识符。此元素包含一个XML限定名列表[W3C.REC-XML-names11-20060816]，用于标识LIS所需的标识符元素。限定名称的命名空间前缀绑定取自文档上下文。图2显示了一个示例错误，表明如果请求要成功，请求者需要包括媒体访问控制（MAC）地址（第3.2节）和IP地址（第3.1节）。
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier">
<message xml:lang="en">MAC address required</message>
<requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac ip
</requiredIdentifiers>
</error>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier">
<message xml:lang="en">MAC address required</message>
<requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac ip
</requiredIdentifiers>
</error>
Figure 2: HELD Error Requesting Device Identifiers
图2：请求设备标识符的保留错误
A limited selection of identifiers are included in this document. The basic Device identity schema allows for the inclusion of elements from any namespace; therefore, additional elements can be defined using different XML namespaces.
本文件包含有限的标识符选择。基本设备标识模式允许包含来自任何名称空间的元素；因此，可以使用不同的XML名称空间定义其他元素。
The "ip" element can express a Device identity as an IP address ([RFC0791], [RFC4291]). The "v" attribute identifies the IP version with a single hexadecimal digit. The element uses the textual format specific to the indicated IP version. The textual format for IP version 4 and version 6 addresses MUST conform to the grammar defined in [RFC3986] ("IPv4address" and "IPv6address", respectively). IP version 6 addresses SHOULD conform to the formatting conventions in [RFC5952].
“ip”元素可以将设备标识表示为ip地址（[RFC0791]、[RFC4291]）。“v”属性用一个十六进制数字标识IP版本。元素使用特定于指定IP版本的文本格式。IP版本4和版本6地址的文本格式必须符合[RFC3986]中定义的语法（“IPv4address”和“IPv6address”）。IP版本6地址应符合[RFC5952]中的格式约定。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
</device>
In situations where location configuration does not require additional identifiers, using an IP address as an identifier enables authorized third-party requests.
在位置配置不需要额外标识符的情况下，使用IP地址作为标识符可以启用授权的第三方请求。
The MAC address used by network interfaces attached to the IEEE LAN [IEEE802]. A MAC address is a unique sequence that is either assigned at the time of manufacture of the interface, or assigned by a local administrator. A MAC address is an appropriate identifier for the Device that uses the network interface as long as the two remain together (see Section 2.1.3).
连接到IEEE LAN[IEEE802]的网络接口使用的MAC地址。MAC地址是在接口制造时分配或由本地管理员分配的唯一序列。MAC地址是使用网络接口的设备的适当标识符，只要两者保持在一起（见第2.1.3节）。
A MAC address can be represented as a MAC-48, EUI-48, or EUI-64 address ([IEEE802], or an extended unique identifier [EUI64]) using the hexadecimal representation defined in [IEEE802].
MAC地址可以使用[IEEE802]中定义的十六进制表示法表示为MAC-48、EUI-48或EUI-64地址（[IEEE802]，或扩展唯一标识符[EUI64]）。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac>
</device>
A locally assigned MAC address is not guaranteed to be unique outside the administrative domain where it is assigned. Locally assigned MAC addresses can only be used within this domain.
本地分配的MAC地址不保证在其分配的管理域之外是唯一的。本地分配的MAC地址只能在此域中使用。
A host might only be known by a flow of packets that it is sending or receiving. On its own, a port number is insufficient to uniquely identify a single host. In combination with an IP address, a port number can be used to uniquely identify a Device in some circumstances.
主机可能只能通过它正在发送或接收的数据包流来识别。端口号本身不足以唯一标识单个主机。在某些情况下，端口号与IP地址结合使用可用于唯一标识设备。
Use of a particular port number can be transient; often significantly more than use of any given IP address. However, widespread use of network address translation (NAT) means that some Devices cannot be uniquely identified by IP address alone. An individual Device might be identified by a flow of packets that it generates. Providing that a LIS has sufficient knowledge of the mappings used by the NAT, an individual target on the remote side of the NAT might be able to be identified uniquely.
特定端口号的使用可能是暂时的；通常比使用任何给定的IP地址都要多得多。然而，网络地址转换（NAT）的广泛使用意味着某些设备无法仅通过IP地址进行唯一标识。单个设备可以通过其生成的数据包流来识别。如果LIS对NAT使用的映射有足够的了解，则NAT远程端的单个目标可能能够被唯一地识别。
Port numbers are defined for UDP [RFC0768], TCP [RFC0793], SCTP [RFC4960], and DCCP [RFC4340].
端口号为UDP[RFC0768]、TCP[RFC0793]、SCTP[RFC4960]和DCCP[RFC4340]定义。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.75</ip>
<udpport>51393</udpport>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.75</ip>
<udpport>51393</udpport>
</device>
Use of port numbers is especially reliant on the value remaining consistent over time.
端口号的使用尤其依赖于随时间保持一致的值。
A Network Access Identifier (NAI) [RFC4282] is an identifier used in network authentication in a range of networks. The identifier establishes a user identity within a particular domain. Often, network services use an NAI in relation to location records, tying network access to user authentication and authorization.
网络访问标识符（NAI）[RFC4282]是一系列网络中用于网络认证的标识符。标识符在特定域中建立用户标识。通常，网络服务使用与位置记录相关的NAI，将网络访问与用户身份验证和授权捆绑在一起。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai>
</device>
The formal grammar for NAI [RFC4282] permits sequences of octets that are not valid UTF-8 [RFC3629] sequences. These sequences cannot be expressed using XML. Therefore, this expression of NAI permits escaping. Sequences of octets that do not represent a valid UTF-8 encoding can be expressed using a backslash ('\') followed by two case-insensitive hexadecimal digits representing the value of a single octet.
NAI[RFC4282]的形式语法允许八位元序列不是有效的UTF-8[RFC3629]序列。这些序列不能用XML表示。因此，NAI的这种表达允许逃跑。不表示有效UTF-8编码的八位字节序列可以使用反斜杠（“\”）后跟表示单个八位字节值的两个不区分大小写的十六进制数字来表示。
The canonical representation of an NAI is the sequence of octets that is produced from the concatenation of UTF-8 encoded sequences of unescaped characters and octets derived from escaped components. The resulting sequence of octets MUST conform to the constraints in [RFC4282].
NAI的规范表示是由未转义字符的UTF-8编码序列和从转义组件派生的八位字节串联而成的八位字节序列。产生的八位字节序列必须符合[RFC4282]中的约束条件。
For example, the NAI "f<U+FC>\<0xFF>@bar.com" that includes the UTF-8 encoded u-umlaut character (U+FC) and an invalid UTF-8 octet (0xFF) might be represented as "f\c3\bc\5c\90@bar.com", though the u-umlaut character might be included directly.
例如，包含UTF-8编码的U-umlaut字符（U+FC）和无效的UTF-8八位字节（0xFF）的NAI“f<U+FC>\<0xFF>\<0xFF>@bar.com”可以表示为“f\c3\bc\5c”\90@bar.com，但u-umlaut字符可能直接包括在内。
An NAI in WiMAX is uniquely attributable to a single Device at any one time. An NAI either identifies a Device or a service subscription, neither of which can have multiple active sessions.
WiMAX中的NAI在任何时候都只能归属于单个设备。NAI标识设备或服务订阅，两者都不能有多个活动会话。
In a WiMAX network, an IP address is not sufficient information for a LIS to locate a Device. The following procedure relies on an NAI to identify the Device. This procedure and the messages and parameters is relies upon are defined in [WiMAX-T33-110-R015v01-B].
在WiMAX网络中，IP地址不足以让LIS定位设备。以下程序依赖NAI来识别设备。[WiMAX-T33-110-R015v01-B]中定义了此过程以及所依赖的消息和参数。
Location requests in a WiMAX network always require the inclusion of an NAI. However, if a LIS receives a request that does not come from an authenticated and authorized third-party requestor, it can treat this request as a location configuration request.
WiMAX网络中的位置请求总是需要包含NAI。但是，如果LIS收到的请求不是来自经过身份验证和授权的第三方请求者，则可以将此请求视为位置配置请求。
After receiving a location request that includes an NAI, the LIS sends a "Location-Requestor-Authentication-Protocol" access request message to the Authentication, Authorization, and Accounting (AAA) server. This request includes an "MS-Identity-Assertion" parameter containing the NAI.
在接收到包含NAI的位置请求后，LIS向认证、授权和记帐（AAA）服务器发送“位置请求者认证协议”访问请求消息。此请求包括包含NAI的“MS标识断言”参数。
The AAA server consults network policy, and if the request is permitted, the response includes the IP address that is currently assigned to the Device. If this IP address matches the source IP address of the HELD location request, the location request can be authorized under the LCP policy (see Section 4.1). Otherwise, the request must be treated as a third-party request.
AAA服务器咨询网络策略，如果允许请求，则响应包括当前分配给设备的IP地址。如果此IP地址与保留位置请求的源IP地址匹配，则可以根据LCP策略授权位置请求（参见第4.1节）。否则，该请求必须被视为第三方请求。
This relies on the same protections against IP address spoofing that are required by [RFC5985]. In addition, the request made of the AAA uses either Diameter [RFC3588] or RADIUS [RFC2865], and therefore relies on the protections provided by those protocols. In order to rely on the access request, the AAA server MUST be authenticated to be a trusted entity for the purpose of providing a link between the
这依赖于[RFC5985]所要求的相同的IP地址欺骗保护。此外，AAA的请求使用直径[RFC3588]或半径[RFC2865]，因此依赖于这些协议提供的保护。为了依赖访问请求，AAA服务器必须经过身份验证，成为可信实体，以便在服务器之间提供链接
NAI and IP address. The AAA protocol MUST also provide protection from modification and replay attacks to ensure that data cannot be altered by an attacker.
NAI和IP地址。AAA协议还必须提供保护，防止修改和重播攻击，以确保数据不会被攻击者更改。
A Device can be identified by a URI [RFC3986]. Any URI can be used providing that the requestor and LIS have a common understanding of the semantics implied by use of the URI.
设备可以通过URI识别[RFC3986]。只要请求者和LIS对使用URI所隐含的语义有共同的理解，就可以使用任何URI。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device>
Particular care needs to be taken in ensuring that a particular URI only refers to a single Device. In many cases, a URI can resolve to multiple destinations. For example, a SIP address of record URI can correspond to a service subscription rather than a single Device.
在确保特定URI只引用单个设备时需要特别小心。在许多情况下，URI可以解析为多个目标。例如，记录URI的SIP地址可以对应于服务订阅，而不是单个设备。
A "tel:" URI [RFC3966] can be used to identify a Device by telephone number:
“电话：”URI[RFC3966]可用于通过电话号码识别设备：
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device>
A fully qualified domain name can be used as the basis for identification using the "fqdn" element.
完全限定的域名可以用作使用“fqdn”元素进行标识的基础。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<fqdn>host.example.net</fqdn>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<fqdn>host.example.net</fqdn>
</device>
This domain name slot, which is aware of Internationalized Domain Names for Applications (IDNA) [RFC5890], is formed from any sequence of valid U-labels or NR-LDH-labels.
该域名槽可识别应用程序的国际化域名（IDNA）[RFC5890]，由有效的U标签或NR LDH标签的任意序列构成。
A domain name does not always correspond to a single IP address or host. If this is the case, a domain name is not a suitable identifier.
域名并不总是对应于单个IP地址或主机。如果是这种情况，域名不是合适的标识符。
A range of different forms of mobile station identifiers are used for different cellular telephony systems. Elements are defined for these identifiers. The following identifiers are defined:
一系列不同形式的移动站标识符用于不同的蜂窝电话系统。元素是为这些标识符定义的。定义了以下标识符：
msisdn: The Mobile Station International Subscriber Dial Number (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15 digits long.
msisdn：移动台国际用户拨号号码（msisdn）[E.213]是一个长度在6到15位之间的E.164号码[E.164]。
imsi: The International Mobile Subscriber Identity (IMSI) [TS.3GPP.23.003] is an identifier associated with all GSM (Global System for Mobile Communications) and UMTS (Universal Mobile Telecommunications System) mobile subscribers between 6 and 15 digits in length.
imsi：国际移动用户标识（imsi）[TS.3GPP.23.003]是一个与所有GSM（全球移动通信系统）和UMTS（通用移动通信系统）移动用户相关的标识符，长度在6到15位之间。
imei: The International Mobile Equipment Identifier (IMEI) [TS.3GPP.23.003] is a unique device serial number up to 15 digits long.
imei：国际移动设备标识符（imei）[TS.3GPP.23.003]是一个长达15位的唯一设备序列号。
min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a 10-digit unique number assigned to CDMA handsets.
min：移动识别号码（min）[TIA.EIA.IS-2000-6]是分配给CDMA手机的10位唯一号码。
mdn: The Mobile Directory Number (MDN) is an E.164 number [E.164], with usage similar to MSISDN.
mdn：移动目录号（mdn）是一个E.164号[E.164]，其用法类似于MSISDN。
Each identifier contains a string of decimal digits with a length as specified.
每个标识符包含指定长度的十进制数字字符串。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn>
</device>
The Dynamic Host Configuration Protocol (DHCP) uses a binary identifier for its clients. The DHCP Unique Identifier (DUID) is expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The "duid" element includes the binary value of the DUID expressed in hexadecimal.
动态主机配置协议（DHCP）为其客户端使用二进制标识符。DHCP唯一标识符（DUID）在DHCPv4的选项61（见[RFC4361]）或DHCPv6的选项1中表示，并遵循[RFC3315]第9节中定义的格式。“duid”元素包括以十六进制表示的duid的二进制值。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid>
</device>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid>
</device>
Location configuration protocols can make use of an authorization model known as "LCP policy", which permits only Targets to be the recipients of their own locations. In effect, an LCP server (that is, the LIS) follows a single-rule policy that states that the Target is the only authorized Location Recipient.
位置配置协议可以使用一种称为“LCP策略”的授权模型，该模型只允许目标成为其自身位置的接收者。实际上，LCP服务器（即LIS）遵循一个规则策略，该策略声明目标是唯一授权的位置收件人。
The security and privacy considerations of the base HELD protocol [RFC5985] are applicable. However, the considerations relating to return routability do not apply to third-party requests. Return routability may also not apply to requests from Targets for their own location, depending on the anti-spoofing mechanisms employed for the identifier.
基本保持协议[RFC5985]的安全性和隐私考虑是适用的。但是，与返回可路由性相关的考虑不适用于第三方请求。返回路由能力也可能不适用于目标对其自身位置的请求，这取决于标识符采用的反欺骗机制。
When a Target uses identity extensions to obtain its own location, HELD can no longer be considered an LCP. The authorization policy that the LIS uses to respond to these requests must be provisioned by one or more Rule Makers.
当目标使用标识扩展获取自己的位置时，HOLD不再被视为LCP。LIS用于响应这些请求的授权策略必须由一个或多个规则制定者提供。
In the case that the LIS exclusively provides Targets with their own locations, the LIS can still be said to be following the "LCP policy". The "LCP policy" concept and further security and privacy considerations can be found in [GEOPRIV-ARCH].
如果LIS专门为目标提供其自己的位置，则可以说LIS遵循“LCP政策”。[GEOPRIV-ARCH]中提供了“LCP政策”概念以及进一步的安全和隐私注意事项。
The spoofing protections provided when using HELD with identity extensions to provide Targets with their own locations differ from the protections inherent in an LCP. For an LCP, return routability is considered sufficient protection against spoofing. For a similar policy to be used, specific measures MUST be defined to protect against spoofing of the alternative identifier. This document defines this for an NAI when used in WiMAX networks (see Section 3.4.1), but for no other identifier.
使用带有身份扩展的HOLD为目标提供自己位置时提供的欺骗保护与LCP中固有的保护不同。对于LCP，返回路由能力被认为是防止欺骗的充分保护。对于要使用的类似策略，必须定义特定措施以防止替代标识符被欺骗。本文件定义了用于WiMAX网络的NAI（见第3.4.1节），但不包括其他标识符。
A Rule Maker might require an assurance that the identifier is owned by the requestor. Any multi-stage verification process that includes a return routability test cannot provide any stronger assurance than return routability alone; therefore, policy might require the use of additional, independent methods of verification.
规则制定者可能需要确保标识符为请求者所有。任何包括返回可路由性测试的多阶段验证过程不能提供比单独返回可路由性更强的保证；因此，政策可能需要使用其他独立的核查方法。
Care is required where a direct one-to-one relationship between requestor and Device identity does not exist. If identifiers are not uniquely attributable to a single Device, the use of HELD identity extensions to provide Targets with their own locations could be exploited by an attacker.
如果请求者和设备标识之间不存在直接的一对一关系，则需要小心。如果标识符不能唯一归属于单个设备，攻击者可能会利用持有的标识扩展为目标提供自己的位置。
It might be possible in some networks to establish multiple concurrent sessions using the same credentials. For instance, Devices with different MAC addresses might be granted concurrent access to a network using the same NAI. It is not appropriate to provide Targets with their own locations based on the NAI in this case. Neither is it appropriate to authenticate a Device using NAI and allow that Device to provide an unauthenticated MAC address as a Device identifier, even if the MAC address is
在某些网络中，可能会使用相同的凭据建立多个并发会话。例如，具有不同MAC地址的设备可能被授予使用相同NAI对网络的并发访问权。在这种情况下，根据NAI为目标提供自己的位置是不合适的。使用NAI对设备进行身份验证并允许该设备提供未经身份验证的MAC地址作为设备标识符也不合适，即使MAC地址是
registered to the NAI. The MAC address potentially identifies a different Device than the one that is making the request. The correct way of gaining authorization is to establish a policy that permits this particular request as a third-party request.
在NAI注册。MAC地址可能会识别与发出请求的设备不同的设备。获得授权的正确方法是建立一个策略，允许此特定请求作为第三方请求。
Section 3.4.1 discusses the implications of using an NAI as an identifier for location requests made of a LIS serving a WiMAX network. Additional security considerations are discussed in [WiMAX-T33-110-R015v01-B].
第3.4.1节讨论了将NAI用作服务于WiMAX网络的LIS的位置请求标识符的含义。[WiMAX-T33-110-R015v01-B]中讨论了其他安全注意事项。
The "LCP policy" does not allow requests made by third parties. If a LIS permits requests from third parties using Device identity, it assumes the rule of a Location Server (LS). As a Location Server, the LIS MUST explicitly authorize requests according to the policies that are provided by Rule Makers, including the Target. The LIS MUST also authenticate requestors according to any agreed-upon authorization policy.
“LCP政策”不允许第三方提出请求。如果LIS允许来自使用设备标识的第三方的请求，则采用位置服务器（LS）的规则。作为位置服务器，LIS必须根据规则制定者（包括目标）提供的策略明确授权请求。LIS还必须根据任何商定的授权策略对请求者进行身份验证。
An organization that provides a LIS that allows third-party requests must provide a means for a Rule Maker to specify authorization policies as part of the LIS implementation (e.g, in the form of access control lists). Authorization must be established before allowing third-party requests for the location of any Target. Until an authorization policy is established, the LIS MUST reject requests by third parties (that is, the default policy is "deny all").
提供允许第三方请求的LIS的组织必须为规则制定者提供指定授权策略的方法，作为LIS实施的一部分（例如，以访问控制列表的形式）。在允许第三方请求任何目标的位置之前，必须建立授权。在建立授权策略之前，LIS必须拒绝第三方的请求（即默认策略为“全部拒绝”）。
When the LIS is operated by an access network, the relationship between the Target and the LIS can be transient. As the Target is a potential Rule Maker, this presents a problem. However, the process of establishing network access usually results in a form of agreement between the Target and the network provider. This process offers a natural vehicle for establishing location privacy policies. Establishing authorization policy might be a manual process, an explicit part of the terms of service for the network, or an automated system that accepts formal authorization policies (see [RFC4745] and [RFC4825]). This document does not mandate any particular mechanism for establishing an authorization policy.
当LIS由接入网络操作时，目标和LIS之间的关系可能是暂时的。由于目标是潜在的规则制定者，这就产生了一个问题。然而，建立网络访问的过程通常会导致目标和网络提供商之间达成协议。这个过程为建立位置隐私策略提供了一个自然的工具。建立授权策略可能是一个手动过程、网络服务条款的明确部分或接受正式授权策略的自动化系统（请参见[RFC4745]和[RFC4825]）。本文件不强制要求建立授权策略的任何特定机制。
The security considerations in [RFC5985] describe the use of Transport Layer Security (TLS) [RFC5246] for server authentication, confidentiality, and protection from modification. These protections apply to both Target requests for their own locations and requests made by third parties.
[RFC5985]中的安全注意事项描述了使用传输层安全性（TLS）[RFC5246]进行服务器身份验证、保密和防止修改。这些保护既适用于目标公司对其自身位置的请求，也适用于第三方提出的请求。
All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy.
包含标识的所有保留请求必须由LIS进行身份验证。如何完成身份验证以及需要什么样的保证是策略的问题。
The base HELD protocol uses return reachability of an IP address implied by the requestor being able to successfully complete a TCP handshake. It is RECOMMENDED that any means of authentication provide at least this degree of assurance. For requests that include Device identity, the requestor MUST support HTTP digest authentication [RFC2617]. Unauthenticated location requests containing Device identity can be challenged with an HTTP 401 (Unauthorized) response or rejected with an HTTP 403 (Forbidden) response.
基本保持协议使用IP地址的返回可达性，该IP地址由能够成功完成TCP握手的请求者暗示。建议任何认证方式至少提供这种程度的保证。对于包含设备标识的请求，请求者必须支持HTTP摘要身份验证[RFC2617]。包含设备标识的未经身份验证的位置请求可以使用HTTP 401（未经授权）响应进行质询，也可以使用HTTP 403（禁止）响应进行拒绝。
HELD [RFC5985] does not mandate that Devices implement authentication. A LIS SHOULD NOT send a HTTP 401 response if the Device does not include Device identity.
HOLD[RFC5985]不要求设备实现身份验证。如果设备不包含设备标识，则LIS不应发送HTTP 401响应。
Transient and ambiguous identifiers can be exploited by malicious requests and are not suitable as a basis for identifying a Device. Section 2.1 provides further discussion on this subject.
临时和不明确的标识符可被恶意请求利用，不适合作为识别设备的基础。第2.1节提供了关于该主题的进一步讨论。
Identifier transience can lead to incorrect location information being provided. An attacker could exploit the use of transient identifiers. In this attack, the attacker either knows of a re-allocation of that identifier or is able to force the identifier to be re-allocated during the processing of the request.
标识符瞬变可能导致提供不正确的位置信息。攻击者可以利用瞬态标识符的使用进行攻击。在此攻击中，攻击者知道该标识符被重新分配，或者能够在处理请求期间强制重新分配该标识符。
An attacker could use this to acquire location information for another Device or to coerce the LIS to lie on its behalf if this re-allocation occurs between the time where authorization is granted and location information is granted.
如果此重新分配发生在授予授权和授予位置信息之间，则攻击者可利用此信息获取其他设备的位置信息，或强制LIS代表其进行分配。
Ambiguous identifiers present a similar problem. An attacker could legitimately gain authorization to use a particular identifier. Since an ambiguous identifier potentially refers to multiple Devices, if authorization is granted for one of those Devices, an attacker potentially gains access to location information for all of those Devices.
不明确的标识符也存在类似的问题。攻击者可以合法地获得使用特定标识符的授权。由于不明确的标识符可能涉及多个设备，因此，如果为其中一个设备授予了授权，则攻击者可能获得对所有这些设备的位置信息的访问权。
Requests made by a Device for its own location are covered by the same set of protections offered by HELD. These requests might be authorized under a policy similar to the "LCP policy" that permits a Target access to location information about itself.
设备对其自身位置的请求由HOLD提供的同一套保护覆盖。这些请求可以根据类似于“LCP策略”的策略进行授权，该策略允许目标访问有关其自身的位置信息。
Identity information provided by the Device is private data that might be sensitive. The Device provides this information in the expectation that it assists the LIS in providing the Device a service. The LIS MUST NOT use identity information for any other purpose other than serving the request that includes that information.
设备提供的身份信息是可能敏感的私有数据。设备提供此信息的目的是帮助LIS向设备提供服务。LIS不得将身份信息用于除服务包含该信息的请求之外的任何其他目的。
Requests from third parties have the same requirements for server authentication, confidentiality, and protection from modification as Target requests for their own locations. However, because the third party needs to be authorized, the requestor MUST be authenticated by the LIS. In addition, third-party requests MUST be explicitly authorized by a policy that is established by a Rule Maker.
来自第三方的请求对服务器身份验证、机密性和防止修改的要求与针对其自身位置的目标请求相同。但是，由于第三方需要授权，请求者必须由LIS进行身份验证。此外，第三方请求必须由规则制定者制定的策略明确授权。
More detail on the privacy implications of third-party requests are covered in Section 4.
有关第三方请求的隐私影响的更多详细信息，请参见第4节。
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6155.txt">
This document defines Device identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6155.txt">
This document defines Device identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
<xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="v" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="v" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/>
<xs:element name="sctpport" type="id:portNumber"/>
<xs:element name="dccpport" type="id:portNumber"/>
<xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/>
<xs:element name="sctpport" type="id:portNumber"/>
<xs:element name="dccpport" type="id:portNumber"/>
<xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType">
<xs:restriction base="xs:token">
<xs:pattern
value="([^\\]|\\[\dA-Fa-f]{2})*
(@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
[A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType">
<xs:restriction base="xs:token">
<xs:pattern
value="([^\\]|\\[\dA-Fa-f]{2})*
(@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
[A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="fqdn" type="xs:token"/>
<xs:element name="fqdn" type="xs:token"/>
<xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="e164">
<xs:restriction base="id:digit15">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit15">
<xs:restriction base="id:digits">
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit10">
<xs:restriction base="id:digits">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="e164">
<xs:restriction base="id:digit15">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit15">
<xs:restriction base="id:digits">
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit10">
<xs:restriction base="id:digits">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
This document registers an XML namespace and schema with IANA in accordance with guidelines in [RFC3688].
本文档根据[RFC3688]中的指南向IANA注册XML名称空间和模式。
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:geopriv:hold:id”。
URI: urn:ietf:params:xml:ns:geopriv:held:id
URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
注册人联系人：IETF、GEOPRIV工作组(geopriv@ietf.org)，詹姆斯·温特巴顿（詹姆斯。winterbottom@andrew.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 Device Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
RFC 6155</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Device Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
RFC 6155</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:schema:geopriv:held:id
URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
注册人联系人：IETF、GEOPRIV工作组(geopriv@ietf.org)，詹姆斯·温特巴顿（詹姆斯。winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of Section 6 of this document.
模式：此模式的XML可作为本文档第6节的全部内容找到。
This section registers the "badIdentifier" error code in the IANA maintained "HELD Error Codes" sub-registry of the "Geopriv HTTP Enabled Location Delivery (HELD) Parameters" registry.
本节在IANA维护的“Geopriv HTTP启用位置交付（保留）参数”注册表的“保留错误代码”子注册表中注册“BADDIDENTIFIER”错误代码。
badIdentifier This error code indicates that a Device identifier used in the HELD request was either: not supported by the LIS, badly formatted, or not one for which the requestor was authorized to make a request.
badIdentifier此错误代码表示保留请求中使用的设备标识符是：LIS不支持、格式不正确，或者不是请求者有权发出请求的设备标识符。
The National Emergency Number Association (NENA) VoIP location working group provided assistance in the definition of the schema used in this document. Special thanks go to Barbara Stark, Guy
国家紧急号码协会（NENA）VoIP位置工作组在定义本文件中使用的模式方面提供了帮助。特别感谢芭芭拉·斯塔克，伙计
Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for providing further corrections. Bernard Aboba provided excellent feedback on use cases and the security model; Bernard, along with Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis provided motivation for the protocol port parameters. Marc Linsner and Alissa Cooper provided guidance and text (respectively) that greatly clarified the discussion relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for forcing this to be practical.
卡伦、纳丁·阿伯特、杰罗姆·格雷尼尔和马丁·道森。Bob Sherry提供了有关URI使用的信息。感谢Adam Muhlbauer和Eddy Corbett提供的进一步更正。Bernard Aboba提供了关于用例和安全模型的优秀反馈；伯纳德和艾伦·德科克也帮助解决了与奈斯的一个问题。Ray Bellis为协议端口参数提供了动机。马克·林斯纳（Marc Linsner）和艾莉莎·库珀（Alissa Cooper）分别提供了指南和文本，极大地澄清了与LCP相关的讨论。多亏了乔恩·彼得森和卡伦·詹宁斯，让这一切变得切实可行。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[W3C.REC-xml-names11-20060816] Hollander, D., Tobin, R., Layman, A., and T. Bray, "Namespaces in XML 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[W3C.REC-xml-names11-20060816]Hollander，D.，Tobin，R.，Layman，A.，和T.Bray，“xml 1.1中的名称空间（第二版）”，万维网联盟建议REC-xml-names11-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802, February 2002.
[IEEE802]IEEE，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE 802，2002年2月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI64]IEEE，“64位全局标识符（EUI-64）注册机构指南”，1997年3月<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[E.164] ITU-T, "E.164 : The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005, <http://www.itu.int/rec/T-REC-E.164-200502-I/en>.
[E.164]ITU-T，“E.164：国际公共电信编号计划”，ITU-T建议E.164，2005年2月<http://www.itu.int/rec/T-REC-E.164-200502-I/en>.
[E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN)", ITU-T Recommendation E.213, November 1988, <http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
[E.213]ITU-T，“E.213：公共陆地移动网络（PLMN）中陆地移动站的电话和ISDN编号计划”，ITU-T建议E.213，1988年11月<http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
[TS.3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 9.4.0, September 2010, <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TS.3GPP.23.003]3GPP，“编号、寻址和标识”，3GPP TS 23.003 9.4.012010年9月<http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TIA.EIA.IS-2000-6] TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002.
[TIA.EIA.IS-2000-6]TIA/EIA，“CDMA 2000扩频系统的模拟信令标准”，TIA/EIA/IS-2000-6-C，2002年5月。
[WiMAX-T33-110-R015v01-B] WiMAX Forum, "Protocols and Procedures for Location Based Services", WiMAX Forum Network Architecture T33-110- R015v01-B, May 2009.
[WiMAX-T33-110-R015v01-B]WiMAX论坛，“基于位置服务的协议和程序”，WiMAX论坛网络架构T33-110-R015v01-B，2009年5月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]Carpenter，B.，Crowcroft，J.，和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年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月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745]Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，Polk，J.，和J.Rosenberg，“共同政策：表达隐私偏好的文件格式”，RFC 47452007年2月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776]Schulzrinne，H.，“Civic地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 4776，2006年11月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687]Tschofenig，H.和H.Schulzrinne，“GEOPRIV第7层位置配置协议：问题陈述和要求”，RFC 5687，2010年3月。
[GEOPRIV-ARCH] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", Work in Progress, October 2010.
[GEOPRIV-ARCH]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，正在进行的工作，2010年10月。
[EMERGENCY-CALLING] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, October 2010.
[紧急呼叫]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务的最佳当前实践”，正在进行的工作，2010年10月。
Authors' Addresses
作者地址
James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
James Winterbottom Andrew Corporation Andrew Building（39）卧龙岗大学校园北田大道，新南威尔士州卧龙岗2522 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
马丁·汤姆森·安德鲁公司安德鲁大厦（39）卧龙岗大学校园北田大道卧龙岗，新南威尔士州2522
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA
Richard Barnes BBN Technologies 9861 Breaked Land Pkwy，美国马里兰州哥伦比亚市400号套房21046
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com