Network Working Group J. Cuellar
Request for Comments: 3693 Siemens AG
Category: Informational J. Morris
Center for Democracy & Technology
D. Mulligan
Samuelson Law, Technology & Public Policy Clinic
J. Peterson
NeuStar
J. Polk
Cisco
February 2004
Network Working Group J. Cuellar
Request for Comments: 3693 Siemens AG
Category: Informational J. Morris
Center for Democracy & Technology
D. Mulligan
Samuelson Law, Technology & Public Policy Clinic
J. Peterson
NeuStar
J. Polk
Cisco
February 2004
Geopriv Requirements
地质驱动要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
基于位置的服务、导航应用、应急服务、现场设备管理和其他依赖位置的服务需要有关目标（如用户、资源或其他实体）的地理位置信息。需要为定位服务安全地收集和传输位置信息，同时保护相关个人的隐私。
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.
本文档重点介绍此类位置相关服务的授权、安全和隐私要求。具体而言，它描述了Geopriv定位对象（LO）和使用该定位对象的协议的要求。该LO被设想为所有Geopriv协议交换中用于安全传输位置数据的主要数据结构。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
Location-based services (applications that require geographic location information as input) are becoming increasingly common. The collection and transfer of location information about a particular Target can have important privacy implications. A key goal of the protocol described in this document is to facilitate the protection of privacy pursuant to Privacy Rules set by the "user/owner of the Target" (or, more precisely in the terminology of this document given in Section 3 and 5.4 below, the "Rule Maker").
基于位置的服务（需要地理位置信息作为输入的应用程序）正变得越来越普遍。收集和传输特定目标的位置信息可能会对隐私产生重要影响。本文件中所述协议的一个关键目标是根据“目标用户/所有者”（或者，更准确地说，根据下文第3节和第5.4节中给出的本文件术语，“规则制定者”）制定的隐私规则，促进隐私保护。
The ability to gather and generate a Target's location, and access to the derived or computed location, are key elements of the location-based services privacy equation. Central to a Target's privacy are (a) the identity of entities that have access to raw location data, derive or compute location, and/or have access to derived or computed location information, and (b) whether those entities can be trusted to know and follow the Privacy Rules of the user.
收集和生成目标位置的能力，以及对导出或计算位置的访问，是基于位置的服务隐私等式的关键要素。目标隐私的核心是（a）可访问原始位置数据、派生或计算位置和/或可访问派生或计算位置信息的实体的身份，以及（b）是否可以信任这些实体了解并遵守用户的隐私规则。
The main principles guiding the requirements described in this document are:
指导本文件所述要求的主要原则是：
1) Security of the transmission of Location Object is essential to guarantee the integrity and confidentiality of the location information. This includes authenticating the sender and receiver of the Location Object, and securing the Location Object itself.
1) 位置对象传输的安全性对于保证位置信息的完整性和机密性至关重要。这包括验证位置对象的发送方和接收方，以及保护位置对象本身。
2) A critical role is played by user-controlled Privacy Rules, which describe the restrictions imposed or permissions given by the "user" (or, as defined below, the "Rule Maker"). The Privacy Rules specify the necessary conditions that allow a Location Server to forward Location Information to a Location Recipient, and the conditions and purposes for which the Location Information can be used.
2) 用户控制的隐私规则起着关键作用，它描述了“用户”（或下文定义的“规则制定者”）施加的限制或授予的权限。隐私规则指定了允许位置服务器将位置信息转发给位置接收者的必要条件，以及可以使用位置信息的条件和目的。
3) One type of Privacy Rules specify how location information should be filtered, depending on who the recipient is. Filtering is the process of reducing the precision or resolution of the data. A typical rule may be of the form: "my location can only be disclosed to the owner of such credentials in such precision or resolution" (e.g., "my co-workers can be told the city I am currently in").
3) 一种类型的隐私规则指定如何过滤位置信息，具体取决于收件人是谁。过滤是降低数据精度或分辨率的过程。一个典型的规则可能是这样的：“我的位置只能以这样的精度或分辨率向此类凭证的所有者披露”（例如，“我的同事可以被告知我目前所在的城市”）。
4) The Location Object should be able to carry a limited but core set of Privacy Rules. The exact form or expressiveness of those Rules in the core set or in the full set is not further discussed in this document, but will be discussed more extensively in future documents produced by this working group.
4) 位置对象应该能够携带一组有限但核心的隐私规则。核心集或整套规则的确切形式或表达方式在本文件中未作进一步讨论，但将在本工作组今后编制的文件中作更广泛的讨论。
5) Whenever appropriate, the location information should not be linked to the real identity of the user or a static identifier easily linked back to the real identity of the user (i.e., Personally Identifiable Information such as a name, mailing address, phone number, social security number, or email address or username). Rather, the user should be able to specify which local identifier, unlinked pseudonym, or private identifier is to be bound to the location information.
5) 在适当情况下，位置信息不应链接到用户的真实身份或容易链接回用户真实身份的静态标识符（即，个人身份信息，如姓名、邮寄地址、电话号码、社会保险号码或电子邮件地址或用户名）。相反，用户应该能够指定将哪个本地标识符、未链接的笔名或私有标识符绑定到位置信息。
6) The user may want to hide the real identities of himself and his partners, not only to eavesdroppers but also to other entities participating in the protocol.
6) 用户可能想要隐藏自己及其合作伙伴的真实身份，不仅对窃听者，而且对参与协议的其他实体。
Although complete anonymity may not be appropriate for some applications because of legal constraints or because some location services may in fact need explicit identifications, most often the location services only need some type of authorization information and/or perhaps anonymous identifiers of the entities in question.
尽管由于法律限制或由于某些位置服务实际上可能需要明确的标识，完全匿名可能不适合于某些应用，但大多数情况下，位置服务只需要某种类型的授权信息和/或可能是所述实体的匿名标识符。
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]中所述进行解释。
Note that the requirements discussed here are requirements on the generic Location Object and on using protocols for location services. Thus, for the most part, the requirements discussed in this document refer to capabilities that are mandatory-to-implement. For example, requiring that implementations support integrity is not the same thing as requiring that all protocol traffic be authenticated. In contrast, an example of a mandatory-to-use (not just mandatory-to-implement) requirement might be one that states that the user always receives a notice when his location data was not authenticated. This practice is mandatory-to-use, not just to implement.
注意，这里讨论的需求是关于通用位置对象和使用位置服务协议的需求。因此，在大多数情况下，本文件中讨论的需求指的是强制实施的能力。例如，要求实现支持完整性与要求所有协议通信都经过身份验证是不同的。相比之下，强制使用（而不仅仅是强制实施）要求的一个示例可能是这样的，即当用户的位置数据未经身份验证时，用户总是收到通知。这种做法是必须使用的，而不仅仅是为了实施。
For easy reference and readability, below are basic terms that will be defined more formally and fully later in this document.
为了便于参考和阅读，以下是本文件后面将更正式、更全面地定义的基本术语。
Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing the location of the Target.
位置生成器（LG）：最初确定或收集目标位置并创建描述目标位置的位置对象的实体。
Location Object (LO): An object conveying location information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied.
位置对象（LO）：传递位置信息（可能还有隐私规则）的对象，Geopriv安全机制和隐私规则将应用于该对象。
Location Recipient (LR): The entity that receives location information. It may have asked for this location explicitly (by sending a query to a location server), or it may receive this location asynchronously.
位置接收者（LR）：接收位置信息的实体。它可能明确地请求了这个位置（通过向位置服务器发送查询），或者它可能异步地接收这个位置。
Location Server (LS): The entity to which a LG publishes location objects, the recipient of queries from location receivers, and the entity that applies rules designed by the rule maker.
位置服务器（LS）：LG向其发布位置对象的实体、位置接收者查询的接收者以及应用规则制定者设计的规则的实体。
Precision: The number of significant digits to which a value has been reliably measured.
精度：可靠测量值的有效位数。
Principal: The holder/subject of the credentials, e.g., a workstation user or a network server.
主体：凭证的持有者/主体，例如工作站用户或网络服务器。
Resolution: The fineness of detail that can be distinguished in a measured area. Applied to Geopriv this means the finite area within provided and closed borders (ex. Latitude and Longitude boundaries).
分辨率：在测量区域内可分辨的细节的精细度。适用于Geopriv，这意味着提供的封闭边界（例如纬度和经度边界）内的有限区域。
Rule Holder: The entity that provides the rules associated with a particular target for the distribution of location information. It may either 'push' rules to a location server, or a location server may 'pull' rules from the Rule Holder.
规则持有者：为分发位置信息提供与特定目标关联的规则的实体。它可以将规则“推”到位置服务器，或者位置服务器可以从规则持有者“拉”出规则。
Rule Maker: The authority that creates rules governing access to location information for a target (typically, this it the target themselves).
规则制定者：创建规则以管理对目标位置信息的访问的权限（通常，这是目标本身）。
Rule, or Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information.
规则或隐私规则：一项指令，用于规范实体在位置信息方面的活动，包括位置信息的收集、使用、披露和保留。
Target: A person or other entity whose location is communicated by a Geopriv Location Object.
目标：一个人或其他实体，其位置由Geopriv定位对象传达。
Using Protocol: A protocol that carries a Location Object.
使用协议：承载位置对象的协议。
Viewer: A Principal that consumes location information that is communicated by a Geopriv Location Object, but does not pass this information further.
查看器：一种主体，它使用Geopriv位置对象传递的位置信息，但不进一步传递该信息。
Resolution and Precision are very close terms. Either quality can be 'reduced' to coarsen location information: 'resolution' by defining a off-center perimeter around a user's location or otherwise enlarging the area in consideration (from state to country, say) and 'precision' by discarding significant digits of positioning information (rounding off longitude and latitude from seconds to minutes, say). Another WG document discusses this topic in much more detail.
分辨率和精度是非常接近的。任何一种质量都可以“降低”以粗化位置信息：“分辨率”是通过在用户位置周围定义一个偏离中心的周长来实现的，或者通过丢弃定位信息的有效数字来扩大所考虑的区域（比如从一个州到另一个国家）和“精度”（例如，将经度和纬度从秒舍入到分钟）。另一个工作组文档更详细地讨论了这个主题。
The following picture shows the primary Geopriv entities in a simple and basic architecture, without claim of completeness or any suggestion that the entities identified must in all cases be physically separate entities.
下图以简单和基本的体系结构显示了主要Geopriv实体，没有完整性声明，也没有任何迹象表明所识别的实体在所有情况下都必须是物理上独立的实体。
+----------+
| Rule |
| Holder |
| |
+----+-----+
|
rule|interface
V
+----------+ +----------+ +----------+
|Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | |
+----------+ +----------+ +----------+
+----------+
| Rule |
| Holder |
| |
+----+-----+
|
rule|interface
V
+----------+ +----------+ +----------+
|Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | |
+----------+ +----------+ +----------+
The four primary Entities are described as follows:
四个主要实体描述如下：
Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing that location. LGs publish Location Objects to Location Servers. The manner in which the Location Generator learns of Location Information is outside the scope of the Geopriv Protocol.
位置生成器（LG）：最初确定或收集目标位置并创建描述该位置的位置对象的实体。LGs将位置对象发布到位置服务器。位置生成器学习位置信息的方式不在Geopriv协议的范围内。
Location Server (LS): The LS is an element that receives publications of Location Objects from Location Generators and may receive subscriptions from Location Recipients. The LS applies the rules (which it learns from the Rule Holder) to LOs it receives from LGs, and then notifies LRs of resulting LOs as necessary.
位置服务器（LS）：LS是一个元素，它从位置生成器接收位置对象的发布，并可以从位置接收者接收订阅。LS将规则（从规则持有者处学习）应用于从LGs处收到的服务水平，然后在必要时通知LRs产生的服务水平。
Location Recipient (LR): The LR is an element that receives notifications of Location Objects from Location Servers. The LR may render these LOs to a user or automaton in some fashion.
位置接收者（LR）：LR是从位置服务器接收位置对象通知的元素。LR可以以某种方式将这些LO呈现给用户或自动机。
Rule Holder (RH): The RH is an element that houses Privacy Rules for receiving, filtering and distributing Location Objects for specific Targets. An LS may query an RH for a set of rules, or rules may be pushed from the RH to an LS. The rules in the Rule Holder are populated by the Rule Maker.
规则持有者（RH）：RH是一个包含隐私规则的元素，用于接收、过滤和分发特定目标的位置对象。LS可以向RH查询一组规则，也可以将规则从RH推送到LS。规则持有者中的规则由规则制定者填充。
Thus Location Generation is the process of gathering Location Information, perhaps from multiple sources, at an IP-based Geopriv Entity, the LG, which communicates with other Geopriv Entities.
因此，位置生成是在与其他Geopriv实体通信的基于IP的Geopriv实体LG处收集位置信息（可能来自多个来源）的过程。
Rules MUST be authenticated and protected. How this is done and in particular how to distribute the keys to the RM and other authorities is outside of the scope of this document. See also Section 8.2, "Securing the Privacy Rules".
规则必须经过身份验证和保护。如何做到这一点，特别是如何将密钥分发给RM和其他机构，不在本文档的范围之内。另见第8.2节“保护隐私规则”。
The interfaces between the Geopriv entities are not necessarily protocol interfaces; they could be internal interfaces within a single composed device. In some architectures, the Location Generator, Rule Holder, and Location Server might all be implemented in the same device. There may be several Rule Holders that enforce the Privacy Rules at a particular Location Server.
Geopriv实体之间的接口不一定是协议接口；它们可以是单个组合设备内的内部接口。在某些体系结构中，位置生成器、规则持有者和位置服务器可能都在同一个设备中实现。可能有多个规则持有者在特定位置服务器上实施隐私规则。
The terminology and definitions detailed below include both terms that, besides the primary Geopriv entities, (1) are used in the requirements section of this document, and (2) provide additional detail about the usage model envisioned for the Geopriv Location Object. These latter terms will be utilized in a separate scenarios document and elsewhere.
下文详述的术语和定义包括两个术语，除主要Geopriv实体外，（1）在本文件的要求部分中使用，（2）提供有关Geopriv定位对象预期使用模型的更多详细信息。后面这些术语将在单独的场景文档和其他地方使用。
The focus of the Geopriv working group is on information about a Target's location that is NOT based on generally or publicly available sources, but instead on private information provided or created by a Target, a Target's Device, or a Target's network or service provider. Notwithstanding this focus on private location information, the Geopriv Location Object could certainly be used to convey location information from publicly available sources.
Geopriv工作组的重点是关于目标位置的信息，这些信息不是基于一般或公开的来源，而是基于目标、目标设备或目标网络或服务提供商提供或创建的私人信息。尽管将重点放在私人位置信息上，Geopriv location对象当然可以用于传达来自公共可用来源的位置信息。
Location Information: A relatively specific way of describing where a Device is located.
位置信息：描述设备位置的相对具体的方式。
This Location Information may have been determined in many different ways, including:
该位置信息可能以多种不同的方式确定，包括：
(a) derived or computed from information generally not available to the general public (such as information mainly available to a network or service provider), (b) determined by a Device that may not be generally publicly addressable or accessible, or (c) input or otherwise provided by a Target.
(a) 从一般公众不可用的信息（如主要可供网络或服务提供商使用的信息）衍生或计算而来，（b）由一般不可公开寻址或访问的设备确定，或（c）输入或由目标提供的其他信息。
As examples, the Location Information could include (a) information calculated by triangulating on a wireless signal with respect to cell phone towers, (b) longitude and latitude information determined by a Device with GPS (global positioning satellite) capabilities, (c) information manually entered into a cell phone or laptop by a Target in response to a query, or (d) automatically delivered by some other IP protocol, such as at device configuration via DHCP.
作为示例，位置信息可以包括（a）通过对无线信号进行关于移动电话塔的三角剖分计算的信息，（b）由具有GPS（全球定位卫星）能力的设备确定的经度和纬度信息，（c）目标为响应查询而手动输入到手机或笔记本电脑中的信息，或（d）由某些其他IP协议（如通过DHCP进行的at设备配置）自动传递的信息。
Excluded from this definition is the determination of location information wholly without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available information such as an IP or e-mail address. In some cases, information like IP address can enable someone to estimate (at least roughly) a location. Commercial services exist that provide rough location information based on IP addresses. Currently, this type of location information is typically less precise than the type of location information addressed in this document. Although this type of location computation still raises significant potential privacy and public privacy concerns, such scenarios are generally outside the scope of this document.
本定义中不包括完全在目标公司（或目标公司的网络或接入服务提供商）不知情或不同意的情况下，根据IP或电子邮件地址等一般可用信息确定位置信息。在某些情况下，IP地址之类的信息可以让人估计（至少大致）一个位置。存在基于IP地址提供粗略位置信息的商业服务。目前，这种类型的位置信息通常不如本文档中所述类型的位置信息精确。尽管这种类型的位置计算仍然会引起重大的潜在隐私和公共隐私问题，但此类场景通常不在本文档的范围内。
Within any given location-based transaction, the INITIAL determination of location (and thus the initial creation of Location Information) is termed a Sighting:
在任何给定的基于位置的交易中，位置的初始确定（以及位置信息的初始创建）称为观测：
Sighting: The initial determination of location based on non-public information (as discussed in the definition of Location Information), and the initial creation of Location Information.
瞄准：根据非公开信息（如位置信息定义中所述）初步确定位置，并初步创建位置信息。
Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields:
定位对象中包含了一些不同的观察信息。抽象地说，它由两个独立的数据字段组成：
(Identifier, Location)
（标识符、位置）
where Identifier is the identifier assigned to a Target being sighted, and Location is the current position of that Target being sighted. Not all entities may have access to exactly the same piece of sighting information. A sighting may be transformed to a new sighting pair:
其中，标识符是分配给被观测目标的标识符，位置是被观测目标的当前位置。并非所有实体都可以访问完全相同的观测信息。瞄准可以转换为新的瞄准对：
(Identifier-1, Location-1)
（标识符-1，位置-1）
before it is provided by a Location Generator or Location Server to Location Recipient. In this case, Identifier-1 may be a Pseudonym, and Location-1 may have less precision or resolution than the original value.
由位置生成器或位置服务器提供给位置收件人之前。在这种情况下，标识符-1可以是假名，并且位置-1的精度或分辨率可能低于原始值。
A main goal of the Geopriv working group is to define a Location Object (LO), to be used to convey both Location Information and basic privacy-protecting instructions:
Geopriv工作组的主要目标是定义一个位置对象（LO），用于传递位置信息和基本隐私保护说明：
Location Object (LO): This data contains the Location Information of the Target, and other fields including an identity or pseudonym of the Target, time information, core Privacy Rules, authenticators, etc. Most of the fields are optional, including the Location Information itself.
位置对象（LO）：此数据包含目标的位置信息，以及其他字段，包括目标的身份或假名、时间信息、核心隐私规则、身份验证符等。大多数字段是可选的，包括位置信息本身。
Nothing is said about the semantics of a missing field. For instance, a partially filled object MAY be understood implicitly as a request to complete it. Or, if no time information is included, this MAY implicitly mean "at the current time" or "at a very recent time", but it could be interpreted in a different way, depending on the context.
对于缺少字段的语义，没有任何说明。例如，部分填充的对象可以隐式地理解为完成它的请求。或者，如果没有包括时间信息，这可能隐含地意味着“在当前时间”或“在最近的时间”，但可以根据上下文以不同的方式进行解释。
The "using protocol" is the protocol that uses (reads or modifies) the Location Object. A protocol that just transports the LO as a string of bits, without looking at them (like an IP storage protocol could do), is not a using protocol, but only a transport protocol. Nevertheless, the entity or protocol that caused the transport protocol to move the LO is responsible for the appropriate distribution, protection, usage, retention, and storage of the LO based on the rules that apply to that LO.
“使用协议”是使用（读取或修改）位置对象的协议。只将LO作为一串位传输而不查看它们（就像IP存储协议一样）的协议不是使用协议，而是传输协议。然而，导致传输协议移动LO的实体或协议负责根据适用于该LO的规则对LO进行适当的分发、保护、使用、保留和存储。
The security and privacy enhancing mechanisms used to protect the LO are of two types: First, the Location Object definition MUST include the fields or mechanisms used to secure the LO as such. The LO MAY be secured, for example, using cryptographic checksums or encryption as part of the LO itself. Second, the using protocol may also provide security mechanisms to securely transport the Location Object.
用于保护LO的安全和隐私增强机制有两种类型：首先，位置对象定义必须包括用于保护LO的字段或机制。例如，可以使用加密校验和或加密作为LO本身的一部分来保护LO。第二，使用协议还可以提供安全机制来安全地传输位置对象。
When defining the LO, the design should observe that the security mechanisms of the Location Object itself are to be preferred. Thus the definition of the LO MUST include some minimal crypto functionality (Req. 14 and 15). Moreover, if the RM specifies the use of a particular LO security mechanism, it MUST be used (Req. 4).
定义LO时，设计应注意位置对象本身的安全机制是首选的。因此，LO的定义必须包括一些最小的加密功能（要求14和15）。此外，如果RM指定使用特定的LO安全机制，则必须使用它（要求4）。
Location information can be used in very different environments. In some cases, the participants will have longstanding relationships, while in others the participants may have discrete interactions with no prior contractual or other contact.
位置信息可以在非常不同的环境中使用。在某些情况下，参与者将有长期的关系，而在其他情况下，参与者可能有离散的互动，没有事先的合同或其他接触。
The different relationships raise different concerns for the implementation of privacy rules, including the need to communicate Privacy Rules. A public Rule Holder, for example, may be unnecessary in a trusted environment where more efficient methods of addressing privacy issues exist. The following terms distinguish between the two basic types of data flows:
不同的关系对隐私规则的实施提出了不同的关注，包括交流隐私规则的需要。例如，在存在更有效的解决隐私问题的方法的可信环境中，公共规则持有者可能是不必要的。以下术语区分两种基本类型的数据流：
Trusted Data Flow: A data flow that is governed by a pre-existing contractual relationship that addresses location privacy.
受信任的数据流：由解决位置隐私的预先存在的契约关系管理的数据流。
Non-trusted Data Flow: The data flow is not governed by a pre-existing contractual relationship that addresses location privacy.
不受信任的数据流：数据流不受解决位置隐私问题的预先存在的合同关系管辖。
Target: The entity whose location is desired by the Location Recipient. In many cases the Target will be the human "user" of a Device or an object such as a vehicle or shipping container to which the Device is attached. In some instances the Target will be the Device itself.
目标：位置接收者需要其位置的实体。在许多情况下，目标将是装置或物体（如装置所连接的车辆或运输容器）的人类“用户”。在某些情况下，目标将是设备本身。
Device: The technical device whereby the location is tracked as a proxy for the location of a Target.
设备：一种技术设备，通过它可以跟踪目标的位置，作为目标位置的代理。
A Device might, for example, be a cell phone, a Global Positioning Satellite (GPS) receiver, a laptop equipped with a wireless access Device, or a transmitter that emits a signal that can be tracked or located. In some situations, such as when a Target manually inputs location information (perhaps with a web browser), the Target is effectively performing the function of a Device.
例如，设备可以是移动电话、全球定位卫星（GPS）接收器、配备有无线接入设备的膝上型电脑或发射可跟踪或定位信号的发射器。在某些情况下，例如当目标手动输入位置信息（可能使用web浏览器）时，目标有效地执行设备的功能。
Rule Maker (RM): The individual or entity that has the authorization to set the applicable Privacy Rules for a potential Geopriv Target. In many cases this will be the owner of the Device, and in other cases this may be the user who is in possession of the Device. For example, parents may control what happens to the location information derived from a child's cell phone. A company, in contrast, may own and provide a cell phone to an employee but permit the employee to set the privacy rules.
规则制定者（RM）：有权为潜在Geopriv目标设置适用隐私规则的个人或实体。在许多情况下，这将是设备的所有者，在其他情况下，这可能是拥有设备的用户。例如，父母可以控制从孩子手机中获取的位置信息的变化。相反，公司可能拥有并向员工提供手机，但允许员工设定隐私规则。
There are four scenarios in which some form of constraint or override might be placed on the Privacy Rules of the Rule Maker:
有四种情况可能会对规则制定者的隐私规则施加某种形式的约束或覆盖：
1. In the case of emergency services (such as E911 within the United States), local or national laws may require that accurate location information be transmitted in certain defined emergency call situations. The Geopriv Working Group MUST facilitate this situation.
1. 对于紧急服务（如美国境内的E911），当地或国家法律可能要求在特定的紧急呼叫情况下传输准确的位置信息。Geopriv工作组必须为这种情况提供便利。
2. In the case of legal interception, the RM may not be aware of an override directive imposed by a legal authority. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
2. 在合法拦截的情况下，RM可能不知道法律机构施加的覆盖指令。工作组并不期望为便利这种情况作出特别的让步。
3. In the context of an employment relationship or other contractual relationship, the owner of a particular location (such as a corporate campus) may impose constraints on the use of Privacy Rules by a Rule Maker. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
3. 在雇佣关系或其他合同关系的情况下，特定地点（如公司校园）的所有者可能会对规则制定者使用隐私规则施加限制。工作组并不期望为便利这种情况作出特别的让步。
4. It is conceivable that a governmental authority may seek to impose constraints on the use of Privacy Rules by a Rule Maker in non-emergency situations. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
4. 可以想象，政府当局可能会试图对规则制定者在非紧急情况下使用隐私规则施加限制。工作组并不期望为便利这种情况作出特别的让步。
Viewer: An individual or entity who receives location data about a Target and does not transmit the location information or information based on the Target's location (such as driving directions to or from the Target) to any party OTHER than the Target or the Rule Maker.
查看者：接收目标位置数据的个人或实体，不会将位置信息或基于目标位置的信息（如往返目标的行驶方向）发送给目标或规则制定者以外的任何一方。
Data Transporter: An entity or network that receives and forwards data without processing or altering it. A Data Transporter could theoretically be involved in almost any transmission between a Device and a Location Server, a Location Server and a second Location Server, or a Location Server and a Viewer. Some location tracking scenarios may not involve a Data Transporter.
数据传送者：在不处理或改变数据的情况下接收和转发数据的实体或网络。从理论上讲，数据传输器几乎可以参与设备与位置服务器、位置服务器与第二位置服务器或位置服务器与查看器之间的任何传输。某些位置跟踪场景可能不涉及数据传输。
Access Provider (AP): The domain that provides the initial network access or other data communications services essential for the operation of communications functions of the Device or computer equipment in which the Device operates. Often, the AP -- which will be a wireless carrier, an Internet Service Provider, or an internal corporate network -- contains the LG. Sometimes the AP has a "dumb" LG, one that transmits Geopriv LOs but does not use any part of the Geopriv Location Object. Other cases may not involve any AP, or the AP may only act as a Data Transporter.
接入提供商（AP）：提供初始网络接入或其他数据通信服务的域，对于设备或设备运行的计算机设备的通信功能的运行至关重要。通常，AP（无线运营商、互联网服务提供商或内部公司网络）包含LG。有时AP有一个“哑”LG，它传输Geopriv LOs，但不使用Geopriv定位对象的任何部分。其他情况可能不涉及任何AP，或者AP可能仅充当数据传输者。
Location Storage: A Device or entity that stores raw or processed Location Information, such as a database, for any period of time longer than the duration necessary to complete an immediate transaction regarding the Location Information.
位置存储：存储原始或处理过的位置信息（如数据库）的设备或实体，存储时间超过立即完成位置信息事务所需的时间。
The existence and data storage practices of Location Storage is crucial to privacy considerations, because this may influence what Location Information could eventually be revealed (through later distribution, technical breach, or legal processes).
位置存储的存在和数据存储实践对于隐私考虑至关重要，因为这可能会影响位置信息最终可能被披露的内容（通过以后的分发、技术违规或法律程序）。
Privacy Rules are rules that regulate an entity's activities with respect to location and other information, including, but not limited to, the collection, use, disclosure, and retention of location information. Such rules are generally based on fair information practices, as detailed in (for example) the OECD Guidelines on the Protection of Privacy and Transporter Flows of Personal Data [OECD].
隐私规则是规范实体在位置和其他信息方面活动的规则，包括但不限于位置信息的收集、使用、披露和保留。此类规则通常基于公平信息实践，如经合组织《个人数据隐私和传输流保护指南》[OECD]所述。
Privacy Rule: A rule or set of rules that regulate an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information. In particular, the Rule describes how location information may be used by an entity and which transformed location information may be released to which entities under which conditions. Rules must be obeyed; they are not advisory.
隐私规则：一条或一组规则，用于规范实体在位置信息方面的活动，包括位置信息的收集、使用、披露和保留。具体而言，该规则描述了实体如何使用位置信息，以及在何种条件下，哪些转换后的位置信息可以发布给哪些实体。必须遵守规则；它们不是咨询性的。
A full set of Privacy Rules will likely include both rules that have only one possible technical meaning, and rules that will be affected by a locality's prevailing laws and customs. For example, a distribution rule of the form "my location can only be disclosed to the owner of such credentials and in such precision or resolution" has clear-cut implications for the protocol that uses the LO. But other rules, like retention or usage Rules, may have unclear technical consequences for the protocol or for the involved entities. For example, the precise scope of a retention rule stating "you may not store my location for more than 2 days" may in part turn on local laws or customs.
一整套隐私规则可能既包括只有一种可能的技术含义的规则，也包括受当地现行法律和习俗影响的规则。例如，形式为“我的位置只能以这样的精度或分辨率披露给此类凭证的所有者”的分发规则对使用LO的协议具有明确的含义。但其他规则，如保留或使用规则，可能对协议或相关实体产生不明确的技术后果。例如，声明“您不得将我的位置存储超过2天”的保留规则的确切范围可能部分取决于当地法律或习俗。
Anonymity is the property of being not identifiable (within a set of subjects). Anonymity serves as the base case for privacy: without the ability to remain anonymous, individuals may be unable to control their own privacy. Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses to each other. Unlinkability requires that entities be unable to determine whether the same user caused certain specific operations in the system. [ISO99] A pseudonym is simply a bit string which is unique as an ID and is suitable to be used for end-point authentication.
匿名性是（在一组主题中）不可识别的属性。匿名性是隐私的基础：没有保持匿名的能力，个人可能无法控制自己的隐私。取消链接可确保用户可以多次使用资源或服务，而其他用户无法将这些使用相互链接。不可链接性要求实体无法确定是否是同一用户导致了系统中的某些特定操作。[ISO99]笔名只是一个作为ID唯一的位字符串，适合用于端点身份验证。
Unlinked Pseudonym: A pseudonym where the linking between the pseudonym and its holder is, at least initially, not known to anybody with the possible exception of the holder himself or a trusted server of the user. See [Pfi01] (there the term is called Initially Unlinked Pseudonym).
未链接的笔名：一种笔名，其中笔名与其持有者之间的链接至少在最初是不为任何人所知的，持有者本人或用户的可信服务器可能除外。参见[Pfi01]（此处术语最初称为未链接笔名）。
The word authentication is used in different manners. Some require that authentication associates an entity with a more or less well-known identity. This basically means that if A authenticates another entity B as being "id-B", then the label "id-B" is a well-known, or at least a linkable identity of the entity. In this case, the label "id-B" is called a publicly known identifier, and the authentication is "explicit":
“身份验证”一词有不同的用法。有些要求身份验证将实体与或多或少众所周知的标识相关联。这基本上意味着，如果A将另一实体B认证为“id-B”，则标签“id-B”是该实体的已知标识，或者至少是可链接标识。在这种情况下，标签“id-B”称为公知标识符，身份验证为“显式”：
Explicit Authentication: The act of verifying a claimed identity as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). Moreover, this identity is easily linked back to the real identity of the entity in question, for instance being a pre-existing static label from a predefined name space (telephone number, name, etc.)
显式身份验证：作为消息的唯一发起人（消息身份验证）或作为通道的端点（实体身份验证）验证声明的身份的行为。此外，该标识很容易链接回相关实体的真实标识，例如，是预定义名称空间（电话号码、名称等）中预先存在的静态标签
Authorization: The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential.
授权：确定是否可以将特定权限（如访问某些资源）授予特定凭证的演示者的行为。
Depending on the type of credential, authorization may or may not imply Explicit Authentication.
根据凭证的类型，授权可能意味着也可能不意味着显式身份验证。
In this subsection we introduce short scenarios to illustrate how these terms and attributes describe location information transactions. Additional illustrative scenarios are discussed in a separate document.
在本小节中，我们将介绍一些简短的场景来说明这些术语和属性如何描述位置信息事务。其他说明性场景将在单独的文档中讨论。
SCENARIO 1: GPS Device with Internal Computing Power: Closed System
场景1：具有内部计算能力的GPS设备：封闭系统
In this example, the Target wishes to know his/her location using the Global Positioning System (GPS) and the Device is capable of independently processing the raw data to determine its location. The location is derived as follows: the Device receives transmissions from the GPS satellites, internally computes and displays location. This is a closed system. For the purpose of this and subsequent examples, it is assumed that the GPS satellite broadcasts some signal, and has no information about the identity or whereabouts of Devices using the signal.
在此示例中，目标希望使用全球定位系统（GPS）知道他/她的位置，并且设备能够独立处理原始数据以确定其位置。位置推导如下：设备接收来自GPS卫星的传输，内部计算并显示位置。这是一个封闭的系统。为了本示例和后续示例的目的，假设GPS卫星广播一些信号，并且没有关于使用该信号的设备的身份或位置的信息。
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------
In this scenario the GPS Device is both the AP and the LG. The interaction occurs in a Trusted environment because it occurs in the Rule Maker's Device.
在这种情况下，GPS设备是AP和LG。交互发生在受信任的环境中，因为它发生在规则制定者的设备中。
SCENARIO 2: Cell Phone Roaming
场景2：手机漫游
In this example, a cell phone is used outside its home service area (roaming). Also, the cell phone service provider (cell phone Corp 2) outsourced the accounting of cell phone usage. The cell phone is not GPS-enabled. Location is derived by the cell phone network in which the Target and Device are roaming. When the Target wishes to use the cell phone, cell phone Corp 1 (AP) provides the roaming service for the Target, which sends the raw data about usage (e.g., duration of call, location in the roaming network, etc.) to cell phone Corp 2, the home service provider. Cell phone Corp 2 submits the raw data to the accounting company, which processes the raw data for the accounting statements. Finally, the raw data is sent to a data warehouse where the raw data is stored in a Location Server (e.g., computer server).
在此示例中，手机在其家庭服务区（漫游）之外使用。此外，手机服务提供商（手机公司2）将手机使用情况的核算外包。手机未启用GPS。位置由目标和设备漫游的移动电话网络导出。当目标希望使用手机时，手机公司1（AP）为目标提供漫游服务，该服务将有关使用情况的原始数据（例如，通话持续时间、漫游网络中的位置等）发送给家庭服务提供商手机公司2。手机公司2向会计公司提交原始数据，会计公司处理会计报表的原始数据。最后，原始数据被发送到数据仓库，其中原始数据存储在位置服务器（例如，计算机服务器）中。
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ /
----------------- / -----------------
/ |
/ | Notification
/ | Interface
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Recipient | | Recipient |
\ / \ /
------------- ----------
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ /
----------------- / -----------------
/ |
/ | Notification
/ | Interface
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Recipient | | Recipient |
\ / \ /
------------- ----------
Here, cell phone Corp 1 is the AP and the LG. In this scenario, Cell phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1 may be Non-trusted.
在这里，手机公司1是美联社和LG。在这种情况下，手机公司2可能是受信任的实体，但手机公司1可能是不受信任的实体。
SCENARIO 3: Mobile Communities and Location-Based Services
场景3：移动社区和基于位置的服务
The figure below shows a common scenario, where a user wants to find
his friends or colleagues or wants to share his position with them or
with a Location-Based Service Provider. Some of the messages use a
Location Object to carry, for instance, identities or pseudonyms,
credentials and proof-of-possession of them, Rules and Location Data
Information, including Data Types and Precision or Resolution.
Messages that do not use the Location Object and are outside of the
scope of the Geopriv WG, but should be mentioned for
understandability, are shown in the figure as starred arrows
("***>").
The figure below shows a common scenario, where a user wants to find
his friends or colleagues or wants to share his position with them or
with a Location-Based Service Provider. Some of the messages use a
Location Object to carry, for instance, identities or pseudonyms,
credentials and proof-of-possession of them, Rules and Location Data
Information, including Data Types and Precision or Resolution.
Messages that do not use the Location Object and are outside of the
scope of the Geopriv WG, but should be mentioned for
understandability, are shown in the figure as starred arrows
("***>").
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+
Assume that the Rule Maker and the Target are registered with the Location Server. The RM has somehow proven to the LS that he indeed is the owner of the privacy rights of the Target (the Target is usually a Device owned by the Rule Maker). The Rule Maker and the Location Server have agreed on the set of keys or credentials and cryptographic material that they will use to authenticate each other,
假设规则制定者和目标已向位置服务器注册。RM以某种方式向LS证明，他确实是目标公司隐私权的所有者（目标公司通常是规则制定者拥有的设备）。规则制定者和位置服务器已就用于相互验证的密钥或凭据以及加密材料集达成一致，
and in particular, to authenticate or sign the Rules. How this has been done is outside of the scope of the document.
特别是认证或签署规则。如何做到这一点超出了本文件的范围。
1: Rule Transfer: The Rule Maker sends a Rule to the Location Server. This Rule may or may not be a field in a Location Object.
1：规则传输：规则制定者向位置服务器发送规则。此规则可能是位置对象中的字段，也可能不是。
1a:Signed Rule: As an alternative, the Rule Maker may write a Rule and place it in a Public Rule Holder. The entities access the repository to read the signed Rules.
1a：签署规则：作为替代方案，规则制定者可以编写规则并将其放置在公共规则持有者中。实体访问存储库以读取已签名的规则。
2: Location Information Request: The Location Recipient requests location information for a Target. In this request, the Location Recipient may select which location information data type it prefers. One way of requesting Location Information MAY be sending a partially filled Location Object, including only the identities of the Target and Location Recipient and the desired Data Type and precision or resolution, and providing proof of possession of the required credentials. But whether or not the using protocol understands this partially filled object as a request MAY depend on the using protocol or on the context. The Location Recipient could also specify the need for periodic location information updates, but this is probably out of the scope of Geopriv.
2：位置信息请求：位置收件人请求目标的位置信息。在此请求中，位置收件人可以选择其首选的位置信息数据类型。请求位置信息的一种方法可以是发送部分填充的位置对象，仅包括目标和位置接收者的身份以及所需的数据类型和精度或分辨率，并提供拥有所需凭证的证明。但是，使用协议是否将这个部分填充的对象理解为请求可能取决于使用协议或上下文。位置接收者还可以指定定期更新位置信息的需要，但这可能超出Geopriv的范围。
3: Locate: When a Location Server receives a Location Information Request for a Target which has no current location information, the server may ask the Location Generator to locate the Target.
3：定位：当位置服务器收到没有当前位置信息的目标的位置信息请求时，服务器可能会要求位置生成器定位目标。
4: Location Information: The Location Generator sends the "full" location information to the Location Server. This Location Information may or may not be embedded in a Location Object.
4：位置信息：位置生成器将“完整”位置信息发送到位置服务器。此位置信息可以嵌入位置对象，也可以不嵌入位置对象。
5: Filtered Location Information: The Location Server sends the location information to the Location Recipient. The information may be filtered in the sense that in general a less precise or a computed version of the information is being delivered.
5：过滤的位置信息：位置服务器将位置信息发送给位置收件人。信息可以在以下意义上被过滤：通常，信息的不精确或计算版本正在被传递。
Remember that this document is primarily specifying requirements on the definition of the LO. Some Requirements read like this: "The LO definition MUST contain Field 'A' as an optional field." This requirement states that
请记住，本文件主要规定了LO定义的要求。有些要求是这样的：“LO定义必须包含字段‘A’作为可选字段。”该要求说明
o the document that defines the LO MUST define the LO field 'A',
o 定义LO的文档必须定义LO字段“A”，
o the field 'A' MUST be defined as optional to use (an instance of a LO MAY or may not contain the field 'A').
o 必须将字段“A”定义为可选使用（LO实例可能包含也可能不包含字段“A”）。
Some Requirements read like this: "The LO definition MUST contain Field 'A', which MAY be an optional field." This requirement states that
有些要求是这样的：“LO定义必须包含字段‘A’，这可能是一个可选字段。”该要求说明
o the document that defines the LO MUST define the LO field 'A',
o 定义LO的文档必须定义LO字段“A”，
o the field 'A' MAY be defined as optional or not to use. If it is defined as optional to use, any instance of an LO MAY or may not contain the field 'A'; if it is not optional, all instances of LOs MUST contain the field 'A'.
o 字段“A”可以定义为可选或不使用。如果定义为可选，则LO的任何实例都可能包含或不包含字段“A”；如果不是可选的，则所有LOs实例必须包含字段“A”。
Req. 1. (Location Object generalities)
请求。1.（位置对象概述）
1.1) Geopriv MUST define one Location Object (LO) -- both in syntax and semantics -- that must be supported by all Geopriv entities.
1.1）Geopriv必须定义一个位置对象（LO）——语法和语义都必须由所有Geopriv实体支持。
1.2) Some fields of the Location Object MAY be optional. This means that an instance of a Location Object MAY or may not contain the fields.
1.2）位置对象的某些字段可能是可选的。这意味着位置对象的实例可能包含字段，也可能不包含字段。
1.3) Some fields of the Location Object MAY be defined as "extensions". This means that the syntax or semantics of these fields is not fully defined in the basic Location Object definition, but their use may be private to one or more of the using protocols.
1.3）位置对象的某些字段可以定义为“扩展”。这意味着这些字段的语法或语义在基本位置对象定义中没有完全定义，但它们的使用可能是一个或多个使用协议的专用。
1.4) The Location Object MUST be extensible, allowing the definition of new attributes or fields.
1.4）位置对象必须是可扩展的，允许定义新的属性或字段。
1.5) The object MUST be suitable for requesting and receiving a location.
1.5）对象必须适合请求和接收位置。
1.6) The object MUST permit (but not require) the Privacy Rules to be enforced by a third party.
1.6）对象必须允许（但不要求）第三方执行隐私规则。
1.7) The object MUST be usable in a variety of protocols, such as HTTP and SIP, as well as local APIs.
1.7）该对象必须在各种协议（如HTTP和SIP）以及本地API中可用。
1.8) The object MUST be usable in a secure manner even by applications on constrained devices.
1.8）即使是受约束设备上的应用程序，对象也必须以安全的方式可用。
Req. 2. (Location Object fields) The Location Object definition MUST contain the following Fields, which MAY be optional to use:
请求。2.（位置对象字段）位置对象定义必须包含以下字段，可以选择使用这些字段：
2.1) Target Identifier
2.1）目标标识符
2.2) Location Recipient Identity This identity may be a multicast or group identity, used to include the Location Object in multicast-based using protocols.
2.2）位置接收者标识此标识可以是多播或组标识，用于使用协议在多播中包括位置对象。
2.3) Location Recipient Credential
2.3）位置收件人凭证
2.4) Location Recipient Proof-of-Possession of the Credential
2.4）地点接收人持有凭证的证明
2.5) Location Field
2.5）位置字段
2.5.1) Motion and direction vectors. This field MUST be optional.
2.5.1）运动和方向矢量。此字段必须是可选的。
2.6) Location Data Type
2.6）位置数据类型
When transmitting the Location Object, the sender and the receiver must agree on the data type of the location information. The using protocol may specify that the data type information is part of the Location Object or that the sender and receiver have agreed on it before the actual data transfer.
发送位置对象时，发送方和接收方必须就位置信息的数据类型达成一致。使用协议可以指定数据类型信息是位置对象的一部分，或者在实际数据传输之前发送方和接收方已经同意了该信息。
2.7) Timing information: (a) When was the Location Information accurate? (sighting time) (b) Until when considered current? TTL (Time-to-live) (This is different than a privacy rule setting a limit on data retention)
2.7）时间信息：（a）位置信息何时准确？（观察时间）（b）直到被认为是最新的？TTL（生存时间）（这与设置数据保留限制的隐私规则不同）
2.8) Rule Field: this field MAY be a referral to an applicable Rule (for instance, a URI to a full Rule), or it MAY contain a Limited Rule (see Req. 11), or both.
2.8）规则字段：该字段可能是对适用规则的引用（例如，完整规则的URI），也可能包含有限规则（请参见Req.11），或两者兼而有之。
2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15).
2.9）安全头和尾（例如加密信息、哈希或签名）（见要求14和15）。
2.10) Version number
2.10）版本号
Req. 3. (Location Data Types)
请求。3.（位置数据类型）
3.1) The Location Object MUST define at least one Location Data Type to be supported by all Geopriv receivers (entities that receive LOs).
3.1）位置对象必须定义至少一种位置数据类型，以供所有Geopriv接收器（接收服务水平的实体）支持。
3.2) The Location Object SHOULD define two Location Data Types: one for latitude / longitude / altitude coordinates and one for civil locations (City, Street, Number) supported by all Geopriv receivers (entities that receive LOs).
3.2）位置对象应定义两种位置数据类型：一种用于纬度/经度/高度坐标，另一种用于所有Geopriv接收器（接收服务水平的实体）支持的民用位置（城市、街道、编号）。
3.3) The latitude / longitude / altitude Data Type SHOULD also support a delta format in addition to an absolute one, used for the purpose of reducing the size of the packages or the security and confidentiality needs.
3.3）纬度/经度/海拔数据类型除支持绝对格式外，还应支持增量格式，用于减小包的大小或安全和保密需求。
3.4) The Location Object definition SHOULD agree on further Location Data Types supported by some Geopriv entities and defined by other organizations.
3.4）位置对象定义应就一些Geopriv实体支持并由其他组织定义的其他位置数据类型达成一致。
Req. 4. The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO.
请求。4.使用协议必须遵守位置对象中编码的隐私和安全说明以及与LO传输和存储相关的相应规则。
Req. 5. The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol.
请求。5.使用协议通常将有助于将与凭证相关联的密钥传输到各当事方，即，密钥建立是使用协议的责任。
Req. 6. (Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction.
请求。6.（单一消息传输）特别是，对于跟踪小型目标设备，设计应允许将位置的单一消息/数据包传输作为完整事务。
Other requirements on the using protocol are out of the scope of this document, but might be the subject of future efforts from this working group. See also Section 9 (Protocol and LO Issues for later Consideration).
关于使用协议的其他要求不在本文件范围内，但可能是本工作组未来工作的主题。另见第9节（协议和LO问题，以供以后考虑）。
Req. 7. (LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules.
请求。7.（LS规则）位置服务器提供位置收件人访问位置信息的决定必须基于规则制定者定义的隐私规则。
It is outside of our scope how Privacy Rules are managed and how a Location Server has access to the Privacy Rules. Note that it might be that some rules contain private information not intended for untrusted parties.
如何管理隐私规则以及位置服务器如何访问隐私规则超出了我们的范围。请注意，有些规则可能包含不适用于不受信任方的私人信息。
Req. 8. (LG Rules) Even if a Location Generator is unaware of and lacks access to the full Privacy Rules defined by the Rule Maker, the Location Generator MUST transmit Location Information in compliance with instructions set by the Rule Maker. Such compliance MAY be accomplished by the Location Generator transmitting the LO only to a URI designated by the Rule Maker.
请求。8.（LG规则）即使位置生成器不知道并无法访问规则制定者定义的完整隐私规则，位置生成器也必须按照规则制定者设置的说明传输位置信息。这种遵从性可以通过位置生成器仅将LO发送到规则制定者指定的URI来实现。
Req. 9. (Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained).
请求。9（查看者规则）查看者不需要知道规则制定者定义的完整规则（因为查看者不应重新传输位置信息），因此，查看者只应收到查看者按照完整隐私规则处理LO所需的隐私规则子集（例如，关于可保留LO的时间段的指示）。
Req. 10. (Full Rule language) Geopriv MAY specify a Rule language capable of expressing a wide range of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language, and it SHOULD be as simple as possible.
请求。10（完整规则语言）Geopriv可以指定一种规则语言，该语言能够表达与位置信息有关的广泛隐私规则。此规则语言可以是现有的、现有规则语言的改编或新规则语言，并且应尽可能简单。
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule language capable of expressing a limited set of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language. The Location Object MUST include sufficient fields and data to express the limited set of privacy rules.
请求。11（有限规则语言）Geopriv必须指定一种有限规则语言，能够表达与位置信息有关的有限隐私规则集。此规则语言可以是现有规则语言、现有规则语言的改编或新规则语言。Location对象必须包含足够的字段和数据来表示有限的隐私规则集。
Req. 12. (Identity Protection) The Location Object MUST support use of Unlinked Pseudonyms in the corresponding identification fields of Rule Maker, Target, Device, and Location Recipient. Since Unlinked Pseudonyms are simply bit strings that are not linked initially to a well-known identity, this requirement boils down to saying that the name space for Identifiers used in the LO has to be large enough to contain many unused strings.
请求。12（身份保护）位置对象必须支持在规则制定者、目标、设备和位置接收者的相应标识字段中使用未链接的假名。由于未链接的假名只是最初未链接到已知标识的位字符串，因此此要求归结为LO中使用的标识符的名称空间必须足够大，以包含许多未使用的字符串。
Req. 13. (Credential Requirements) The using protocol and the Location Object SHOULD allow the use of different credential types, including privacy-enhancing credentials (for instance those described in [Bra00] or [Cha85]).
请求。13（凭证要求）使用协议和位置对象应允许使用不同的凭证类型，包括隐私增强凭证（例如[Bra00]或[Cha85]中所述的凭证）。
Req. 14. (Security Features) The Location Object MUST support fields suitable for protecting the Object to provide the following security features:
请求。14（安全功能）位置对象必须支持适合保护对象的字段，以提供以下安全功能：
14.1) Mutual end-point authentication: the using protocol is able to authenticate both parties in a Location Object transmission,
14.1）相互端点认证：使用协议能够对位置对象传输中的双方进行认证，
14.2) Data object integrity: the LO is secured from modification by unauthorized entities during transmission and storage,
14.2）数据对象完整性：LO在传输和存储期间不会被未经授权的实体修改，
14.3) Data object confidentiality: the LO is secured from eavesdropping (unauthorized reading) during transmission and storage, and
14.3）数据对象机密性：LO在传输和存储期间不会被窃听（未经授权的读取），以及
14.4) Replay protection: an old LO may not be replayed by an adversary or by the same entity that used the LO itself (except perhaps during a small window of time that is configurable or accepted by the Rule Maker).
14.4）重放保护：对手或使用LO本身的同一实体不得重放旧LO（可能在规则制定者可配置或接受的小时间窗内除外）。
Req. 15. (Minimal Crypto)
请求。15（最小加密）
15.1) Geopriv MUST specify a minimum mandatory to implement Location Object security, including mandatory to implement crypto algorithms for digital signature algorithms and encryption algorithms.
15.1）Geopriv必须规定实施位置对象安全的最低强制性要求，包括实施数字签名算法和加密算法的加密算法的强制性要求。
15.2) It MAY also define further mandatory to implement Location Object security mechanisms for message authentication codes (MACs) or other purposes.
15.2）它还可以定义进一步的强制要求，以实现用于消息身份验证码（MAC）或其他目的的位置对象安全机制。
15.3) The protocol SHOULD allow a bypass if authentication fails in an emergency call.
15.3）如果紧急呼叫中身份验证失败，协议应允许旁路。
The issue addressed in the last point is that an emergency call in some unfavorable situations may not be completed if the minimal authentication fails. This is probably not what the user would like to happen. The user may prefer an unauthenticated call to an
最后一点讨论的问题是，如果最小身份验证失败，在某些不利情况下的紧急呼叫可能无法完成。这可能不是用户希望发生的事情。用户可能更喜欢未经验证的呼叫，而不是
unauthenticated emergency server over no call completion at all, even at the risk that he is talking to an attacker or that his information is not secured.
未经验证的紧急服务器完全没有呼叫完成，即使他正在与攻击者通话或他的信息不安全。
Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
不需要。1.（桥接至非IP网络）Geopriv规范不应规定桥接至非IP网络（PSTN等）。
The purpose of the Geopriv Location Object and the requirements on the using protocol are to allow a Privacy Rule-controlled disclosure of location information for location services.
Geopriv定位对象的目的和使用协议的要求是允许隐私规则控制位置服务位置信息的披露。
The information carried within the Location Object is secured in a way compliant with the privacy and security Rules of the Rule Maker, but other information, carried in other objects or headers are in general not secured in the same way. This means that Geopriv may not as a general matter, secure the Target against general traffic analysis attacks or other forms of privacy violations.
位置对象中携带的信息以符合规则制定者的隐私和安全规则的方式进行保护，但其他对象或标题中携带的其他信息通常不以相同的方式进行保护。这意味着Geopriv不能作为一般事项保护目标免受一般流量分析攻击或其他形式的隐私侵犯。
The Privacy Rules of the Rule Maker regarding the location of the Target may be accessible to a Location Server in a public or non-public Rule Holder, or they may be carried by the Location Object, or they may be presented by the Location Recipient as capabilities or tokens. Each type of Rule has to be secured its own particular way.
关于目标位置的规则制定者的隐私规则可以由公共或非公共规则持有者中的位置服务器访问，或者可以由位置对象携带，或者可以由位置接收者作为功能或令牌呈现。每种类型的规则都必须以其特定的方式加以保护。
The rules in a non-public Rule Holder are typically authenticated using a MAC (Message Authentication Code) or a signature, depending on the type of keys used. The rules in a public Rule Holder (one that in principle may be accessed directly by several entities, for instance several Location Servers) are typically digitally signed. Rule Fields in an LO are secured as part of the LO itself. A Geopriv Token (a token or ticket issued by the Rule Maker to a Location Recipient, expressing the explicit consent of the Rule Maker to access his location information) is authenticated or signed.
非公共规则持有者中的规则通常使用MAC（消息身份验证码）或签名进行身份验证，具体取决于使用的密钥类型。公共规则持有者中的规则（原则上可由多个实体（例如多个位置服务器）直接访问的规则）通常是数字签名的。LO中的规则字段作为LO本身的一部分进行保护。Geopriv令牌（规则制定者向位置接收者颁发的令牌或票据，表示规则制定者明确同意访问其位置信息）经过身份验证或签名。
Let us consider the situation where the authentication fails in an emergency call because the authentication center fails to authenticate itself. In this case, one way of implementing the
让我们考虑急诊科呼叫认证失败的情况，因为认证中心无法验证自己。在这种情况下，实现
authentication bypass for emergency calls (mentioned in Req 15.3) is to let the user have the choice of writing a Rule that says:
紧急呼叫的认证旁路（在Req 15.3中提到）是让用户可以选择编写一条规则，该规则说明：
- "If the emergency server does not authenticate itself, send the location information anyway", or
- “如果紧急服务器未进行自身身份验证，请发送位置信息”，或
- "If the emergency server does not authenticate itself, let the call fail".
- “如果紧急服务器未进行自身身份验证，则让呼叫失败”。
Second, in the case where the authentication of the emergency call fails because the user may not authenticate itself, the question arises: whose Rule to use? It is reasonable to use a default one: this location information can only be sent to an emergency center.
第二，如果紧急呼叫的身份验证失败，因为用户可能无法对自己进行身份验证，那么问题就出现了：使用谁的规则？使用默认位置是合理的：此位置信息只能发送到急救中心。
The third situation, which should be studied in more detail, is: what to do if not only the user fails to authenticate itself, but also the emergency center is not authenticable? It is reasonable to send the Location Information anyway, but are there any security threats that must be considered?
第三种情况需要更详细地研究：如果不仅用户无法对自己进行身份验证，而且急救中心也无法进行身份验证，该怎么办？无论如何，发送位置信息是合理的，但是否存在任何必须考虑的安全威胁？
The use of Unlinked Pseudonyms is necessary to obtain anonymity.
为了获得匿名性，必须使用未链接的笔名。
The purpose of the use of Unlinked Pseudonyms is the following: the using protocol should be able to hide the real identity of the Rule Maker, the Target, and the Device, from Location Servers or Location Recipients, if required by the RM. Also, the using protocol SHOULD be able to hide the real identity of the Location Recipient from the Location Server.
使用未链接笔名的目的如下：如果RM要求，使用协议应能够对位置服务器或位置收件人隐藏规则制定者、目标和设备的真实身份。此外，使用协议应该能够向位置服务器隐藏位置收件人的真实身份。
In this last case, the Target is not concerned about the Server identifying him and knowing his location, but identifying his business partners, and therefore his habits, etc. Reasons for hiding the real identities of the Location Recipients include (a) that this knowledge may be used to infer the identity of the Target, (b) that knowledge of the identity of the Location Recipient may embarrass the Target or breach confidential information, and (c) that the dossier telling who has obtained a Target's location information over a long period of time can give information on habits, movements, etc. Even if the location service providers agree to respect the privacy of the user, are compelled by laws or regulations to protect the privacy of the user, and misbehavior or negligence of the Location Server can be ruled out, there is still risk that personal data may become available to unauthorized persons through attacks from outsiders, unauthorized access from insiders, technical or human errors, or legal processes.
在最后一种情况下，目标不关心服务器识别他和知道他的位置，而是识别他的业务合作伙伴，因此也不关心他的习惯等。隐藏位置接收者真实身份的原因包括（a）该知识可用于推断目标的身份，（b）知道位置接收者的身份可能会使目标尴尬或违反保密信息，以及（c）告知长期获得目标位置信息的人的档案可以提供有关习惯、动作、行为的信息，等。即使位置服务提供商同意尊重用户的隐私，法律或法规强制保护用户的隐私，并且可以排除位置服务器的不当行为或疏忽，但仍然存在个人数据可能通过外部攻击提供给未经授权人员的风险，内部人员未经授权的访问、技术或人为错误或法律程序。
On some occasions, a Location Server has to know who is supplying the Privacy Rules for a particular Target, while in other situations it could be enough to know that the supplier of the Rules is authorized to do so.
在某些情况下，位置服务器必须知道谁在为特定目标提供隐私规则，而在其他情况下，只要知道规则的供应商有权这样做就足够了。
An Unintended Target is a person or object tracked by proximity to the Target. This special case most frequently occurs if the Target is not a person. For example, the Target may be a rental car equipped with a GPS Device, used to track car inventory. The rental company may not care about the driver's location, but the driver's privacy is implicitly affected.
非预期目标是通过接近目标跟踪的人或物体。如果目标不是个人，则最常发生这种特殊情况。例如，目标可能是配备GPS设备的租赁汽车，用于跟踪汽车库存。租赁公司可能不关心司机的位置，但司机的隐私会受到间接影响。
Geopriv may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged.
Geopriv可能会也可能不会保护或影响非预期目标的隐私，但应承认对非预期目标的影响。
This section briefly discusses issues relating to the Location Object or the protocol that have emerged during the discussion of earlier versions of this document.
本节简要讨论在讨论本文档早期版本时出现的与位置对象或协议相关的问题。
A location Field is intended to represent one point or one region in space (either 1, 2, or 3 dimensionally). The possibility of inclusion of multiple locations is discussed in another document. The current rough consensus is the following: the LO definition MAY allow the Location Field to be optional, to appear exactly one time or to occur several times. Each Location Field may contain one or more "Location Representations", each of which is intended to represent a different measurement or a different formatting of the same position. But there are other possibilities for using multiple Location Fields and multiple representations: maybe several Location Fields would be used to report the same sighting in different formats, or multiple sightings at different times, or multiple sensor locations for the same device, or other purposes, which could also depend on the using protocol. This is all for further discussion.
位置字段用于表示空间中的一个点或一个区域（1、2或3维）。在另一份文件中讨论了包含多个位置的可能性。目前的大致共识如下：LO定义可能允许位置字段是可选的，只出现一次或出现几次。每个位置字段可能包含一个或多个“位置表示”，每个“位置表示”旨在表示同一位置的不同测量值或不同格式。但使用多个位置字段和多个表示还有其他可能性：可能会使用多个位置字段以不同格式报告相同的观测，或在不同时间报告多个观测，或为同一设备报告多个传感器位置，或出于其他目的，这也可能取决于使用协议。这些都有待进一步讨论。
It is possible to include fields to indicate that one of the locations is a translation of another. If this is done, it is also possible to have a field to identify the translator, as identity and method.
可以包括字段以指示其中一个位置是另一个位置的翻译。如果这样做了，还可以有一个字段来标识翻译人员，如身份和方法。
Geopriv MUST be silent on the truth or lack-of-truth of the location information contained in the LO. Thus, the LO MUST NOT provide an attribute in object saying "I am (or am not) telling you the whole truth."
Geopriv必须对LO中包含的位置信息的真实性或缺乏真实性保持沉默。因此，LO不能在对象中提供一个属性，表示“我正在（或没有）告诉你全部真相。”
The format of timing information is out of the scope of this document.
定时信息的格式不在本文档的范围内。
Who defines the Identities: can the using protocol define the Identifiers or must the using protocol use and authenticate Pseudonyms proposed by the Rules, chosen independently of the using protocol? Of course, if the using protocol has an appropriate namespace, containing many unused names that may be used as pseudonyms and may be replaced by new ones regularly, then the Location Object may be able to use the name space. For this purpose, the user would probably have to write his Rules using this name space. Note that it is necessary to change the used pseudonyms regularly, because identifying the user behind an unlinked pseudonym can be very simple.
谁定义身份：使用协议是否可以定义标识符，或者使用协议是否必须使用和验证规则提出的、独立于使用协议选择的假名？当然，如果使用协议有一个适当的名称空间，其中包含许多未使用的名称，这些名称可以用作假名，并且可以定期替换为新名称，那么位置对象可能能够使用名称空间。为此，用户可能必须使用此名称空间编写规则。请注意，有必要定期更改使用的笔名，因为识别未链接笔名后面的用户非常简单。
There are several advantages in letting the using protocol define the name space:
让使用协议定义名称空间有几个优点：
o the embedded authentication would be easier, as the using protocol often already has the credentials for the authentication identity in place and the "embedded" authentication would be independent on the form of Identifiers,
o 嵌入式身份验证将更容易，因为使用协议通常已经具有身份验证身份的凭据，并且“嵌入式”身份验证将独立于标识符的形式，
o the size of the names would be fixed.
o 名字的大小将是固定的。
On the other hand, the benefits of the Rule choosing the identifiers are:
另一方面，选择标识符规则的好处是：
o the user has a control of his anonymity, and
o 用户可以控制其匿名性，并且
o the interworking of multiple systems with Location object across protocol boundaries is facilitated.
o 有助于多个系统与跨协议边界的位置对象的互通。
We wish to thank the members of the IETF Geopriv WG for their comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and the participants of the Geopriv meetings in San Diego and Yokohama provided detailed comments or text.
我们要感谢IETF Geopriv工作组成员的意见和建议。Aaron Burstein、Mehmet Ersue、Allison Mankin、Randall Gellens以及圣地亚哥和横滨Geopriv会议的与会者提供了详细的评论或文本。
[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月。
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and
Digital Certificates : Building in Privacy, MIT Press;
ISBN: 0262024918; 1st edition, August, 2000
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and
Digital Certificates : Building in Privacy, MIT Press;
ISBN: 0262024918; 1st edition, August, 2000
[Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
[Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[ISO99]ISO99:ISO IS 154081999，http://www.commoncriteria.org/.
[OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, http://www.oecd.org.
[OECD]OECD个人数据隐私和跨境流动保护指南，http://www.oecd.org.
[Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at
http://www.koehntopp.de/marit/pub/anon
[Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at
http://www.koehntopp.de/marit/pub/anon
Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich, Germany
豪尔赫R奎利亚尔西门子公司公司技术CT IC 3 81730德国慕尼黑
EMail: Jorge.Cuellar@siemens.com
EMail: Jorge.Cuellar@siemens.com
John B. Morris, Jr. Director, Internet Standards, Technology & Privacy Project Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, D.C. 20006 USA
John B.Morris，Jr.民主与技术互联网标准、技术与隐私项目中心主任，美国华盛顿特区西北大街1634号，1100室，邮编：20006
EMail: jmorris@cdt.org
URI: http://www.cdt.org
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Deirdre K. Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
DulrdR.Muligang-萨缪尔森定律，技术与公共政策诊所，博尔特学院法学院，加利福尼亚大学，伯克利，CA 94720美国
EMail: dmulligan@law.berkeley.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
EMail: dmulligan@law.berkeley.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 5707 Concord, CA 94520 USA
Jon Peterson NeuStar，Inc.美国加利福尼亚州康科德市萨特街1800号5707室，邮编94520
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
詹姆斯·M·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。