Network Working Group J. Peterson
Request for Comments: 4119 NeuStar
Category: Standards Track December 2005
Network Working Group J. Peterson
Request for Comments: 4119 NeuStar
Category: Standards Track December 2005
A Presence-based GEOPRIV Location Object Format
基于状态的GEOPRIV定位对象格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.
本文档描述了在Internet上承载地理信息的对象格式。此位置对象扩展了状态信息数据格式（PIDF），该格式用于传输隐私敏感的状态信息，并且具有类似的属性。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Location Object Format ..........................................4
2.1. Baseline PIDF Usage ........................................4
2.2. Extensions to PIDF for Location and Usage Rules ............5
2.2.1. 'location-info' Element .............................5
2.2.2. 'usage-rules' Element ...............................7
2.2.3. 'method' Element ....................................9
2.2.4. 'provided-by' Element ...............................9
2.2.5. Schema Definitions .................................10
2.3. Example Location Objects ..................................14
3. Carrying PIDF in a Using Protocol ..............................15
4. Securing PIDF ..................................................15
5. Security Considerations ........................................17
6. IANA Considerations ............................................17
6.1. 'method' Tokens ...........................................17
6.2. 'provided-by' Elements ....................................18
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
7. Acknowledgements ...............................................19
A. Appendix: NENA Provided-by Schema ..............................20
A.1. dataProvider XML Schema ...................................21
Normative References ..............................................22
Informative References ............................................22
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Location Object Format ..........................................4
2.1. Baseline PIDF Usage ........................................4
2.2. Extensions to PIDF for Location and Usage Rules ............5
2.2.1. 'location-info' Element .............................5
2.2.2. 'usage-rules' Element ...............................7
2.2.3. 'method' Element ....................................9
2.2.4. 'provided-by' Element ...............................9
2.2.5. Schema Definitions .................................10
2.3. Example Location Objects ..................................14
3. Carrying PIDF in a Using Protocol ..............................15
4. Securing PIDF ..................................................15
5. Security Considerations ........................................17
6. IANA Considerations ............................................17
6.1. 'method' Tokens ...........................................17
6.2. 'provided-by' Elements ....................................18
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
7. Acknowledgements ...............................................19
A. Appendix: NENA Provided-by Schema ..............................20
A.1. dataProvider XML Schema ...................................21
Normative References ..............................................22
Informative References ............................................22
Geographical location information describes a physical position in the world that may correspond to the past, present, or future location of a person, event, or device. Numerous applications used in the Internet today benefit from sharing location information (including mapping/navigation applications, 'friend finders' on cell phones, and so on). However, such applications may disclose the whereabouts of a person in a manner contrary to the user's preferences. Privacy lapses may result from poor protocol security (which permits eavesdroppers to capture location information), inability to articulate or accommodate user preferences, or similar defects common in existing systems. The privacy concerns surrounding the unwanted disclosure of a person's physical location are among the more serious issues that confront users on the Internet.
地理位置信息描述了世界上可能与人、事件或设备的过去、现在或未来位置相对应的物理位置。如今互联网上使用的许多应用程序都受益于共享位置信息（包括地图/导航应用程序、手机上的“朋友查找器”等）。然而，此类应用程序可能以与用户偏好相反的方式披露某人的下落。隐私失效可能是由于协议安全性差（允许窃听者捕获位置信息）、无法表达或适应用户偏好或现有系统中常见的类似缺陷造成的。围绕着不必要地泄露个人物理位置的隐私问题是互联网用户面临的更为严重的问题之一。
Consequently, a need has been identified to convey geographical location information within an object that includes a user's privacy and disclosure preferences and which is protected by strong cryptographic security. Previous work [13] has observed that this problem bears some resemblance to the general problem of
因此，已经确定了在对象内传递地理位置信息的需要，该对象包括用户的隐私和披露偏好，并且受到强密码安全性的保护。以前的工作[13]已经观察到，这个问题在某种程度上类似于一般的问题
communicating and securing presence information on the Internet. Presence (defined in [12]) provides a real-time communications disposition for a user, and thus has similar requirements for selective distribution and security.
在Internet上通信和保护状态信息。存在（定义见[12]）为用户提供实时通信配置，因此对选择性分布和安全性有类似的要求。
Therefore, this document extends the XML-based Presence Information Data Format (PIDF [2]) to allow the encapsulation of location information within a presence document.
因此，本文档扩展了基于XML的状态信息数据格式（PIDF[2]），以允许在状态文档中封装位置信息。
This document does not invent any format for location information itself. Numerous existing formats based on civic location, geographic coordinates, and the like, have been developed in other standards fora. Instead, this document defines an object that is suitable both for identifying and encapsulating preexisting location information formats, and for providing adequate security and policy controls to regulate the distribution of location information over the Internet.
本文档本身并没有发明任何位置信息格式。许多基于城市位置、地理坐标等的现有格式已在其他标准论坛中开发。相反，本文档定义了一个对象，该对象既适用于识别和封装先前存在的位置信息格式，也适用于提供足够的安全性和策略控制，以规范位置信息在Internet上的分发。
The location object described in this document can be used independently of any 'using protocol', as the term is defined in the GEOPRIV requirements [10]. It is considered an advantage of this proposal that existing presence protocols (such as [14]) would natively accommodate the location object format defined in this document, and be capable of composing location information with other presence information, because this location object is an extension of PIDF. However, the usage of this location object format is not limited to presence-using protocols-- any protocol that can carry XML or MIME types can carry PIDF.
本文件中描述的位置对象可独立于任何“使用协议”使用，如GEOPRIV要求[10]中定义的术语。该方案的一个优点是，现有的存在协议（如[14]）将在本机上适应本文档中定义的位置对象格式，并且能够将位置信息与其他存在信息组合在一起，因为该位置对象是PIDF的扩展。然而，这种位置对象格式的使用并不局限于使用协议的存在——任何可以携带XML或MIME类型的协议都可以携带PIDF。
Some of the requirements in [10] and [11] concern data collection and usage policies associated with location objects. This document provides only the minimum markup necessary for a user to express the necessary privacy preferences as specified by the GEOPRIV requirements (the three basic elements in [11]). However, this document does not demonstrate how a full XML-based ruleset, accommodating the needs of Location Servers, could be embedded in PIDF. It is assumed that other protocols (such as HTTP) will be used to move rules between Rule Holders and Location Servers, and that full rulesets will be defined in a separate document.
[10]和[11]中的一些要求涉及与位置对象相关的数据收集和使用策略。本文件仅提供用户表达GEOPRIV要求规定的必要隐私偏好所需的最低标记（见[11]中的三个基本要素）。但是，本文档没有演示如何将一个完整的基于XML的规则集（适应位置服务器的需要）嵌入到PIDF中。假设其他协议（如HTTP）将用于在规则持有者和位置服务器之间移动规则，并且完整的规则集将在单独的文档中定义。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
The GEOPRIV requirements [10] (or REQ for short) specify the need for a name for the person, place or thing that location information describes (REQ 2.1). PIDF has such an identifier already: every PIDF document has an "entity" attribute of the 'presence' element that signifies the URI of the entity whose presence the document describes. Consequently, if location information is contained in a PIDF document, the URI in the "entity" attribute of the 'presence' element indicates the target of that location information (the 'presentity'). The URI in the "entity" attribute generally uses the "pres" URI scheme defined in [3]. Such URIs can serve as unlinkable pseudonyms (per REQ 12).
GEOPRIV要求[10]（简称REQ）规定了位置信息所描述的人员、地点或事物的名称需求（REQ 2.1）。PIDF已经有了这样一个标识符：每个PIDF文档都有一个“presence”元素的“entity”属性，表示文档描述的实体的URI。因此，如果位置信息包含在PIDF文档中，“presence”元素的“entity”属性中的URI指示该位置信息的目标（“presentity”）。“entity”属性中的URI通常使用[3]中定义的“pres”URI方案。此类URI可以用作不可链接的假名（根据REQ 12）。
PIDF optionally contains a 'contact' element that provides a URI where the presentity can be reached by some means of communication. Usually, the URI scheme in the value of the 'contact' element gives some sense of how the presentity can be reached; if it uses the SIP URI scheme, for example, SIP can be used, and so on. Location information can be provided without any associated means of communication. Thus, the 'contact' element may or may not be present, as desired by the creator of the PIDF document.
PIDF可选地包含一个“contact”元素，该元素提供一个URI，通过某种通信方式可以访问该实体。通常，“contact”元素的值中的URI方案给出了如何达到存在实体的某种意义；例如，如果它使用SIPURI方案，则可以使用SIP，等等。无需任何相关通信手段即可提供位置信息。因此，根据PIDF文档的创建者的需要，“联系人”元素可能存在，也可能不存在。
PIDF optionally contains a 'timestamp' element that designates the time at which the PIDF document was created. This element corresponds to REQ 2.7a.
PIDF可选地包含一个“timestamp”元素，用于指定创建PIDF文档的时间。该元素对应于要求2.7a。
PIDF contains a 'status' element, which is mandatory. 'status' contains an optional child element, 'basic', that describes the presentity's communications disposition (in very broad terms: either OPEN or CLOSED). For the purposes of this document, it is not necessary for 'basic' status to be included. If, however, communications disposition is included in a PIDF document above and beyond geolocation, then 'basic' status may appear in a PIDF document that uses these extensions.
PIDF包含一个“status”元素，这是必需的status包含一个可选的子元素basic，它描述了实体的通信配置（用非常宽泛的术语：打开或关闭）。就本文件而言，无需包括“基本”状态。但是，如果通信配置包含在地理位置之上和之外的PIDF文档中，则“基本”状态可能会出现在使用这些扩展的PIDF文档中。
PIDF also contains a 'tuple' umbrella element, which holds an "id" element used to uniquely identify a segment of presence information so that changes to this information can be tracked over time (as multiple notifications of presence are received). 'timestamp', 'status', and 'contact' are composed under 'tuple'.
PIDF还包含一个“tuple”伞形元素，其中包含一个“id”元素，用于唯一标识状态信息段，以便随着时间的推移（当接收到多个状态通知时）可以跟踪对该信息的更改“时间戳”、“状态”和“联系人”由“元组”组成。
This XML Schema extends the 'status' element of PIDF with a complex element called 'geopriv'. There are two major subelements that are encapsulated within geopriv: one for location information, and one for usage rules. Both of these subelements are mandatory, and are described in subsequent sections. By composing these two subelements under 'geopriv', the usage rules are clearly and explicitly associated with the location information.
此XML模式使用名为“geopriv”的复杂元素扩展了PIDF的“status”元素。geopriv中封装了两个主要的子元素：一个用于位置信息，另一个用于使用规则。这两个子元素都是必需的，将在后续章节中介绍。通过在“geopriv”下组合这两个子元素，使用规则与位置信息明确关联。
For extensibility (see REQ 1.4), the schema allows any other subelements to appear under the 'geopriv' element. Two other optional subelements are included in this document: one that indicates the method by which geographical location was determined, and one that allows an explicit designation of the entity that provided the information.
对于可扩展性（参见REQ 1.4），模式允许任何其他子元素出现在“geopriv”元素下。本文件还包括两个可选子元素：一个表示确定地理位置的方法，另一个允许明确指定提供信息的实体。
Each 'geopriv' element MUST contain one 'location-info' element. A 'location-info' element consists of one or more chunks of location information (per REQ 2.5). The format of the location information (REQ 2.6) is identified by the imported XML Schema, which describes the namespace in question. All PIDF documents that contain a 'geopriv' element MUST contain one or more import directives indicating the XML Schema(s) that are used for geographic location formats.
每个“geopriv”元素必须包含一个“位置信息”元素。“位置信息”元素由一个或多个位置信息块组成（根据REQ 2.5）。位置信息（REQ 2.6）的格式由导入的XML模式标识，该模式描述了所讨论的名称空间。包含“geopriv”元素的所有PIDF文档必须包含一个或多个指示用于地理位置格式的XML模式的导入指令。
In order to ensure interoperability of GEOPRIV implementations, it is necessary to select a baseline location format that all compliant implementations support (see REQ 3.1). Because it satisfies REQ 2.5.1, this document works from the assumption that Geography Markup Language (GML) 3.0 [15] shall be this mandatory format (a MUST implement for all PIDF implementations supporting the 'geopriv' element).
为了确保GEOPRIV实施的互操作性，有必要选择所有合规实施支持的基线位置格式（见REQ 3.1）。由于满足REQ 2.5.1的要求，本文件基于地理标记语言（GML）3.0[15]应为该强制性格式的假设（所有支持“geopriv”元素的PIDF实现必须实现）。
GML is an extraordinarily thorough and versatile system for modeling all manner of geographic object types, topologies, metadata, coordinate reference systems, and units of measurement. The simplest package for GML supporting location
GML是一个非常全面和通用的系统，用于建模各种地理对象类型、拓扑、元数据、坐标参考系和度量单位。GML支持位置的最简单包
information is the 'feature.xsd' schema. Although 'feature.xsd' can express complicated geographical concepts, it requires very little markup to provide basic coordinate points for the most commonly used cases. Various format descriptions (including latitude/longitude based location information) are supported by Feature (see section 7.4.1.4 of [15] for examples), which resides here:
信息是“feature.xsd”模式。尽管“feature.xsd”可以表达复杂的地理概念，但它只需要很少的标记就可以为最常用的情况提供基本的坐标点。功能支持各种格式描述（包括基于纬度/经度的位置信息）（示例见[15]第7.4.1.4节），该功能位于：
urn:opengis:specification:gml:schema-xsd:feature:v3.0
urn:opengis:specification:gml:schema-xsd:feature:v3.0
Note that by importing the Feature schema, necessary GML baseline schemas are transitively imported.
请注意，通过导入功能模式，必要的GML基线模式将被传递导入。
Complex features (such as modeling topologies and polygons, directions and vectors, temporal indications of the time for which a particular location is valid for a target) are also available in GML, but require importing additional schemas. For the purposes of baseline interoperability as defined by this document, only support for the 'feature.xsd' GML schema is REQUIRED.
GML中也提供了复杂的特征（例如建模拓扑和多边形、方向和向量、特定位置对目标有效的时间的时间指示），但需要导入其他模式。为了实现本文档定义的基线互操作性，只需要支持'feature.xsd'GML模式。
Implementations MAY support the civic location format (civicLoc) defined in Section 2.2.5. civicLoc provides the following elements:
实施可支持第2.2.5节中定义的CivicLocation格式（civicLoc）。civicLoc提供以下要素：
+----------------------+----------------------+---------------------+
| Label | Description | Example |
+----------------------+----------------------+---------------------+
| country | The country is | US |
| | identified by the | |
| | two-letter ISO 3166 | |
| | code. | |
| | | |
| A1 | national | New York |
| | subdivisions (state, | |
| | region, province, | |
| | prefecture) | |
| | | |
| A2 | county, parish, gun | King's County |
| | (JP), district (IN) | |
| | | |
| A3 | city, township, shi | New York |
| | (JP) | |
| | | |
| A4 | city division, | Manhattan |
| | borough, city | |
| | district, ward, chou | |
| | (JP) | |
| | | |
| A5 | neighborhood, block | Morningside Heights |
| | | |
| A6 | street | Broadway |
| | | |
| PRD | Leading street | N, W |
| | direction | |
| | | |
| POD | Trailing street | SW |
| | suffix | |
+----------------------+----------------------+---------------------+
| Label | Description | Example |
+----------------------+----------------------+---------------------+
| country | The country is | US |
| | identified by the | |
| | two-letter ISO 3166 | |
| | code. | |
| | | |
| A1 | national | New York |
| | subdivisions (state, | |
| | region, province, | |
| | prefecture) | |
| | | |
| A2 | county, parish, gun | King's County |
| | (JP), district (IN) | |
| | | |
| A3 | city, township, shi | New York |
| | (JP) | |
| | | |
| A4 | city division, | Manhattan |
| | borough, city | |
| | district, ward, chou | |
| | (JP) | |
| | | |
| A5 | neighborhood, block | Morningside Heights |
| | | |
| A6 | street | Broadway |
| | | |
| PRD | Leading street | N, W |
| | direction | |
| | | |
| POD | Trailing street | SW |
| | suffix | |
| | | |
| STS | Street suffix | Avenue, Platz, |
| | | Street |
| | | |
| HNO | House number, | 123 |
| | numeric part only. | |
| | | |
| HNS | House number suffix | A, 1/2 |
| | | |
| LMK | Landmark or vanity | Low Library |
| | address | |
| | | |
| LOC | Additional location | Room 543 |
| | information | |
| | | |
| FLR | Floor | 5 |
| | | |
| NAM | Name (residence, | Joe's Barbershop |
| | business or office | |
| | occupant) | |
| | | |
| PC | Postal code | 10027-0401 |
+----------------------+----------------------+---------------------+
| | | |
| STS | Street suffix | Avenue, Platz, |
| | | Street |
| | | |
| HNO | House number, | 123 |
| | numeric part only. | |
| | | |
| HNS | House number suffix | A, 1/2 |
| | | |
| LMK | Landmark or vanity | Low Library |
| | address | |
| | | |
| LOC | Additional location | Room 543 |
| | information | |
| | | |
| FLR | Floor | 5 |
| | | |
| NAM | Name (residence, | Joe's Barbershop |
| | business or office | |
| | occupant) | |
| | | |
| PC | Postal code | 10027-0401 |
+----------------------+----------------------+---------------------+
Either the GML 3.0 geographical information format element, or the location format element ('civicLoc') defined in this document, MAY appear in a 'location-info' element. Both MAY also be used in the same 'location-info' element. In summary, the feature.xsd schema of GML 3.0 MUST be supported by implementations compliant with this specification, and the civicLoc format MAY be supported by implementations compliant with this specification.
本文件中定义的GML 3.0地理信息格式元素或位置格式元素（“civicLoc”）可能出现在“位置信息”元素中。两者也可用于同一“位置信息”元素。总之，符合本规范的实现必须支持GML 3.0的feature.xsd模式，符合本规范的实现可能支持civicLoc格式。
At the time this document was written, the policy requirements for GEOPRIV objects were not definitively completed. However, the 'usage-rules' element exists to satisfy REQ 2.8 and the requirements of the GEOPRIV policy requirements [11] document. Each 'geopriv' element MUST contain one 'usage-rules' element, even if the Rule
在编写本文件时，GEOPRIV对象的政策要求尚未最终完成。然而，“使用规则”元素的存在是为了满足要求2.8和GEOPRIV政策要求[11]文件的要求。每个“geopriv”元素必须包含一个“usage rules”元素，即使规则
Maker has requested that all subelements be given their default values.
Maker已请求为所有子元素提供其默认值。
Following the policy requirements document (Section 3.1), there are three fields that need to be expressible in Location Objects throughout their lifecycle (from Generator to Recipient): one field that limits retransmission, one that limits retention, and one that contains a reference to external rulesets. Those three fields are
在策略要求文档（第3.1节）之后，有三个字段需要在位置对象的整个生命周期（从生成器到收件人）中表达：一个字段限制重新传输，一个字段限制保留，还有一个字段包含对外部规则集的引用。这三个字段是
instantiated here by the first three elements. The fourth element provides a generic space for human-readable policy directives. Any of these fields MAY be present in a Location Object 'usage-rules' element; none are required to be.
这里由前三个元素实例化。第四个元素为人类可读的策略指令提供了通用空间。这些字段中的任何一个都可能存在于Location对象的“usage rules”元素中；不需要任何人。
'retransmission-allowed': When the value of this element is 'no', the Recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. When the value of this element is 'yes', distributing this Location is permitted (barring an existing out-of-band agreement or obligation to the contrary). By default, the value MUST be assumed to be 'no'. Implementations MUST include this field, with a value of 'no', if the Rule Maker specifies no preference.
“允许重新传输”：当此元素的值为“否”时，不允许此位置对象的收件人与其他方共享所包含的位置信息或对象作为一个整体。当该元素的值为“是”时，允许分配该位置（除非存在带外协议或相反的义务）。默认情况下，该值必须假定为“否”。如果规则制定者未指定首选项，则实现必须包含此字段，其值为“否”。
'retention-expires': This field specifies an absolute date at which time the Recipient is no longer permitted to possess the location information and its encapsulating Location Object; both may be retained only until the time specified by this field. By default, the value MUST be assumed to be twenty-four hours from the 'timestamp' element in the PIDF document, if present; if the 'timestamp' element is also not present, then the value MUST be assumed to be twenty-four hours from the time at which the Location Object is received by the Location Recipient. If the value in the 'retention-expires' element has already passed when the Location Recipient receives the Location Object, the Recipient MUST discard the Location Object immediately.
“retention expires”：此字段指定一个绝对日期，在该日期收件人不再被允许拥有位置信息及其封装位置对象；两者都只能保留到该字段指定的时间。默认情况下，该值必须假定为从PIDF文档中的“timestamp”元素（如果存在）起24小时；如果“timestamp”元素也不存在，则必须假定该值为从位置接收者接收位置对象的时间算起的二十四小时。如果“retention expires”元素中的值在Location收件人收到Location对象时已传递，则收件人必须立即放弃Location对象。
'ruleset-reference': This field contains a URI that indicates where a fuller ruleset of policies, related to this object, can be found. This URI SHOULD use the HTTPS URI scheme; and if it does, the server that holds these rules MUST authenticate any attempt to access these rules. Usage rules themselves may divulge private information about a Target or Rule Maker. The URI MAY, alternatively, use the CID URI scheme [7], in which case it MUST denote a MIME body carried with the Location Object by the using protocol. Rulesets carried as MIME bodies SHOULD be encrypted and signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored by Location Servers or Location Recipients. Note that in order to avoid network lookups that result in an authorization failure, creators of Location Objects MAY put HTTPS-based ruleset-references into an encrypted external MIME body referenced by a CID; in this way, recipients of the Location Object that are unable to decrypt the external MIME body will not learn the HTTPS URI unless they are able to decrypt the MIME body.
“规则集引用”：此字段包含一个URI，指示在何处可以找到与此对象相关的更完整的策略规则集。此URI应使用HTTPS URI方案；如果是这样，则持有这些规则的服务器必须对访问这些规则的任何尝试进行身份验证。使用规则本身可能泄露有关目标或规则制定者的私人信息。URI也可以使用CID URI方案[7]，在这种情况下，它必须表示由using协议与Location对象一起携带的MIME主体。作为MIME主体携带的规则集应由规则制定者进行加密和签名；位置服务器或位置收件人不应遵守未签名的规则集。请注意，为了避免导致授权失败的网络查找，位置对象的创建者可以将基于HTTPS的规则集引用放入由CID引用的加密外部MIME主体中；这样，无法解密外部MIME正文的Location对象的收件人将不会学习HTTPS URI，除非他们能够解密MIME正文。
'note-well': This field contains a block of text containing further generic privacy directives. These directives are intended to be human-readable only, not to be processed by any automaton.
“注意事项”：此字段包含一个包含更多通用隐私指令的文本块。这些指令仅供人类阅读，不可由任何自动机处理。
The optional 'method' element describes the way that the location information was derived or discovered. An example of this element (for a geographical position system) is:
可选的“method”元素描述位置信息的派生或发现方式。该要素的一个示例（对于地理位置系统）为：
<method>gps</method>
<method>gps</method>
The possible values of the 'method' element are enumerated within an IANA registry. Implementations MUST limit the use of this method to the values shepherded by IANA. This document pre-populates the IANA registry with seven possible values; see Section 6.1 for more information.
“method”元素的可能值在IANA注册表中枚举。实现必须将此方法的使用限制为IANA指定的值。本文档使用七个可能的值预先填充IANA注册表；详见第6.1节。
The 'method' element is useful, for example, when multiple sources are reporting location information for a given user, and some means of determining location might be considered more authoritative than others (i.e., a dynamic, real-time position system versus static provisioning associated with a target device). However, note that inclusion of 'method' might reveal sensitive information when the generator is providing intentionally coarsened location information. For example, when a LO is transmitted with 'DHCP' as the 'method', but the location information indicates only the city in which the generator is located, the sender has good justification to suspect that some location information is being withheld.
例如，当多个源报告给定用户的位置信息时，“方法”元素是有用的，并且某些确定位置的方法可能被认为比其他方法更具权威性（即，与与目标设备相关联的静态供应相比，动态、实时位置系统）。但是，请注意，当生成器提供有意粗化的位置信息时，包含“方法”可能会显示敏感信息。例如，当使用“DHCP”作为“方法”传输LO时，但位置信息仅指示生成器所在的城市，发送方有充分的理由怀疑某些位置信息被扣留。
The optional 'provided-by' element describes the entity or organization that supplied this location information (beyond the domain information that can be inferred from a signing certificate). An example of this element (for a made-up game system) might be:
可选的“provided by”元素描述提供此位置信息的实体或组织（不包括可从签名证书推断的域信息）。此元素的一个示例（对于虚构的游戏系统）可能是：
<provided-by>
<test:game>
West5
</test:game>
</provided-by>
<provided-by>
<test:game>
West5
</test:game>
</provided-by>
Values for the 'provided-by' element MUST be IANA-registered XML namespaces; see Section 6.2 for more information.
“提供者”元素的值必须是IANA注册的XML命名空间；详见第6.2节。
The 'provided-by' element is not intended for use by most entities, but rather to meet special requirements for which overhead (IANA registration, location object size) and potential location information leakage are acceptable choices.
“提供者”元素并非用于大多数实体，而是用于满足特殊要求，对于这些要求，开销（IANA注册、位置对象大小）和潜在的位置信息泄漏是可接受的选择。
In general cases, the entity that supplied location information is communicated by the subjectAltName of the certificate with which the location object is signed; thus, this element is unnecessary. 'Provided-by' is meaningful in particular cases when the creator of a location object wants to designate a particular system or party within a complex administrative domain, including situations envisioned for providing emergency services in a diverse national context. It might assist, for example, the recipient of a malformed or misleading location object in identifying the particular system that malfunctioned.
在一般情况下，提供位置信息的实体通过与位置对象签名的证书的subjectAltName进行通信；因此，这一要素是不必要的。”当位置对象的创建者希望指定复杂行政领域内的特定系统或当事方时，包括在不同国家背景下提供紧急服务的设想情况下，“提供者”在特定情况下是有意义的。例如，它可能有助于格式错误或误导性位置对象的接收者识别发生故障的特定系统。
Users should be aware that this information can inadvertently provide additional information to the receiver, increasing the effective resolution of the geospatial or civic information, or even revealing some location information, when it was meant to be entirely protected. Consider if there were circumstances that influenced Columbia University to elect to register and use the provided-by element. If an example LO includes only state-level information, then including the fact that the location information was provided by Columbia University provides a strong indication that the Target is actually located in a four-block area in Manhattan. Accordingly, this element should be used only when organizational functions strongly would depend on it. In all but such usages, the subjectAltName of the certificate will suffice, and 'provided-by' SHOULD NOT be used.
用户应意识到，这些信息可能无意中向接收者提供额外信息，从而提高地理空间或公民信息的有效分辨率，甚至在需要完全保护的情况下泄露某些位置信息。如果有影响哥伦比亚大学选择登记和使用元素提供的情况。如果示例LO仅包括州级信息，那么包括由哥伦比亚大学提供的位置信息这一事实就强烈表明目标实际位于曼哈顿的四个街区区域。因此，只有当组织职能强烈依赖这一要素时，才应使用这一要素。在除此类用途外的所有用途中，证书的主题名称就足够了，不应使用“提供人”。
Note that the XML namespace [4] for this extension to PIDF contains a version number 1.0 (as per REQ 2.10).
请注意，此PIDF扩展的XML命名空间[4]包含版本号1.0（根据REQ 2.10）。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
<xs:import namespace=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
<!-- This import brings in the XML language attribute xml:lang-->
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="geopriv" type="tns:geopriv"/>
<xs:element name="geopriv" type="tns:geopriv"/>
<xs:complexType name="geopriv">
<xs:sequence>
<xs:element name="location-info" type="tns:locInfoType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="usage-rules" type="gbp:locPolicyType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="method" type="tns:locMethod"
minOccurs="0" maxOccurs="1"/>
<xs:element name="provided-by" type="tns:locProvidedBy"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="geopriv">
<xs:sequence>
<xs:element name="location-info" type="tns:locInfoType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="usage-rules" type="gbp:locPolicyType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="method" type="tns:locMethod"
minOccurs="0" maxOccurs="1"/>
<xs:element name="provided-by" type="tns:locProvidedBy"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locInfoType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locInfoType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locMethod">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locMethod">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locProvidedBy">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locProvidedBy">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</xs:schema>
The 'geopriv10' schema imports, for the 'usage-rules' element, the following policy schema. This schema has been broken out from the basic geolocation object in order to allow for its reuse. The semantics associated with these elements, described in Section 2.2.2,
“geopriv10”架构为“usage rules”元素导入以下策略架构。此模式已从基本地理位置对象中分离出来，以允许其重用。第2.2.2节中描述的与这些元素相关的语义，
apply only to the use of these elements to define policy for geolocation objects; any other use of 'usage-rules' must characterize its own semantics for all 'usage-rules' subelements.
仅适用于使用这些元素定义地理定位对象的策略；“使用规则”的任何其他用法必须为所有“使用规则”子元素描述其自身的语义。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:complexType name="locPolicyType">
<xs:sequence>
<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>
<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>
<xs:element name="note-well" type="tns:notewell"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locPolicyType">
<xs:sequence>
<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>
<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>
<xs:element name="note-well" type="tns:notewell"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="notewell">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="notewell">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
</xs:schema>
The following schema is a trivial representation of civic location that MAY be implemented by entities compliant with this specification.
以下模式是civic location的简单表示，可由符合本规范的实体实现。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A1" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A2" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A3" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A4" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A5" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A6" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PRD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="POD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="STS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNO" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LMK" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LOC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="FLR" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="NAM" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A1" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A2" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A3" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A4" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A5" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A6" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PRD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="POD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="STS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNO" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LMK" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LOC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="FLR" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="NAM" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</xs:schema>
Note that these examples show PIDF documents without any MIME headers or security applied to them (see Section 4 below).
请注意，这些示例显示的PIDF文档没有应用任何MIME头或安全性（请参阅下面的第4节）。
The following XML instance document is an example of the use of a simple GML 3.0 markup with a few of the policy directives specified above within a PIDF document. The GPS coordinates given in the 'gml' element are for San Francisco, CA.
下面的XML实例文档是一个简单的GML 3.0标记与上面在PIDF文档中指定的一些策略指令一起使用的示例。GML元素中给出的GPS坐标是旧金山，CA.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
The following XML instance document is an example of the use of the civicLoc object with a few of the policy directives specified above within a PIDF document.
下面的XML实例文档是在PIDF文档中使用civicLoc对象和上面指定的一些策略指令的示例。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
A PIDF document is an XML document; therefore, PIDF might be carried in any protocol capable of carrying XML. A MIME type has also been registered for PIDF: 'application/pidf+xml'. PIDF may therefore be carried as a MIME body in protocols that use MIME (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME headers, including a Content-Type of 'application/pidf+xml'.
PIDF文档是XML文档；因此，PIDF可以在任何能够携带XML的协议中携带。还为PIDF注册了MIME类型：“application/PIDF+xml”。因此，在使用MIME（如SMTP、HTTP或SIP）的协议中，PIDF可以作为MIME主体携带，并带有一组封装的MIME头，包括“应用程序/PIDF+xml”的内容类型。
Further specification of the behavior of using protocols (including subscribing to or requesting presence information) is outside the scope of this document.
使用协议（包括订阅或请求状态信息）的行为的进一步规范超出了本文档的范围。
There are a number of ways in which XML documents can be secured. XML itself supports several ways of partially securing documents, including element-level encryption and digital signature properties.
XML文档的安全保护方式有很多种。XML本身支持几种部分保护文档的方法，包括元素级加密和数字签名属性。
For the purposes of this document, only the securing of a PIDF document as a whole, rather than element-by-element security, is considered. None of the requirements [10] suggest that only part of the information in a location object might need to be protected while other parts are unprotected; virtually any such configuration would introduce potentials for privacy leakage. Consequently, the use of MIME-level security is appropriate.
就本文件而言，仅考虑PIDF文件作为一个整体的安全性，而不是元素对元素的安全性。没有任何要求[10]表明可能只需要保护位置对象中的一部分信息，而其他部分不需要保护；实际上，任何这样的配置都可能导致隐私泄露。因此，使用MIME级别的安全性是合适的。
S/MIME [5] allows security properties (including confidentiality, integrity, and authentication properties) to be applied to the contents of a MIME body. Therefore, all PIDF implementations that support the XML Schema extensions for location information described in this document MUST support S/MIME; in particular, they MUST support the CMS [6] EnvelopedData and SignedData content types, which are used for encryption and digital signatures, respectively. It is believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, and 14.4.
S/MIME[5]允许将安全属性（包括机密性、完整性和身份验证属性）应用于MIME正文的内容。因此，所有支持本文档中描述的位置信息的XML模式扩展的PIDF实现都必须支持S/MIME；特别是，它们必须支持CMS[6]EnvelopedData和SignedData内容类型，分别用于加密和数字签名。相信该机制符合要求2.10、13、14.1、14.2、14.3和14.4。
Additionally, all compliant applications MUST implement the AES encryption algorithm for S/MIME, as specified in [8] (and per REQ 15.1). Of course, implementations MUST also support the baseline encryption and digital signature algorithms described in the S/MIME specification.
此外，所有符合要求的应用程序必须实现[8]中规定的S/MIME AES加密算法（并按照REQ 15.1）。当然，实现还必须支持S/MIME规范中描述的基线加密和数字签名算法。
S/MIME generally entails the use of X.509 [9] certificates. In order to encrypt a request for a particular destination end-to-end (i.e., to a Location Recipient), the Location Generator must possess credentials (typically an X.509 certificate) that have been issued to the Location Recipient. Implementations of this specification SHOULD support X.509 certificates for S/MIME, and MUST support password-based CMS encryption (see [6]). Any symmetric keying systems SHOULD derive high-entropy content encoding keys (CEKs). When X.509 certificates are used to sign PIDF Location Objects, the subjectAltName of the certificate SHOULD use the "pres" URI scheme.
S/MIME通常需要使用X.509[9]证书。为了对特定目的地的请求进行端到端加密（即对位置接收者），位置生成器必须拥有已颁发给位置接收者的凭据（通常是X.509证书）。本规范的实现应支持S/MIME的X.509证书，并且必须支持基于密码的CMS加密（参见[6]）。任何对称密钥系统都应该派生出高熵内容编码密钥（CEK）。当使用X.509证书对PIDF位置对象进行签名时，证书的subjectAltName应使用“pres”URI方案。
One envisioned deployment model for S/MIME in PIDF documents is the following. Location Servers hold X.509 certificates and share secrets with Location Generators and Location Recipients. When a Generator sends location information to a Server, it can be encrypted with S/MIME (or any lower-layer encryption specific to the using protocol). When a Server forwards location information to a Recipient, location information can be encrypted with password-based CMS encryption. This allows the use of encryption when the Location Recipient does not possess its own X.509 certificate.
PIDF文档中S/MIME的一个设想部署模型如下。位置服务器持有X.509证书，并与位置生成器和位置收件人共享机密。当生成器向服务器发送位置信息时，可以使用S/MIME（或特定于使用协议的任何较低层加密）对其进行加密。当服务器将位置信息转发给收件人时，可以使用基于密码的CMS加密对位置信息进行加密。这允许在位置收件人不拥有自己的X.509证书时使用加密。
S/MIME was designed for end-to-end security between email peers that communicate through multiple servers (i.e mail transfer agents) that do not modify message bodies. There is, however, at least one instance in which Location Servers modify Location Objects: when Location Servers enforce policies on behalf of the Rule Maker. For example, a Rule Maker may specify that Location Information should be coarsened (made less specific) before it is transmitted to particular recipients. If the Location Server were unable to modify a Location Object, because it was encrypted, signed, or both, it would be unable to accomplish this function. Consequently, when a Location Generator wants to allow a Location Server to modify such messages, they MAY
S/MIME设计用于通过多个不修改邮件正文的服务器（即电子邮件传输代理）进行通信的电子邮件对等方之间的端到端安全。但是，至少有一个位置服务器修改位置对象的实例：当位置服务器代表规则制定者实施策略时。例如，规则制定者可以指定在将位置信息传输给特定接收者之前，应该对其进行粗化（使其不那么具体）。如果位置服务器无法修改位置对象，因为它是加密的、签名的或两者都是，那么它将无法完成此功能。因此，当位置生成器希望允许位置服务器修改此类消息时，它们可能会
encrypt such messages with a key that can be decrypted by the Location Server (the digital signature, of course, can still be created with keying material from the Location Generator's certificate). After modifying the Location Object, the Location
使用位置服务器可以解密的密钥加密此类消息（当然，数字签名仍然可以使用位置生成器证书中的密钥材料创建）。修改位置对象后，位置
Server can re-sign the Object with its own credentials (encrypting it with any keys issued to the Location Recipient, if they are known to the Server).
服务器可以使用自己的凭据对对象进行重新签名（如果服务器知道，则使用发给位置收件人的任何密钥对其进行加密）。
Note that policies for data collection and usage of location information, in so far as they are carried within a location object, are discussed in Section 2.2.2.
请注意，第2.2.2节讨论了位置信息的数据收集和使用策略，只要这些策略包含在位置对象中。
The threats facing an Internet protocol that carries geolocation information are detailed in [16]. The requirements that were identified in that analysis of the threat model were incorporated into [10], in particular within Section 7.4. This document aims to be compliant with the security requirements derived from those two undertakings, in so far as they apply to the location object itself (as opposed to the using protocol).
[16]详细介绍了承载地理位置信息的互联网协议面临的威胁。威胁模型分析中确定的要求已纳入[10]，特别是第7.4节。本文件旨在遵守从这两项承诺中得出的安全要求，只要它们适用于位置对象本身（与使用协议相反）。
Security of the location object defined in this document, including normative requirements for implementations, is discussed in Section 4. This security focuses on end-to-end integrity and confidentiality properties that are applied to a location object for its lifetime via S/MIME.
第4节讨论了本文档中定义的位置对象的安全性，包括实现的规范性要求。此安全性关注通过S/MIME在位置对象的生命周期中应用的端到端完整性和机密性属性。
Security requirements associated with using protocols (including authentication of subscribers to geographical information, etc.) are outside the scope of this document.
与使用协议相关的安全要求（包括地理信息订阅者的身份验证等）不在本文件的范围内。
This document requests that the IANA create a new registry for 'method' tokens associated with the PIDF-LO object. 'method' tokens are text strings designating the manner in which location information in a PIDF-LO object has been derived or discovered. Any party may register new 'method' tokens with the IANA, as needed, on a first-come-first-serve basis.
本文档要求IANA为与PIDF-LO对象关联的“方法”标记创建一个新的注册表方法的标记是文本字符串，指定派生或发现PIDF-LO对象中位置信息的方式。根据需要，任何一方均可在IANA注册新的“方法”代币，先到先得。
This section pre-registers 7 new 'method' tokens associated with the 'method' element described above in Section 2.2.3:
本节预先注册了7个与上述第2.2.3节所述“方法”元素相关的新“方法”令牌：
GPS: Global Positioning System A-GPS: GPS with assistance Manual: entered manually by an operator or user, e.g., based on subscriber billing or service location information DHCP: provided by DHCP (used for wireline access networks, see 802.11 below) Triangulation: triangulated from time-of-arrival, signal strength, or similar measurements Cell: location of the cellular radio antenna 802.11: 802.11 access point (used for DHCP-based provisioning over wireless access networks)
GPS:Global Positioning System A-GPS:GPS with assistance Manual（全球定位系统A-GPS:GPS辅助手册）：由操作员或用户手动输入，例如，基于订户账单或服务位置信息DHCP：由DHCP提供（用于有线接入网络，见下文802.11）三角测量：从到达时开始三角测量，信号强度，或类似测量：蜂窝无线天线802.11:802.11接入点的位置（用于无线接入网络上基于DHCP的配置）
This document requests that IANA create a new registry of XML namespaces for 'provided-by' elements for use with PIDF-LO objects. Registrations of new XML namespaces that are used for 'provided-by' MUST be reviewed by an Expert Reviewer designated by the IESG.
本文档要求IANA为“提供者”元素创建一个新的XML名称空间注册表，用于PIDF-LO对象。用于“提供者”的新XML名称空间的注册必须由IESG指定的专家审核人审核。
This document pre-registers a single XML namespace for 'provided-by', which is given in Appendix A.
本文档为“提供者”预先注册了一个XML名称空间，如附录a所示。
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10
This section registers a new XML namespace, as per the guidelines in [4].
本节根据[4]中的指导原则注册一个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10. Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML:
URI：此命名空间的URI为urn:ietf:params:xml:ns:pidf:geopriv10。注册人联系人：IETF、GEOPRIV工作组、(geopriv@ietf.org)，乔恩·彼得森。peterson@neustar.biz). XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>GEOPRIV PIDF Extensions</title>
</head>
<body>
<h1>PIDF Extensions of Geographical Information and Privacy</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>GEOPRIV PIDF Extensions</title>
</head>
<body>
<h1>PIDF Extensions of Geographical Information and Privacy</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
RFC4119</a>.</p>
</body>
</html>
END
This document was produced with the assistance of many members of the GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS for a close read of the document.
本文件是在GEOPRIV IETF工作组许多成员的协助下编制的。特别感谢OpenGIS的Carl Reed仔细阅读了该文档。
The civic location format described in this document was proposed by Henning Schulzrinne for communicating location information in DHCP, and has been appropriated in its entirety for this document.
本文件中描述的城市位置格式由Henning Schulzrinne提出，用于在DHCP中传输位置信息，并已全部用于本文件。
James M. Polk provided the text related to the 'method' element, and much of the text for the 'provided-by' element. The text of Appendix A was written by Nadine Abbott.
James M.Polk提供了与“method”元素相关的文本，而大部分文本都是为“provided by”元素提供的。附录A的文本由Nadine Abbott编写。
A. Appendix: NENA Provided-By Schema
A.附录：NENA由Schema提供
The following registers the XML namespace urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated schema below, for usage within the 'provided-by' element of PIDF-LO. The dataProvider namespace was developed by the US National Emergency Number Administration (NENA) for next-generation emergency communications needs.
下面注册了XML命名空间urn:ietf:params:XML:ns:pidf:geopriv10:dataProvider和下面的关联架构，以便在pidf-LO的“提供者”元素中使用。数据提供者名称空间由美国国家紧急号码管理局（NENA）为满足下一代紧急通信需求而开发。
This appendix is non-normative for implementers of PIDF-LO implementations and MAY support the dataProvider namespace. Other registrants of 'provided-by' namespaces are invited to use the registration below as an informative example.
本附录对于PIDF-LO实现的实现者来说是非规范性的，可能支持dataProvider命名空间。请“提供者”名称空间的其他注册者使用下面的注册作为信息示例。
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV working group, (geopriv@ietf.org), Nadine Abbott (nabbott@telcordia.com). XML:
URI：此命名空间的URI为urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider注册人联系人：NENA，VoIP工作组&ietf，GEOPRIV工作组(geopriv@ietf.org)，Nadine Abbott(nabbott@telcordia.com). XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>NENA dataProvider Schema for PIDF-LO</title>
</head>
<body>
<h1>NENA dataProvider Schema for 'provided-by' in PIDF-LO</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>NENA dataProvider Schema for PIDF-LO</title>
</head>
<body>
<h1>NENA dataProvider Schema for 'provided-by' in PIDF-LO</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by
Patricia Bluhm (HBF Group) -->
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="nena" type="tns:DataProviderIDType"/>
<xs:complexType name="DataProviderIDType">
<xs:annotation>
<xs:documentation>NENA registered Company ID
for Service Provider supplying location information</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="DataProviderID"
type="tns:NENACompanyIDType" minOccurs="0"/>
<xs:element name="TelURI"
type="tns:TelURI_24x7Type" minOccurs="0"/>
<xs:element name="URL" type="xs:anyURI"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="NENACompanyIDType">
<xs:annotation>
<xs:documentation>NENA registered Company
ID.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TelURI_24x7Type">
<xs:annotation>
<xs:documentation>24x7 Tel URI for the
caller's [location data] service provider. To be used for contacting
service provider to resolve problems with location data. Possible
values TN number, enumerated values when not
available.</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by
Patricia Bluhm (HBF Group) -->
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="nena" type="tns:DataProviderIDType"/>
<xs:complexType name="DataProviderIDType">
<xs:annotation>
<xs:documentation>NENA registered Company ID
for Service Provider supplying location information</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="DataProviderID"
type="tns:NENACompanyIDType" minOccurs="0"/>
<xs:element name="TelURI"
type="tns:TelURI_24x7Type" minOccurs="0"/>
<xs:element name="URL" type="xs:anyURI"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="NENACompanyIDType">
<xs:annotation>
<xs:documentation>NENA registered Company
ID.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TelURI_24x7Type">
<xs:annotation>
<xs:documentation>24x7 Tel URI for the
caller's [location data] service provider. To be used for contacting
service provider to resolve problems with location data. Possible
values TN number, enumerated values when not
available.</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="10"/>
<xs:enumeration value="NOT FOUND"/>
<xs:restriction base="xs:string">
<xs:maxLength value="10"/>
<xs:enumeration value="NOT FOUND"/>
<xs:enumeration value="UNAVAILABLE"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>
<xs:enumeration value="UNAVAILABLE"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>
Normative References
规范性引用文件
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[2] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, October 2003.
[3] 彼得森，J.，“存在的共同概况（CPP）”，RFC 3859，2003年10月。
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 2004.
[4] Mealling，M.，“IETF XML注册表”，RFC 3688，BCP 81，2004年1月。
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[5] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[6] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[7] Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[8] Schaad，J.，“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[9] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
Informative References
资料性引用
[10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[10] Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[11] Morris, J., Mulligan, D., and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", Work in Progress, June 2003.
[11] Morris，J.，Mulligan，D.，和J.Cuellar，“Geopriv定位对象的核心隐私保护”，正在进行的工作，2003年6月。
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[12] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.
[13] Peterson，J.，“Geopriv定位对象分布的存在架构”，正在进行的工作，20003年2月。
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[14] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年5月。
[15] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, January 2003, <http://www.opengeospatial.org/specs/?page=specs>.
[15] OpenGIS，“开放地理标记语言（GML）实现规范”，OGC 02-023r4，2003年1月<http://www.opengeospatial.org/specs/?page=specs>.
[16] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[16] Danley，M.，Mulligan，D.，Morris，J.，和J.Peterson，“Geopriv协议的威胁分析”，RFC 36942004年2月。
Author's Address
作者地址
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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编辑功能的资金目前由互联网协会提供。