Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6848 CommScope
Updates: 4776, 5222 M. Thomson
Category: Standards Track Skype
ISSN: 2070-1721 R. Barnes
BBN Technologies
B. Rosen
NeuStar, Inc.
R. George
Huawei Technologies
January 2013
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6848 CommScope
Updates: 4776, 5222 M. Thomson
Category: Standards Track Skype
ISSN: 2070-1721 R. Barnes
BBN Technologies
B. Rosen
NeuStar, Inc.
R. George
Huawei Technologies
January 2013
Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
在状态信息数据格式位置对象（PIDF-LO）中指定公民地址扩展
Abstract
摘要
New fields are occasionally added to civic addresses. A backward-compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process.
偶尔会在公民地址中添加新字段。描述了一种向后兼容的机制，用于向Geopriv civic地址格式添加civic地址元素。为需要执行此转换的实体定义了在XML和DHCP civic地址表单之间转换时处理不受支持扩展的正式机制。还定义了一些新元素的初始扩展。澄清了返回用于验证位置信息的civic address元素名称的位置到服务转换（LoST）协议机制（在RFC 5222中定义），并进行了规范性更新，以要求在作为验证过程一部分返回的每个civic address元素上都有一个合格的命名空间标识符。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6848.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6848.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9
5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
5.6. Extension Examples . . . . . . . . . . . . . . . . . . . . 11
6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CAtype Registration for Extensions . . . . . . . . . . . . 13
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
8.4. Registration of the CAtypes Defined in this Document . . . 15
8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
8.6. URN Sub-Namespace Registration . . . . . . . . . . . . . . 17
8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9
5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
5.6. Extension Examples . . . . . . . . . . . . . . . . . . . . 11
6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CAtype Registration for Extensions . . . . . . . . . . . . 13
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
8.4. Registration of the CAtypes Defined in this Document . . . 15
8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
8.6. URN Sub-Namespace Registration . . . . . . . . . . . . . . 17
8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
The Geopriv civic location specifications ([RFC4776], [RFC5139]) define an XML and binary representations for civic addresses that allow for the expression of civic addresses. Guidance for the use of these formats for the civic addresses in different countries is included in [RFC5774].
Geopriv civic location specifications（[RFC4776]、[RFC5139]）定义了civic地址的XML和二进制表示形式，允许表达civic地址。[RFC5774]中包含了不同国家公民地址使用这些格式的指南。
Subsequent to these specifications being produced, use cases for
extending the civic address format with new elements have emerged.
[RFC5774] describes a mechanism for mapping long-standing address
formats into the civic address elements defined in [RFC4776] and
[RFC5139]. However, some of these existing address elements do not
readily fit into the civic address elements defined in [RFC4776] and
[RFC5139]. In these cases, creating new civic address elements
provides a better solution than overloading existing civic address
fields, which may cause confusion.
Subsequent to these specifications being produced, use cases for
extending the civic address format with new elements have emerged.
[RFC5774] describes a mechanism for mapping long-standing address
formats into the civic address elements defined in [RFC4776] and
[RFC5139]. However, some of these existing address elements do not
readily fit into the civic address elements defined in [RFC4776] and
[RFC5139]. In these cases, creating new civic address elements
provides a better solution than overloading existing civic address
fields, which may cause confusion.
The XML format for civic addresses [RFC5139] provides a mechanism that allows for the addition of standardized or privately understood elements. A similar facility for private extension is not provided for the DHCP format [RFC4776], though new specifications are able to define new CAtypes (civic address types).
civic地址的XML格式[RFC5139]提供了一种机制，允许添加标准化或私人理解的元素。DHCP格式[RFC4776]没有提供类似的专用扩展功能，尽管新规范能够定义新的CATYPE（公民地址类型）。
A recipient of a civic address in either format currently has no option other than to ignore elements that it does not understand. This results in any elements that are unknown to that recipient being discarded if a recipient performs a translation between the two formats. In order for a new extension to be preserved through translation by any recipient, the recipient has to understand the extension and know how to correlate an XML element with a CAtype.
任何一种形式的公民地址的接收者目前都别无选择，只能忽略其不理解的内容。如果收件人在两种格式之间执行翻译，则会丢弃收件人未知的任何元素。为了通过任何接收者的翻译来保留新的扩展，接收者必须理解该扩展，并知道如何将XML元素与CAtype关联起来。
This document describes how new civic address elements are added. Extensions always start with the definition of XML elements. A mechanism for carrying the extension in the DHCP format is described. A new XML namespace containing a small number of additional civic elements is also defined and can be used as a template to illustrate how other extensions can be defined as required.
本文档描述了如何添加新的公民地址元素。扩展总是从XML元素的定义开始。描述了以DHCP格式承载扩展的机制。还定义了一个包含少量其他civic元素的新XML名称空间，可以将其用作模板，以说明如何根据需要定义其他扩展。
These mechanisms ensure that any translation between formats can be performed consistently and without loss of information. Translation between formats can occur without knowledge of every extension that is present.
这些机制确保格式之间的任何转换都可以一致地执行，并且不会丢失信息。格式之间的转换可以在不知道存在的每个扩展的情况下进行。
The registry of numeric CAtypes is modified so that the creators of extensions can advertise new namespaces and civic elements to encourage maximum reuse.
修改了数字类型的注册表，以便扩展的创建者可以公布新的名称空间和civic元素，以鼓励最大程度的重用。
The additions described in this document are backwardly compatible. Existing implementations may cause extension information to be lost, but the presence of extensions does not affect an implementation that conforms to either [RFC4776] or [RFC5139].
本文档中描述的添加是向后兼容的。现有实现可能会导致扩展信息丢失，但扩展的存在不会影响符合[RFC4776]或[RFC5139]的实现。
This document also normatively updates [RFC5222] to clarify that the namespace must be included with the element name in the lists of valid, invalid, and not checked elements in the <locationValidation> part of a Location-to-Service Translation (LoST) response. While the LoST schema does not need to be changed, the example in the document is updated to show the namespaces in the lists.
本文档还规范性地更新了[RFC5222]，以澄清名称空间必须与元素名称一起包含在位置到服务转换（丢失）响应的<locationValidation>部分的有效、无效和未检查元素列表中。虽然丢失的模式不需要更改，但文档中的示例将更新以显示列表中的名称空间。
One instance where translation might be necessary is where a device receives location configuration using DHCP [RFC4776]. Conversion of DHCP information to an XML form is necessary if the device wishes to use the DHCP-provided information in a range of applications, including location-based presence services [RFC4079] and emergency calling [RFC5012].
可能需要转换的一个实例是，设备使用DHCP[RFC4776]接收位置配置。如果设备希望在一系列应用中使用DHCP提供的信息，包括基于位置的状态服务[RFC4079]和紧急呼叫[RFC5012]，则需要将DHCP信息转换为XML格式。
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
Figure 1: Conversion Scenario
图1：转换场景
The device that performs the translation between the DHCP and XML formats might not be aware of some of the extensions that are in use. Without knowledge of these extensions and how they are represented in XML, the device is forced to discard them.
执行DHCP和XML格式之间转换的设备可能不知道正在使用的某些扩展。在不知道这些扩展以及它们如何用XML表示的情况下，设备被迫放弃它们。
These extensions could be useful, or may be critical, to the ultimate consumers of this information. For instance, an extension element might provide a presence watcher with important information in locating the device, or an extension might be significant in choosing a particular call route.
这些扩展可能对这些信息的最终消费者有用，也可能至关重要。例如，一个扩展元素可以为状态观察者提供定位设备的重要信息，或者一个扩展元素在选择特定的呼叫路由时可能很重要。
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]中所述进行解释。
The civic schema in [RFC5139] defines an ordered structure of elements that can be combined to describe a civic address. The XML extension point at the end of this sequence is used to extend the address.
[RFC5139]中的思域模式定义了元素的有序结构，这些元素可以组合起来描述思域地址。此序列末尾的XML扩展点用于扩展地址。
New elements are defined in a new XML namespace [XMLNS]. This is true of address elements with significance within private or localized domains as well as those that are intended for global applicability.
新元素在新的XML名称空间[XMLNS]中定义。对于在私有域或本地化域中具有重要意义的地址元素以及用于全局适用性的地址元素，情况也是如此。
New elements SHOULD use the basic "caType" schema type defined in [RFC5139]. This type provides an optional "xml:lang" attribute.
新元素应使用[RFC5139]中定义的基本“caType”模式类型。此类型提供可选的“xml:lang”属性。
For example, suppose the (fictitious) Central Devon Canals Authority wishes to introduce a new civic element called "bridge". The authority defines an XML namespace that includes a "bridge" element. The namespace needs to be a unique URI, for example "http://devon.canals.example.com/civic".
例如，假设（虚构的）德文郡中央运河管理局希望引入一种称为“桥”的新的市民元素。权威机构定义了一个包含“bridge”元素的XML命名空间。名称空间必须是唯一的URI，例如“http://devon.canals.example.com/civic".
A civic address that includes the new "bridge" element is shown in Figure 2.
图2显示了一个包含新“bridge”元素的civicaddress。
<civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cdc="http://devon.canals.example.com/civic">
<country>UK</country>
<A1>Devon</A1>
<A3>Monkokehampton</A3>
<RD>Deckport</RD>
<STS>Cross</STS>
<civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cdc="http://devon.canals.example.com/civic">
<country>UK</country>
<A1>Devon</A1>
<A3>Monkokehampton</A3>
<RD>Deckport</RD>
<STS>Cross</STS>
<cdc:bridge>21451338</cdc:bridge>
<cdc:bridge>21451338</cdc:bridge>
</civicAddress>
</civicAddress>
Figure 2: Extended Civic Address Example
图2：扩展公民地址示例
An entity that receives this location information might not understand the extension address element. As long as the added element is able to be safely ignored, the remainder of the civic address can be used. The result is that the information is not as useful as it could be, but the added element does not prevent the use of the remainder of the address.
接收此位置信息的实体可能不理解扩展地址元素。只要添加的元素能够被安全地忽略，公民地址的其余部分就可以使用。结果是信息没有它可能的那么有用，但是添加的元素并不会阻止使用地址的其余部分。
The address can be passed to other applications, such as a LoST server [RFC5222], without modification. If the application
地址可以传递给其他应用程序，如丢失的服务器[RFC5222]，无需修改。如果应用程序
understands the added element(s), it is able to make use of that information. For example, if this civic address is acquired using HTTP-Enabled Location Delivery (HELD) [RFC5985], it can be included in a LoST request directly.
了解添加的元素，它就能够利用这些信息。例如，如果使用启用HTTP的位置传递（HOLD）[RFC5985]获取该公民地址，则可以将其直接包含在丢失的请求中。
Unsupported civic address elements can be carried without consequence as long as the format of the address does not change. However, conversion between formats has been shown to be necessary.
只要地址的格式不变，不受支持的公民地址元素就可以被携带而不产生任何后果。然而，格式之间的转换已被证明是必要的。
Format conversion requires knowledge of the format of the address elements. An entity performing a conversion between XML and DHCP address formats is forced to discard unrecognized elements. The entity performing the conversion has no way to know the correct element to use in the target format.
格式转换需要了解地址元素的格式。在XML和DHCP地址格式之间执行转换的实体将被迫放弃无法识别的元素。执行转换的实体无法知道要在目标格式中使用的正确元素。
This document defines a single extension element for the DHCP format that makes knowledge of extensions unnecessary during conversion. This extension element relies on the extension mechanisms defined for the XML format. New extensions to the civic address format MUST be defined only for the XML format; these extensions are then conveyed in DHCP using the extension element.
本文档为DHCP格式定义了一个扩展元素，在转换过程中不需要了解扩展。此扩展元素依赖于为XML格式定义的扩展机制。必须仅为XML格式定义civic地址格式的新扩展；然后使用扩展元素在DHCP中传输这些扩展。
Further extensions to the DHCP format are prohibited; these extensions cannot be safely conveyed in environments where conversion is possible.
禁止进一步扩展DHCP格式；这些扩展无法在可能进行转换的环境中安全传输。
Extensions to the XML format [RFC5139] are defined in a new XML namespace [XMLNS]. The XML namespace received in DHCP is expressed as a URL, however, it should not be dereferenced or treated as a source location for the actual schema and doing so will serve no useful purpose.
XML格式[RFC5139]的扩展在新的XML名称空间[XMLNS]中定义。DHCP中接收的XML名称空间表示为URL，但是，不应取消引用或将其视为实际架构的源位置，这样做没有任何用处。
Extensions in the XML format can be added to a DHCP format civic address using an extension CAtype.
可以使用扩展CAtype将XML格式的扩展添加到DHCP格式的civic地址。
The extension CAtype (CAtype code 40) includes three values that uniquely identify the XML extension and its value: a namespace URI, the local name of the XML element, and the text content of that element. These three values are all included in the value of the CAtype, each separated by a single whitespace character.
扩展CAtype（CAtype代码40）包括三个唯一标识XML扩展及其值的值：名称空间URI、XML元素的本地名称以及该元素的文本内容。这三个值都包含在CAtype的值中，每个值由一个空格字符分隔。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAtype (40) | Length | Namespace URI ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Namespace URI (continued) .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | XML element local name .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | Extension type value .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAtype (40) | Length | Namespace URI ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Namespace URI (continued) .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | XML element local name .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | Extension type value .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: XML Civic Address Extension CAtype
图3:XML公民地址扩展CAtype
CAtype (40) identifies the extension CAtype.
CAtype（40）标识扩展CAtype。
Length is the number of octets used to represent the namespace URI, local name, and value. The length includes the space between the namespace URI and local name and the space between the local name and value fields.
Length是用于表示命名空间URI、本地名称和值的八位字节数。长度包括名称空间URI和本地名称之间的空格以及本地名称和值字段之间的空格。
The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. Octets consumed by the namespace URI and local name reduce the space available for values.
CAtype的内容（在CAtype代码和长度之后）是UTF-8编码的Unicode文本[RFC3629]。最多允许255个八位字节。命名空间URI和本地名称使用的八位字节减少了值的可用空间。
This conversion only works for elements that have textual content and an optional "xml:lang" attribute. Elements with complex content or other attributes -- aside from namespace bindings -- MUST be ignored if they are not understood.
此转换仅适用于具有文本内容和可选“xml:lang”属性的元素。如果不理解具有复杂内容或其他属性的元素（除了名称空间绑定），则必须忽略这些元素。
The registration of a new CAtype following the process in [RFC4776] means that a recipient that does not know the equivalent XML is unable to produce a complete XML representation of the DHCP civic address. For this reason, this document ends the registration of new numeric CAtypes. No new registrations of numeric CAtypes can be made.
按照[RFC4776]中的流程注册新的CAtype意味着不知道等效XML的收件人无法生成DHCP civic地址的完整XML表示。因此，本文档将结束新数字类型的注册。无法进行数字类型的新注册。
In lieu of making new numerical CAtype assignments, this document creates a new extensionCA type that is defined in a manner that lets new civic elements be described in DHCP form by carrying the namespace and type name of the extension in parameters of the extensionCA type.
本文档创建了一个新的extensionCA类型，该类型通过在extensionCA类型的参数中携带扩展的名称空间和类型名称，以DHCP形式描述新的civic元素，而不是进行新的数字CAtype分配。
When converting to XML, the namespace prefix used for the extension element is selected by the entity that performs the conversion.
转换为XML时，执行转换的实体将选择用于扩展元素的命名空间前缀。
The following example civic address contains two extensions:
以下示例civic address包含两个扩展名：
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.example.com/ns"
xmlns:ap="http://example.com/airport/5.0">
<country>US</country>
<A1>CA</A1>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.example.com/ns"
xmlns:ap="http://example.com/airport/5.0">
<country>US</country>
<A1>CA</A1>
<post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon>
<post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
Figure 4: XML Example with Multiple Extensions
图4：具有多个扩展的XML示例
This is converted to a DHCP form as follows:
这将转换为DHCP格式，如下所示：
country = US
CAtype[0] = en-US
CAtype[1] = CA
CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471
CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
CAtype[40] = http://example.com/airport/5.0 airport LAX
CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley
CAtype[40] = http://example.com/airport/5.0 concourse G
CAtype[40] = http://example.com/airport/5.0 gate 36B
country = US
CAtype[0] = en-US
CAtype[1] = CA
CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471
CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
CAtype[40] = http://example.com/airport/5.0 airport LAX
CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley
CAtype[40] = http://example.com/airport/5.0 concourse G
CAtype[40] = http://example.com/airport/5.0 gate 36B
Figure 5: Converted DHCP Example with Multiple Extensions
图5：具有多个扩展的已转换DHCP示例
[RFC4776] created the CAtype registry. Among other things, this registry advertised available civic elements. While it has always been possible to use an extension namespace to define civic elements that are not in the CAtype registry, and this document does not change that, the registry is valuable to alert implementors of commonly used civic elements and provides guidance to clients of what elements they should support.
[RFC4776]创建了CAtype注册表。除其他事项外，该登记处还公布了可用的公民要素。虽然始终可以使用扩展名称空间来定义不在CAtype注册表中的civic元素，并且本文档并没有改变这一点，但是注册表对于提醒实现者常用的civic元素并为客户端提供他们应该支持的元素的指导是很有价值的。
This document alters the CAtype registry in several ways. It closes the registry to new numeric CAtypes. It deletes the "NENA" column, which is not needed. It adds columns for a namespace and contact, and changes the name of the column currently called "PIDF" to "Local Name". It also adds a column to the registry called "Type". "Type" can have one of two values "A" and "B". Type A elements are intended for wide use with many applications and SHOULD be implemented by all clients unless the client is certain the element will not be encountered. Type B civic elements MAY be implemented by any client.
本文档以几种方式更改CAtype注册表。它会关闭注册表，以创建新的数字类型。它删除了不需要的“NENA”列。它为名称空间和联系人添加列，并将当前称为“PIDF”的列的名称更改为“Local name”。它还向注册表添加了一个名为“Type”的列。“类型”可以有两个值“A”和“B”中的一个。类型A元素旨在广泛用于许多应用程序，并且应该由所有客户端实现，除非客户端确定不会遇到该元素。B类civic元素可由任何客户实施。
Type A civic elements require IETF review, while Type B elements only require an expert review.
A类公民要素需要IETF审查，而B类要素只需要专家审查。
We use this new extension method to define some additional civic address elements that are needed to correctly encode civic locations in several countries. The definition of these new civic address elements also serves as an example of how to define additional elements using the mechanisms described in this document.
我们使用这种新的扩展方法来定义一些额外的公民地址元素，这些元素是在几个国家正确编码公民地址所必需的。这些新的市政地址元素的定义也是如何使用本文件所述机制定义其他元素的示例。
In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the label on the lamp post also carries the local emergency service number, such as "110", encouraging callers to use the pole number to identify their location.
在某些地区，公用设施和灯柱带有唯一标识符，我们在本文件中称之为极号。在一些国家，灯柱上的标签上还印有当地紧急服务号码，如“110”，鼓励呼叫者使用杆位号码来确定自己的位置。
_.-----,===.
| | (''''')
| | `---'
| |
| | ,---------,
| | ,---, |Emergency|
| | /|,-.|----->| Number |
| | / |110| '---------'
| | / |`-'|
|_|/ | 2 | ,---------,
| | | 1 | |Lamp Post|
| | | 2 |----->| Number |
|-| | 1 | '---------'
| |\ | 0 |
| | \ | 1 |
| | \ | 4 |
| | \|,,,|
_ | |
``-..|.|
``--.._
`'--.._
_.-----,===.
| | (''''')
| | `---'
| |
| | ,---------,
| | ,---, |Emergency|
| | /|,-.|----->| Number |
| | / |110| '---------'
| | / |`-'|
|_|/ | 2 | ,---------,
| | | 1 | |Lamp Post|
| | | 2 |----->| Number |
|-| | 1 | '---------'
| |\ | 0 |
| | \ | 1 |
| | \ | 4 |
| | \|,,,|
_ | |
``-..|.|
``--.._
`'--.._
Figure 6: Lamp Post with Emergency Number
图6：带有紧急编号的灯柱
On some roads, trails, railroad rights of way, and other linear features, a post with a mile or kilometer distance from one end of the feature may be found (a "milepost"). There are other cases of poles or markers with numeric indications that are not the same as a "house number" or street address number.
在一些道路、小径、铁路路权和其他线性特征上，可以找到一个距离特征一端一英里或一公里的标杆（“里程碑”）。还有一些带有数字指示的电杆或标记与“门牌号”或街道地址号不同。
The civic schema defined in [RFC5139] allows the definition of address "123 Colorado Boulevard", but it does not allow for the easy expression of "123 Boulevard Colorado". Adding a street type prefix, allows a street named in this manner to be more easily represented.
[RFC5139]中定义的civic模式允许定义地址“123 Colorado Boulevard”，但不允许轻松表达“123 Boulevard Colorado”。添加街道类型前缀，可以更容易地表示以这种方式命名的街道。
The civic schema defined in [RFC5139] provides a house number suffix element, allowing one to express an address like "123A Main Street", but it does not contain a corresponding house number prefix. The house number prefix element allows the expression of address such as "Z123 Main Street".
[RFC5139]中定义的civic模式提供了一个门牌号后缀元素，允许表示类似“123A Main Street”的地址，但它不包含相应的门牌号前缀。门牌号前缀元素允许表达地址，如“Z123 Main Street”。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
<xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
<!-- Post Number -->
<xs:element name="PN" type="ca:caType"/>
<!-- Post Number -->
<xs:element name="PN" type="ca:caType"/>
<!-- Milepost -->
<xs:element name="MP" type="ca:caType"/>
<!-- Milepost -->
<xs:element name="MP" type="ca:caType"/>
<!-- Street Type Prefix -->
<xs:element name="STP" type="ca:caType"/>
<!-- Street Type Prefix -->
<xs:element name="STP" type="ca:caType"/>
<!-- House Number Prefix -->
<xs:element name="HNP" type="ca:caType"/>
<!-- House Number Prefix -->
<xs:element name="HNP" type="ca:caType"/>
</xs:schema>
</xs:schema>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>I5</RD>
<cae:MP>248</cae:MP>
<cae:PN>22-109-689</cae:PN>
</civicAddress>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>I5</RD>
<cae:MP>248</cae:MP>
<cae:PN>22-109-689</cae:PN>
</civicAddress>
Figure 7: XML Example with Post Number and Milepost
图7：带有邮政编码和里程标的XML示例
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>Colorado</RD>
<HNO>223</HNO>
<cae:STP>Boulevard</cae:STP>
<cae:HNP>A</cae:HNP>
</civicAddress>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>Colorado</RD>
<HNO>223</HNO>
<cae:STP>Boulevard</cae:STP>
<cae:HNP>A</cae:HNP>
</civicAddress>
Figure 8: XML Example with Street Type Prefix and House Number Prefix
图8：带有街道类型前缀和门牌号前缀的XML示例
One critical use of civic location information is in next generation emergency services applications, in particular, call routing applications. In such cases, location information is provided to a location-based routing service using the LoST protocol [RFC5222]. LoST is used to provide call routing information, but it is also used to validate location information to ensure that it can route to an emergency center when required.
市民位置信息的一个关键用途是在下一代紧急服务应用程序中，特别是呼叫路由应用程序中。在这种情况下，使用丢失协议[RFC5222]向基于位置的路由服务提供位置信息。LoST用于提供呼叫路由信息，但也用于验证位置信息，以确保在需要时可以路由到应急中心。
LoST is an XML-based protocol, and so the namespace extension mechanisms described in this document do not impact LoST. When LoST is used for validation, a <locationValidation> element is returned containing a list of valid, a list of invalid, and a list of unchecked civic elements. Figure 9 is an extract of the validation response in Figure 6 from [RFC5222].
LoST是一个基于XML的协议，因此本文档中描述的命名空间扩展机制不会影响LoST。当LoST用于验证时，将返回一个<locationValidation>元素，其中包含有效元素列表、无效元素列表和未检查元素列表。图9是从[RFC5222]中摘录的图6中的验证响应。
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
Figure 9: Location Validation Example from LoST (RFC5222)
图9：丢失的位置验证示例（RFC5222）
The RelaxNG schema in [RFC5222] requires the elements in each of these lists to be namespace qualified, which makes the example in Figure 6 of [RFC5222] erroneous. This issue is especially significant when local-civic extensions are used as the domain to which the extensions are attributed may impact their interpretation by the server or client. To ensure that local-civic extensions do not cause issues with the LoST server and client implementations, all
[RFC5222]中的RelaxNG模式要求这些列表中的每个元素都是命名空间限定的，这使得图6中的[RFC5222]示例是错误的。当将本地civic扩展用作扩展所属的域时，此问题尤其重要，可能会影响服务器或客户端对其的解释。为了确保本地civic扩展不会导致丢失的服务器和客户端实现出现问题，所有
elements listed in a <valid>, <invalid>, or <unchecked> element MUST be qualified with a namespace. To illustrate this, the extract above from Figure 6 in [RFC5222] becomes Figure 10.
在<valid>、<invalid>或<unchecked>元素中列出的元素必须使用命名空间限定。为了说明这一点，[RFC5222]中图6的上述摘录变成了图10。
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<valid>ca:country ca:A1 ca:A3 ca:A6</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO</unchecked>
</locationValidation>
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<valid>ca:country ca:A1 ca:A3 ca:A6</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO</unchecked>
</locationValidation>
Figure 10: Corrected Location Validation Example
图10：更正的位置验证示例
If a validation request has also included the extensions defined in Section 5, then the validation response would look like Figure 11.
如果验证请求还包括第5节中定义的扩展，那么验证响应将如图11所示。
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO cae:MP cae:HNP</unchecked>
</locationValidation>
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO cae:MP cae:HNP</unchecked>
</locationValidation>
Figure 11: Corrected Location Validation Example
图11：更正的位置验证示例
This document defines a formal way to extend the existing Geopriv civic address schema. While no security threats are directly introduced by this document, creators of new civic address extensions should refer to Sections 4.3.1 and 5.1 of [RFC3694] to understand the environments in which these new elements will be used. New elements should only be registered if the person or organization performing the registration understands any associated risks.
本文档定义了扩展现有Geopriv civic地址模式的正式方法。虽然本文件未直接引入任何安全威胁，但新公民地址扩展的创建者应参考[RFC3694]第4.3.1节和第5.1节，以了解使用这些新元素的环境。仅当执行注册的人员或组织了解任何相关风险时，才应注册新元素。
Security threats applicable to the civic address formats are described in [RFC4776] DHCP and [RFC5139] XML.
[RFC4776]DHCP和[RFC5139]XML中描述了适用于civic地址格式的安全威胁。
This document alters the "CAtypes" registry in the Civic Address Types Registry established by [RFC4776].
本文件修改了[RFC4776]建立的公民地址类型注册表中的“CAtypes”注册表。
IANA has allocated a CAtype code of 40 for the extension CAtype. Registrations using this code will be made below, in Section 8.4.
IANA已为扩展CAtype分配了CAtype代码40。使用本代码的注册将在下文第8.4节中进行。
IANA has made the following changes to the CAtype registry:
IANA对CAtype注册表进行了以下更改：
o No registrations of new CAtype numbers in the Civic Address Types Registry are permitted, except by IESG Approval [RFC5226] under unusual circumstances.
o 除非在特殊情况下获得IESG批准[RFC5226]，否则不允许在公民地址类型注册中心注册新的CAtype号码。
o The following note has been placed in the header of the CAtypes registry, above the table:
o 以下注释已放置在表上方的CAtypes注册表的标题中：
Note: As specified in RFC 6848, new registrations are only accepted for CAtype 40, using the template specified in Section 8.3.
注：按照RFC 6848的规定，使用第8.3节规定的模板，仅接受CAtype 40的新注册。
o The registration procedures are changed: IETF Review (if Type=A), Expert Review (if Type=B). The designated expert is unchanged.
o 注册程序更改：IETF审查（如果类型为A）、专家审查（如果类型为B）。指定专家不变。
o The reference for the table is changed: [RFC4776], RFC 6848
o 表的参考已更改：[RFC4776]，RFC 6848
o The column called "NENA" is removed.
o 名为“NENA”的列被删除。
o The column called "PIDF" is renamed to "Local Name".
o 名为“PIDF”的列重命名为“本地名称”。
o New columns are added named "Namespace URI", "Contact", "Schema" and "Type". All existing entries will have the following values for those new columns:
o 添加了名为“名称空间URI”、“联系人”、“架构”和“类型”的新列。对于这些新列，所有现有条目将具有以下值：
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Type: A
类型：A
New registrations in the Civic Address Types Registry require the following information:
公民地址类型注册中心的新注册需要以下信息：
CAtype: The assigned numeric CAtype. All new registrations will use the value 40.
CAtype：指定的数字CAtype。所有新注册将使用值40。
Namespace URI: A unique identifier for the XML namespace used for the extension element.
命名空间URI：用于扩展元素的XML命名空间的唯一标识符。
Local Name: The local name of an XML element that carries the civic address element.
Local Name：携带civic address元素的XML元素的本地名称。
Description: A brief description of the semantics of the civic address element.
描述：对civicaddress元素语义的简要描述。
Example (optional): One or more simple examples of the element.
示例（可选）：元素的一个或多个简单示例。
Contact: Contact details for the person providing the extension.
联系人：提供扩展的人员的详细联系方式。
Specification (optional): A reference to a specification for the civic address element.
规范（可选）：对civic address元素规范的引用。
Schema (optional): A reference to a formal schema (XML schema, RelaxNG, or other form) that defines the extension.
Schema（可选）：对定义扩展的正式模式（xmlschema、RelaxNG或其他形式）的引用。
Type: "A" or "B". If Type is "A", all clients SHOULD implement this element. If Type is "B", clients MAY implement this element.
类型：“A”或“B”。如果类型为“A”，则所有客户端都应实现此元素。如果类型为“B”，则客户端可以实现此元素。
This section registers the following four new CAtypes in the Civic Address Types Registry.
本节在Civic地址类型注册表中注册以下四种新类型。
Post Number (see Section 5.1):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: PN
Description: Post number that is attributed to a lamp post or
utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Post Number (see Section 5.1):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: PN
Description: Post number that is attributed to a lamp post or
utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Milepost (see Section 5.2):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP
Description: Milepost: a marker indicating distance to or from a
place (often a town).
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Milepost (see Section 5.2):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP
Description: Milepost: a marker indicating distance to or from a
place (often a town).
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Street Type Prefix (see Section 5.3):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP
Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Street Type Prefix (see Section 5.3):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP
Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
House Number Prefix (see Section 5.4):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP
Description: House Number Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
House Number Prefix (see Section 5.4):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP
Description: House Number Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
The "CAtypes" registry is altered to operate on a registration policy of "Expert Review", and optionally "Specification Required" [RFC5226] if the element being registered has a Type value of "B".
“CAtypes”注册表更改为按照“专家评审”的注册策略操作，如果注册的元素的类型值为“B”，则可选择“所需规范”[RFC5226]。
The registration rules for "Specification Required" are followed only if a registration includes a reference to a specification. Registrations can be made without a specification reference.
仅当注册包括对规范的引用时，才遵循“所需规范”的注册规则。注册可以在没有规范参考的情况下进行。
If the element being registered has a Type value of "A", then the registration policy is "IETF Review" [RFC5226].
如果正在注册的元素的类型值为“a”，则注册策略为“IETF审查”[RFC5226]。
All registrations are reviewed to identify potential duplication between registered elements. Duplicated semantics are not prohibited in the registry, though it is preferred if existing elements are used. The expert review is advised to recommend the use of existing elements following the guidance in [RFC5774]. Any registration that is a duplicate or could be considered a close match for the semantics of an existing element SHOULD include a discussion of the reasons that the existing element was not reused.
审查所有注册，以确定注册元素之间的潜在重复。注册表中不禁止重复语义，但如果使用现有元素，则首选重复语义。建议专家评审按照[RFC5774]中的指南建议使用现有元件。任何重复的注册或可以被认为与现有元素的语义非常匹配的注册都应该包括对现有元素未被重用原因的讨论。
[RFC6280] provides a comprehensive framework concerning the privacy of location information as pertaining to its use in Internet applications. The expert reviewer is asked to keep the spirit of this document in mind when reviewing new CAtype registrations.
[RFC6280]提供了一个关于位置信息在互联网应用中使用的隐私的综合框架。请专家评审员在评审新的CAtype注册时牢记本文件的精神。
IANA has registered a new XML namespace, as per the guidelines in [RFC3688].
IANA已根据[RFC3688]中的指南注册了一个新的XML名称空间。
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com)
注册人联系人：IETF GEOPRIV工作组(geopriv@ietf.org)，詹姆斯·温特巴顿（詹姆斯。Winterbottom@commscope.com)
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Civic Address Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt">
RFC 6848</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Civic Address Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt">
RFC 6848</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the procedures in [RFC3688].
本节按照[RFC3688]中的步骤注册XML模式。
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com)
注册人联系人：IETF GEOPRIV工作组(geopriv@ietf.org)，詹姆斯·温特巴顿（詹姆斯。Winterbottom@commscope.com)
XML: The XML for this schema can be found as the entirety of Section 5.5 of this document.
XML：此模式的XML可作为本文档第5.5节的完整内容找到。
Thanks to anyone who has tried to extend the civic schema and found it a little less than intuitive.
感谢那些试图扩展公民模式的人，他们发现这有点不直观。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3694]Danley，M.，Mulligan，D.，Morris，J.，和J.Peterson，“Geopriv协议的威胁分析”，RFC 3694，2004年2月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776]Schulzrinne，H.，“Civic地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 4776，2006年11月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139]Thomson，M.和J.Winterbottom，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 5139，2008年2月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, "Namespaces in XML 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[XMLNS]Hollander，D.，Layman，A.，Tobin，R.，和T.Bray，“XML 1.1中的名称空间（第二版）”，万维网联盟建议REC-XML-names11-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
[RFC4079]Peterson，J.，“GEOPRIV定位对象分布的存在架构”，RFC 4079，2005年7月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012]Schulzrinne，H.和R.Marshall，“利用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition", BCP 154, RFC 5774, March 2010.
[RFC5774]Wolf，K.和A.Mayrhofer，“存在信息数据格式位置对象（PIDF-LO）中公民地址的注意事项：指南和IANA注册表定义”，BCP 154，RFC 5774，2010年3月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
Authors' Addresses
作者地址
James Winterbottom CommScope Suit 1, Level 2 iC Enterprise 1, Innovation Campus Squires Way North Wollongong, NSW 2500 AU
James Winterbottom康普西服1，新南威尔士州卧龙岗北部创新校园Squires路2级iC企业1，邮编：2500 AU
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Martin Thomson Skype 3210 Porter Drive Palo Alto, CA 94304 US
美国加利福尼亚州帕洛阿尔托波特大道3210号马丁·汤姆森Skype邮编94304
EMail: martin.thomson@gmail.com
EMail: martin.thomson@gmail.com
Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US
Richard Barnes BBN Technologies 9861美国马里兰州哥伦比亚市布罗克兰大道21046号
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US
布莱恩·罗森·纽斯塔公司，美国宾夕法尼亚州康拉德·马尔斯博士，邮编：16046
EMail: br@brianrosen.net
EMail: br@brianrosen.net
Robins George Huawei Technologies Huawei Base, Bantian, Longgan District Shenzhen, Guangdong 518129 P. R. China
中国广东省深圳市龙岗区坂田罗宾斯乔治华为技术有限公司华为基地邮编：518129
Phone: +86 755 2878 8314
EMail: robinsgv@gmail.com
Phone: +86 755 2878 8314
EMail: robinsgv@gmail.com