Network Working Group H. Schulzrinne
Request for Comments: 4676 Columbia U.
Category: Standards Track October 2006
Network Working Group H. Schulzrinne
Request for Comments: 4676 Columbia U.
Category: Standards Track October 2006
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
用于Civic地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.
本文档指定了一个动态主机配置协议（DHCPv4和DHCPv6）选项，其中包含客户端或DHCP服务器的位置。位置配置信息（LCI）包括有关国家、行政单位（如州、省和市）的信息，以及街道地址、邮政社区名称和建筑信息。该选项允许以不同的脚本和语言对同一地址进行多个格式副本。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Format of the DHCP Civic Location Option ........................5
3.1. Overall Format for DHCPv4 ..................................5
3.2. Overall Format for DHCPv6 ..................................6
3.3. Element Format .............................................6
3.4. Civic Address Components ...................................7
4. Postal Addresses ...............................................13
5. Example ........................................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................17
Acknowledgements ..................................................17
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Format of the DHCP Civic Location Option ........................5
3.1. Overall Format for DHCPv4 ..................................5
3.2. Overall Format for DHCPv6 ..................................6
3.3. Element Format .............................................6
3.4. Civic Address Components ...................................7
4. Postal Addresses ...............................................13
5. Example ........................................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................17
Acknowledgements ..................................................17
Many end system services can benefit by knowing the approximate location of the end device. In particular, IP telephony devices need to know their location to contact the appropriate emergency response agency and to be found by emergency responders.
许多终端系统服务可以通过了解终端设备的大致位置而受益。特别是，IP电话设备需要知道其位置，以便联系相应的应急响应机构，并由应急响应人员找到。
There are two common ways to identify the location of an object, either through geospatial coordinates or by so-called civic addresses. Geospatial coordinates indicate longitude, latitude, and altitude, while civic addresses indicate a street address.
通过地理空间坐标或所谓的公民地址，有两种常用的方法来确定物体的位置。地理空间坐标表示经度、纬度和海拔，而城市地址表示街道地址。
The civic address is commonly, but not necessarily, closely related to the postal address, used by the local postal service to deliver mail. However, not all postal addresses correspond to street addresses. For example, the author's address is a postal address that does not appear on any street or building sign. Naturally, post office boxes would be unsuitable for the purposes described here. The term 'civil address' or 'jurisdictional address' is also sometimes used instead of civic address. This document mainly supports civic addresses, but allows the postal community name to be indicated if it differs from the civic name.
公民地址通常（但不一定）与邮政地址密切相关，由当地邮政服务部门用于投递邮件。然而，并非所有的邮政地址都与街道地址相对应。例如，作者的地址是没有出现在任何街道或建筑标志上的邮政地址。当然，邮政信箱不适合这里描述的用途。“公民地址”或“管辖地址”有时也用来代替公民地址。本文档主要支持公民地址，但如果邮政社区名称与公民名称不同，则允许显示邮政社区名称。
A related document [15] describes a DHCPv4 [2] option for conveying geospatial information to a device. This document describes how DHCPv4 and DHCPv6 [6] can be used to convey the civic and postal address to devices. Both geospatial and civic formats can be used simultaneously, increasing the chance to deliver accurate and timely location information to emergency responders. The reader should also be familiar with the concepts in [11], as many of the protocol elements below are designed to dovetail with PIDF-LO elements.
相关文档[15]描述了用于将地理空间信息传送到设备的DHCPv4[2]选项。本文档描述了如何使用DHCPv4和DHCPv6[6]将公民和邮政地址传送到设备。地理空间和民用格式可以同时使用，增加了向应急响应人员提供准确及时位置信息的机会。读者还应该熟悉[11]中的概念，因为下面的许多协议元素都是为配合PIDF-LO元素而设计的。
This document only defines the delivery of location information from the DHCP server to the client, due to security concerns related to using DHCP to update the database. Within the GEOPRIV architecture as defined by RFC 3693 [9], the defined mechanism in this document for conveying initial location information is known as a "sighting" function. Sighting functions are not required to have security capabilities and are only intended to be configured in trusted and controlled environments. (A classic example of the sighting function is a Global Positioning System wired directly to a network node.) Further discussion of the protections that must be provided according to RFC 3694 [10] are in the Security Considerations (Section 6).
由于与使用DHCP更新数据库相关的安全问题，本文档仅定义从DHCP服务器到客户端的位置信息传递。在RFC 3693[9]定义的GEOPRIV架构内，本文件中定义的用于传输初始位置信息的机制称为“瞄准”功能。瞄准功能不需要具备安全功能，仅用于在受信任和受控的环境中进行配置。（瞄准功能的一个典型示例是直接连接到网络节点的全球定位系统。）关于必须根据RFC 3694[10]提供的保护的进一步讨论见安全注意事项（第6节）。
End systems that obtain location information via the mechanism described here then use other protocol mechanisms to communicate this information to an emergency call center or to convey it as part of presence information.
通过此处描述的机制获取位置信息的终端系统然后使用其他协议机制将该信息传达给紧急呼叫中心或将其作为存在信息的一部分进行传递。
Civic information is useful since it often provides additional, human-usable information, particularly within buildings. Also, compared to geospatial information, it is readily obtained for most occupied structures and can often be interpreted even if incomplete. For example, for many large university or corporate campuses, geocoding information to building and room granularity may not be readily available.
公民信息很有用，因为它通常提供额外的、人类可用的信息，特别是在建筑物内。此外，与地理空间信息相比，对于大多数被占用的结构来说，它很容易获得，而且即使不完整，也常常可以解释。例如，对于许多大型大学或企业校园，建筑物和房间粒度的地理编码信息可能并不容易获得。
Unlike geospatial information, the format for civic and postal information differs from country to country. The initial set of data fields is derived from standards published by the United States National Emergency Number Association (NENA) [18] and takes into account addressing conventions for a number of countries in different areas of the world. It is anticipated that other countries can reuse many of the data elements, but the document also establishes an IANA registry for defining additional civic location data fields.
与地理空间信息不同，公民和邮政信息的格式因国家而异。初始数据字段集源自美国国家紧急情况号码协会（NENA）[18]发布的标准，并考虑到世界不同地区许多国家的相关公约。预计其他国家可以重复使用许多数据元素，但该文件还建立了IANA登记册，用于定义其他城市位置数据字段。
The same civic and postal address information can often be rendered in multiple languages and scripts. For example, Korean addresses are often shown in Hangul, Latin, and Kanji, while some older cities have multiple language variants (e.g., Munich, Muenchen, and Monaco). Since DHCPv4 and DHCPv6 do not currently support a mechanism to query for a specific script or language, the DHCP server SHOULD provide all common renderings to the client and MUST provide at least the rendering in the language and script appropriate to the location indicated. For example, for use in presence information, the target may be visiting from a foreign country and want to convey the information in a format suitable for watchers in its home country. For emergency services, the rendering in the local language is likely to be most appropriate. To provide multiple renderings, the server repeats sequences of address elements, prefixing each with a 'language' and/or 'script' element (see Section 3.3). The language and script remain in effect for subsequent elements until overridden by another language or script element. Since the DHCP client is unlikely to be the final consumer of the location information, the DHCP server has to provide all appropriate language and script versions, which the client then passes on via some other GEOPRIV using protocol, typically encoded in a presence-based GEOPRIV location object format [16].
相同的公民和邮政地址信息通常可以用多种语言和脚本呈现。例如，韩语地址通常以韩语、拉丁语和汉字显示，而一些较老的城市有多种语言变体（如慕尼黑、慕尼黑和摩纳哥）。由于DHCPv4和DHCPv6目前不支持查询特定脚本或语言的机制，因此DHCP服务器应向客户端提供所有通用呈现，并且必须至少提供适合指定位置的语言和脚本呈现。例如，为了在状态信息中使用，目标可能是从外国访问的，并且希望以适合其本国观察者的格式传达信息。对于紧急服务，以当地语言呈现可能是最合适的。为了提供多个呈现，服务器重复地址元素序列，在每个元素前面加上“语言”和/或“脚本”元素（参见第3.3节）。在被其他语言或脚本元素覆盖之前，该语言和脚本对后续元素保持有效。由于DHCP客户端不太可能是位置信息的最终使用者，DHCP服务器必须提供所有适当的语言和脚本版本，然后客户端使用协议（通常以基于状态的GEOPRIV位置对象格式编码）通过其他GEOPRIV传递这些语言和脚本版本[16]。
The DHCP server MAY provide location information for multiple locations related to the target, for example, both the network element and the network jack itself. This is likely to help in debugging network problems, for example.
DHCP服务器可以提供与目标相关的多个位置的位置信息，例如，网元和网络插孔本身。例如，这可能有助于调试网络问题。
This document calls for various operational decisions. For example, an administrator has to decide when to provide the location of the DHCP server or other network elements even if these may be a good
本文件要求作出各种运营决策。例如，管理员必须决定何时提供DHCP服务器或其他网络元素的位置，即使这些可能是一个好方法
distance away from the client. The administrator must also consider whether to include both civic and geospatial information if these may differ. The document does not specify the criteria to be used in making these choices, as these choices are likely to depend strongly on local circumstances and need to be based on local, human knowledge.
与客户的距离。管理员也必须考虑是否包括公民和地理空间信息，如果这些可能不同。该文件没有具体说明作出这些选择时所采用的标准，因为这些选择可能在很大程度上取决于当地情况，并且需要以当地人的知识为基础。
A system that works with location information configured by DHCP is dependent that the administrators of the DHCP systems are careful enough on a number of fronts, such as:
使用DHCP配置的位置信息的系统取决于DHCP系统的管理员在许多方面是否足够小心，例如：
- if information about one location is provided in multiple forms (e.g., in multiple languages), is it consistent?
- 如果一个地点的信息以多种形式提供（例如，以多种语言提供），是否一致？
- is the administrator certain that location information is configured only to systems to which it applies (e.g., not to systems topologically near, but geographically far)?
- 管理员是否确定位置信息仅配置到其应用的系统（例如，不是拓扑上靠近的系统，而是地理上远离的系统）？
- if the location configured is not that of the target but that of a 'nearby' network node or the DHCP server, despite the recommendation against this practice in Section 3.1, is the administrator certain that this configuration is geographically valid?
- 如果配置的位置不是目标位置，而是“附近”网络节点或DHCP服务器的位置，尽管第3.1节中建议不使用此做法，管理员是否确定此配置在地理上有效？
There are many other considerations in ensuring that location information is handled safely and promptly for an emergency service in particular. Those are in the province of the applications which make use of the configured location information, and they are beyond the scope of this document. DHCP configuration SHOULD NOT be used for emergency services without guidelines on these considerations. Work on these is under way in the IETF ECRIT working group at the time of publication of this document.
特别是在紧急服务中，在确保安全、及时地处理位置信息时，还有许多其他考虑因素。这些在使用配置的位置信息的应用程序的范围内，不在本文档的范围内。如果没有关于这些注意事项的指导原则，DHCP配置不应用于紧急服务。在本文件出版时，IETF ECRIT工作组正在进行这些方面的工作。
In addition, if a network provides civic location information via both DHCPv4 and DHCPv6, the information conveyed by two protocols MUST be the same.
此外，如果网络通过DHCPv4和DHCPv6提供市民位置信息，则两个协议传递的信息必须相同。
As discussed in the Security Considerations (Section 6), the GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when the DHCPv4 client has included this option in its 'parameter request list' (RFC 2131 [2], Section 3.5). Similarly, the OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only when the DHCPv6 client has included this option in its OPTION_ORO.
如安全注意事项（第6节）中所述，只有当DHCPv4客户端将此选项包括在其“参数请求列表”（RFC 2131[2]，第3.5节）中时，DHCPv4服务器才应返回GEOCONF_CIVIC选项。类似地，只有当DHCPv6客户机将此选项包含在其选项\u ORO中时，DHCPv6服务器才应返回选项\u GEOCONF\u CIVIC选项。
The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be used if the civic address option exceeds the maximum DHCPv4 option size of 255 octets.
如果civic address选项超过最大DHCPv4选项大小255个八位字节，则必须使用RFC 3396[8]中描述的DHCPv4长选项机制。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释，并指出符合性实施的要求级别。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEOCONF_CIVIC | N | what | country |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | civic address elements ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEOCONF_CIVIC | N | what | country |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | civic address elements ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code GEOCONF_CIVIC: The code for this DHCP option is 99.
代码GEOCONF_CIVIC：此DHCP选项的代码为99。
N: The length of this option is variable. The minimum length is 3 octets.
N:此选项的长度是可变的。最小长度为3个八位字节。
what: The 'what' element describes to which location the DHCP entry refers. Currently, three options are defined: the location of the DHCP server (a value of 0), the location of the network element believed to be closest to the client (a value of 1), or the location of the client (a value of 2). Option (2) SHOULD be used, but may not be known. Options (0) and (1) SHOULD NOT be used unless it is known that the DHCP client is in close physical proximity to the server or network element.
what:“what”元素描述DHCP条目引用的位置。目前，定义了三个选项：DHCP服务器的位置（值为0）、据信最靠近客户端的网元的位置（值为1）或客户端的位置（值为2）。应使用选项（2），但可能未知。不应使用选项（0）和（1），除非知道DHCP客户端与服务器或网络元素在物理上非常接近。
country code: The two-letter ISO 3166 country code in capital ASCII letters, e.g., DE or US. (Civic addresses always contain country designations, suggesting the use of a fixed-format field to save space.)
国家代码：两个字母的ISO 3166国家代码，大写ASCII字母，例如DE或US。（公民地址始终包含国家名称，建议使用固定格式字段以节省空间。）
civic address elements: Zero or more elements comprising the civic and/or postal address, with the format described below (Section 3.3).
公民地址元素：包含公民和/或邮政地址的零个或多个元素，格式如下所述（第3.3节）。
The DHCPv6 [6] civic address option refers generally to the client as a whole.
DHCPv6[6]civic address选项通常指的是整个客户端。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_GEOCONF_CIVIC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| what | country code | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. civic address elements .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_GEOCONF_CIVIC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| what | country code | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. civic address elements .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_GEOCONF_CIVIC (37)
选项代码：选项地理配置公民（37）
option-len: Length of the Countrycode, 'what' and civic address elements in octets.
选项len:Countrycode、“what”和civicaddress元素的长度（以八位字节为单位）。
what: See above (Section 3.1).
内容：见上文（第3.1节）。
country code: See above (Section 3.1).
国家代码：见上文（第3.1节）。
civic address elements: See above (Section 3.1).
公民地址要素：见上文（第3.1节）。
For both DHCPv4 and DHCPv6, each civic address element has the following format:
对于DHCPv4和DHCPv6，每个civic address元素都具有以下格式：
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 | CAlength | CAvalue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | CAlength | CAvalue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAtype: A one-octet descriptor of the data civic address value.
CAtype：数据地址值的一个八位描述符。
CAlength: The length, in octets, of the CAvalue, not including the CAlength field itself.
日历长度：卡瓦鲁的长度，以八位字节为单位，不包括日历长度字段本身。
CAvalue: The civic address value, as described in detail below.
CAvalue：公民地址值，如下所述。
Since each country has different administrative hierarchies, with often the same (English) names, this specification adopts a simple hierarchical notation that is then instantiated for each country. We assume that five levels are sufficient for sub-national divisions above the street level.
由于每个国家都有不同的管理层次结构，通常具有相同的（英文）名称，因此本规范采用简单的层次表示法，然后为每个国家实例化。我们假设五个级别足以满足街道级别以上的次国家级划分。
All elements are OPTIONAL and can appear in any order.
所有元素都是可选的，可以以任何顺序显示。
Component values MUST be encoded as UTF-8 [7]. They SHOULD be written in mixed case, following the customary spelling. The script indication (CAtype 128) MUST be written in mixed case, with the first letter a capital letter.
组件值必须编码为UTF-8[7]。它们应该按照习惯的拼写，混合使用大小写。脚本指示（CAtype 128）必须混合使用大小写，第一个字母为大写字母。
Abbreviations MUST NOT be used unless indicated for each element. Abbreviations do not need a trailing period.
除非为每个元素指定，否则不得使用缩写。缩写不需要尾随句点。
It is RECOMMENDED that all elements in a particular script (CAtype 128) and language (CAtype 0) be grouped together, as that reduces the number of script and language identifiers needed.
建议将特定脚本（CAtype 128）和语言（CAtype 0）中的所有元素分组在一起，因为这样可以减少所需的脚本和语言标识符的数量。
For each script and language, elements SHOULD be included in numeric order from lowest to highest of their CAtype. In general, an element is labeled in its language and script by the most recent 'language tag' (CAtype ) element preceding it. Since not all elements depend on the script and language, a client accumulates the elements by CAtype and then selects the most desirable language and script rendition if there are multiple elements for the same CAtype.
对于每种脚本和语言，元素应按从其CAtype的最低到最高的数字顺序包含。通常，元素在其语言和脚本中由其前面最新的“语言标记”（CAtype）元素标记。由于并非所有元素都依赖于脚本和语言，因此客户端会按CAtype累加元素，然后如果同一CAtype有多个元素，则会选择最理想的语言和脚本格式副本。
+--------+-------+--------------------------------------------------+
| CAtype | label | description |
+--------+-------+--------------------------------------------------+
| 1 | A1 | national subdivisions (state, canton, region, |
| | | province, prefecture) |
| | | |
| 2 | A2 | county, parish, gun (JP), district (IN) |
| | | |
| 3 | A3 | city, township, shi (JP) |
| | | |
| 4 | A4 | city division, borough, city district, ward, |
| | | chou (JP) |
| | | |
| 5 | A5 | neighborhood, block |
| | | |
| 6 | A6 | group of streets below the neighborhood level |
+--------+-------+--------------------------------------------------+
Table 1
+--------+-------+--------------------------------------------------+
| CAtype | label | description |
+--------+-------+--------------------------------------------------+
| 1 | A1 | national subdivisions (state, canton, region, |
| | | province, prefecture) |
| | | |
| 2 | A2 | county, parish, gun (JP), district (IN) |
| | | |
| 3 | A3 | city, township, shi (JP) |
| | | |
| 4 | A4 | city division, borough, city district, ward, |
| | | chou (JP) |
| | | |
| 5 | A5 | neighborhood, block |
| | | |
| 6 | A6 | group of streets below the neighborhood level |
+--------+-------+--------------------------------------------------+
Table 1
For specific countries, the administrative sub-divisions are described below.
具体国家的行政分区如下所述。
CA (Canada): The mapping to NENA designations is shown in parentheses. A1 designates the province (STA), A2 the county (CNA), A3 the city, town, or MSAG community name (MCN).
CA（加拿大）：括号中显示了NENA名称的映射。A1表示省（STA），A2表示县（CNA），A3表示市、镇或MSAG社区名称（MCN）。
DE (Germany): A1 represents the state (Bundesstaat), A2 the county (Regierungsbezirk), A3 the city (Stadt, Gemeinde), A4 the district (Bezirk). Street suffixes (STS) are used only for designations that are a separate word (e.g., Marienthaler Strasse).
德（德国）：A1代表州（邦德斯塔特），A2代表县（Regierungsbezirk），A3代表市（斯塔特，杰梅因德），A4代表区（贝齐尔克）。街道后缀（STS）仅用于单独单词的名称（如Marienthaler Strasse）。
JP (Japan): A1 represents the metropolis (To, Fu) or prefecture (Ken, Do), A2 the city (Shi) or rural area (Gun), A3 the ward (Ku) or village (Mura), A4 the town (Chou or Machi), A5 the city district (Choume), and A6 the block (Banchi or Ban).
JP（日本）：A1代表大都会（To，Fu）或县（Ken，Do），A2代表城市（Shi）或农村地区（Gun），A3代表病房（Ku）或村庄（Mura），A4代表城镇（Chou或Machi），A5代表城区（Choume），A6代表街区（Banchi或Ban）。
KR (Korea): A1 represents the province (Do), A2 the county (gun), A3 the city or village (ri), A4 the urban district (gu), A5 the neighborhood (dong).
KR（韩国）：A1代表省（Do），A2代表县（gun），A3代表市或村（ri），A4代表市区（gu），A5代表邻里（dong）。
US (United States): The mapping to NENA designations is shown in parentheses. A1 designates the state (STA), using the two-letter state and possession abbreviations recommended by the United States Postal Service Publication 28 [17], Appendix B. A2 designates the county, parish (Louisiana), or borough (Alaska) (CNA). A3 designates the civic community name, e.g., city or town. It is also known as the municipal jurisdiction or MSAG community name (MCN). The civic community name (A3) reflects the political boundaries. These boundaries may differ from postal delivery assignments, the postal community name (PCN), for historical or practical reasons. The optional element A4 contains the community place name, such as "New Hope Community" or "Urbanizacion" in Puerto Rico.
美国（美国）：括号中显示了NENA名称的映射。A1表示州（STA），使用美国邮政局出版物28[17]附录B推荐的两个字母的州和属地缩写。A2表示县、教区（路易斯安那州）或自治区（阿拉斯加州）（CNA）。A3表示市民社区名称，例如城市或城镇。它也被称为市政辖区或MSAG社区名称（MCN）。公民社区名称（A3）反映了政治边界。由于历史或实际原因，这些边界可能不同于邮政交付任务，即邮政社区名称（PCN）。可选元素A4包含社区地名，例如波多黎各的“新希望社区”或“Urbanizacion”。
Mappings and considerations from additional countries may be informally gathered from time to time in independent documents published by the IETF. These should be titled "Civic Address Considerations for [Country]" and should contain similar information to the examples given here. As published by the IETF, they will be non-normative and purely descriptive, like the examples here, and will not purport to speak with authority for any country, but rather be offered for information. If authors choose to label the document with a country code, this does not preclude its use for labeling a future coexisting document.
来自其他国家的映射和考虑可能会不时非正式地收集在IETF发布的独立文件中。这些文件的标题应为“针对[国家]的公民地址考虑”，并应包含与此处给出的示例类似的信息。如IETF所发布的，它们将是非规范性和纯描述性的，就像这里的示例一样，并且不会声称与任何国家的权威对话，而是提供信息。如果作者选择使用国家代码为文档添加标签，这并不排除将其用于为未来共存的文档添加标签。
Additional CA types appear in many countries and are simply omitted where they are not needed or known:
其他CA类型出现在许多国家/地区，在不需要或不知道的情况下简单地省略：
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 0 | | | language | i-default [3] |
| | | | | |
| 16 | PRD | PRD | leading street direction | N |
| | | | | |
| 17 | POD | POD | trailing street suffix | SW |
| | | | | |
| 18 | STS | STS | street suffix or type | Ave, Platz |
| | | | | |
| 19 | HNO | HNO | house number | 123 |
| | | | | |
| 20 | HNS | HNS | house number suffix | A, 1/2 |
| | | | | |
| 21 | LMK | LMK | landmark or vanity | Columbia |
| | | | address | University |
| | | | | |
| 22 | LOC | LOC | additional location | South Wing |
| | | | information | |
| | | | | |
| 23 | NAM | NAM | name (residence and | Joe's |
| | | | office occupant) | Barbershop |
| 24 | ZIP | PC | postal/zip code | 10027-1234 |
| | | | | |
| 25 | | | building (structure) | Low Library |
| | | | | |
| 26 | | | unit (apartment, suite) | Apt 42 |
| | | | | |
| 27 | | FLR | floor | 4 |
| | | | | |
| 28 | | | room | 450F |
| | | | | |
| 29 | | | type of place | office |
| | | | | |
| 30 | PCN | | postal community name | Leonia |
| | | | | |
| 31 | | | post office box (P.O. | 12345 |
| | | | Box) | |
| | | | | |
| 32 | | | additional code | 13203000003 |
| | | | | |
| 33 | | SEAT | seat (desk, cubicle, | WS 181 |
| | | | workstation) | |
| | | | | |
| 34 | | | primary road name | Broadway |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 0 | | | language | i-default [3] |
| | | | | |
| 16 | PRD | PRD | leading street direction | N |
| | | | | |
| 17 | POD | POD | trailing street suffix | SW |
| | | | | |
| 18 | STS | STS | street suffix or type | Ave, Platz |
| | | | | |
| 19 | HNO | HNO | house number | 123 |
| | | | | |
| 20 | HNS | HNS | house number suffix | A, 1/2 |
| | | | | |
| 21 | LMK | LMK | landmark or vanity | Columbia |
| | | | address | University |
| | | | | |
| 22 | LOC | LOC | additional location | South Wing |
| | | | information | |
| | | | | |
| 23 | NAM | NAM | name (residence and | Joe's |
| | | | office occupant) | Barbershop |
| 24 | ZIP | PC | postal/zip code | 10027-1234 |
| | | | | |
| 25 | | | building (structure) | Low Library |
| | | | | |
| 26 | | | unit (apartment, suite) | Apt 42 |
| | | | | |
| 27 | | FLR | floor | 4 |
| | | | | |
| 28 | | | room | 450F |
| | | | | |
| 29 | | | type of place | office |
| | | | | |
| 30 | PCN | | postal community name | Leonia |
| | | | | |
| 31 | | | post office box (P.O. | 12345 |
| | | | Box) | |
| | | | | |
| 32 | | | additional code | 13203000003 |
| | | | | |
| 33 | | SEAT | seat (desk, cubicle, | WS 181 |
| | | | workstation) | |
| | | | | |
| 34 | | | primary road name | Broadway |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 35 | | | road section | 14 |
| | | | | |
| 36 | | | branch road name | Lane 7 |
| | | | | |
| 37 | | | sub-branch road name | Alley 8 |
| | | | | |
| 38 | | | street name pre-modifier | Old |
| | | | | |
| 39 | | | street name post-modifier | Service |
| | | | | |
| 128 | | | script | Latn |
| | | | | |
| 255 | | | reserved | |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 35 | | | road section | 14 |
| | | | | |
| 36 | | | branch road name | Lane 7 |
| | | | | |
| 37 | | | sub-branch road name | Alley 8 |
| | | | | |
| 38 | | | street name pre-modifier | Old |
| | | | | |
| 39 | | | street name post-modifier | Service |
| | | | | |
| 128 | | | script | Latn |
| | | | | |
| 255 | | | reserved | |
+--------+------+------+---------------------------+----------------+
The CA types labeled in the second column correspond to items from the NENA "Recommended Formats and Protocols For ALI Data Exchange, ALI Response and GIS Mapping" [18], but are applicable to most countries. The "NENA" column refers to the data dictionary name in Exhibit 18 of [18].
第二列中标记的CA类型对应于NENA“ALI数据交换、ALI响应和GIS映射的推荐格式和协议”[18]中的项目，但适用于大多数国家。“NENA”列指[18]附件18中的数据字典名称。
The column labeled PIDF indicates the element name from [16]. (Some elements were added to this document after the PIDF location object definition had been completed. These elements currently do not have a PIDF-LO equivalent.)
标有PIDF的列表示[16]中的元素名称。（某些元素是在完成PIDF位置对象定义后添加到此文档的。这些元素当前没有PIDF-LO等效项。）
Language: The "language" item (CAtype 0) optionally identifies the language used for presenting the address information, drawing from the tags for identifying languages in [4], as discussed in [13]. If omitted, the default value for this tag is "i-default" [3].
语言：“语言”项（CAtype 0）选择性地标识用于表示地址信息的语言，如[13]所述，从[4]中标识语言的标记中提取。如果省略，此标记的默认值为“i-default”[3]。
Script: The "script" item (CAtype 128) optionally identifies the script used for presenting the address information, drawing from the tags for identifying scripts described in [12] and elaborated on in Section 2.2.3 of [13]. If omitted, the default value for this tag is "Latn".
脚本：“脚本”项（CAtype 128）可选择性地标识用于显示地址信息的脚本，从[12]中描述并在[13]第2.2.3节中详述的用于标识脚本的标签中提取。如果省略，此标记的默认值为“Latn”。
POD, PRD: The abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be used for POD (trailing street suffix) and PRD (leading street direction) in English-speaking countries.
POD，PRD：在英语国家，POD（尾随街道后缀）和PRD（主要街道方向）应使用缩写N、E、S、W和NE、NW、SE、SW。
STS: STS designates a street suffix or type. In the United States (US), the abbreviations recommended by the United States Postal Service Publication 28 [17], Appendix C, SHOULD be used.
STS:STS指定街道后缀或类型。在美国，应使用美国邮政局出版物28[17]附录C推荐的缩写。
HNS: HNS ("house number suffix") is a modifier to a street address; it does not identify parts of a street address.
HNS:HNS（“门牌号后缀”）是街道地址的修饰语；它不能识别街道地址的某些部分。
building: While a landmark (LMK, CAtype 21) can indicate a complex of buildings, 'building' (CAtype 25) conveys the name of a single building if the street address includes more than one building or if the building name is helpful in identifying the location.
建筑物：虽然地标（LMK，CAtype 21）可以表示建筑物的综合体，但如果街道地址包含多个建筑物，或者如果建筑物名称有助于识别位置，则“建筑物”（CAtype 25）表示单个建筑物的名称。
LOC: LOC ("location", CAtype 22) is an unstructured string specifying additional information about the location, such as the part of a building or other unstructured information.
LOC:LOC（“location”，CAtype 22）是一个非结构化字符串，用于指定有关位置的其他信息，例如建筑的一部分或其他非结构化信息。
PCN: The postal community name (CAtype 30) and the post office box (CAtype 31) allow the recipient to construct a postal address. The post office box field should contain the words "P.O. Box" or other locally appropriate postal designation.
PCN：邮政团体名称（CAtype 30）和邮政信箱（CAtype 31）允许收件人构建邮政地址。“邮政信箱”字段应包含“邮政信箱”或其他当地适当的邮政名称。
NAM: The NAM object is used to aid user location ("Joe Miller", "Alice's Dry Cleaning"). It does not identify the person using a communications device, but rather the person or organization associated with the address.
NAM：NAM对象用于帮助用户定位（“Joe Miller”、“Alice的干洗店”）。它不识别使用通信设备的人，而是识别与地址相关联的人或组织。
LMK: While a landmark (LMK, CAtype 21) can indicate a complex of buildings, 'building' (CAtype 25) conveys the name of a single building if the street address includes more than one building or the building name is helpful in identifying the location. (For example, on university campuses, the house number is often not displayed on buildings, whereas the building name is prominently shown.)
LMK：虽然地标（LMK，CAtype 21）可以表示建筑群，“建筑”（CAtype 25）表示单个建筑的名称，如果街道地址包含多个建筑，或者建筑名称有助于识别位置。（例如，在大学校园中，房屋编号通常不会显示在建筑物上，而建筑物名称会突出显示。）
Unit: The "unit" object (CAtype 26) contains the name or number of a part of a structure where there are separate administrative units, owners, or tenants, such as separate companies or families that occupy that structure. Common examples include suite or apartment designations.
单元：“单元”对象（CAtype 26）包含一个结构部分的名称或编号，其中有独立的管理单元、所有者或租户，例如占用该结构的独立公司或家庭。常见的例子包括套房或公寓名称。
Room: A "room" (CAtype 28) is the smallest identifiable subdivision of a structure.
房间：“房间”（CAtype 28）是结构中可识别的最小分区。
Type of place: The "type of place" item (CAtype 29) describes the type of place described by the civic coordinates. For example, it describes whether it is a home, office, street, or other public space. The values are drawn from the items in the location types registry [11]. This information makes it easy, for example, for the DHCP client to then populate the presence information. Since this is an IANA-registered token, the language and script designations do not apply for this element.
地点类型：“地点类型”项（CAtype 29）描述了公民坐标所描述的地点类型。例如，它描述了它是家庭、办公室、街道还是其他公共空间。这些值来自位置类型注册表中的项目[11]。例如，此信息使DHCP客户端很容易填充状态信息。由于这是IANA注册的令牌，因此语言和脚本指定不适用于此元素。
Additional code: The "additional code" item (CAtype 32) provides an additional, country-specific code identifying the location. For example, for Japan, it contains the Japan Industry Standard (JIS) address code. The JIS address code provides a unique address inside of Japan, down to the level of indicating the floor of the building.
附加代码：“附加代码”项（CAtype 32）提供了一个附加的、特定于国家/地区的代码，用于标识位置。例如，对于日本，它包含日本工业标准（JIS）地址代码。JIS地址代码在日本境内提供了一个唯一的地址，直至指示建筑物楼层的级别。
SEAT: The "seat" item (CAtype 33) designates a place where a person might sit, such as a seat in a stadium or theater, or a cubicle in an open-plan office or a booth in a trade show.
座位：“座位”项（CAtype 33）指定一个人可以坐的地方，例如体育场或剧院的座位，开放式办公室的隔间或贸易展的展位。
Primary road name: The "primary road" item (CAtype 34) is given to the road or street name associated with the address. If CAtypes 35 through 37 are not specified, the building or designated location is found on that street. If some of CAtypes 35 through 37 are specified, this designates the main road, off of which the smaller streets branch off and where the structure or building is actually located.
主要道路名称：“主要道路”项目（CAtype 34）用于与地址关联的道路或街道名称。如果未指定CATYPE 35到37，则该建筑物或指定位置位于该街道上。如果指定了类别35至37中的某些类别，则这将指定主要道路，较小的街道将从该道路分支，并且结构或建筑实际位于该道路上。
Road section: The "road section" item (CAtype 35) designates a specific section or stretch of a primary road. This is a new thoroughfare element and is useful where a primary road is divided into sections that re-use the same street number ranges.
路段：“路段”项目（35类）指定主要道路的特定路段或路段。这是一个新的通道元素，在将主要道路划分为重复使用相同街道编号范围的路段时非常有用。
Branch road name: The "branch road name" item (CAtype 36) represents the name or identifier of a road or street that intersects or is associated with a primary road. The branch road name is used only in countries where side streets do not have unique names within a municipality or other administrative unit, but rather must be qualified by the name of the primary road name that they branch off of.
支路名称：“支路名称”项（CAtype 36）表示与主路相交或关联的道路或街道的名称或标识符。支路名称仅在城市或其他行政单位内没有唯一名称，但必须以支路所在的主要道路名称进行限定的国家/地区使用。
Sub-Branch road name: The "sub-branch road name" (CAtype 37) item represents the name of a street that branches off a branch road (CAtype 36). The sub-branch road name is used only in countries where such streets are named relative to the primary road name and branch road that they connect with.
支路名称：“支路名称”（CAtype 37）项表示支路的街道名称（CAtype 36）。支路名称仅在这些街道相对于其连接的主要道路名称和支路进行命名的国家/地区使用。
Street name pre-modifier: The "street name pre-modifier" (CAtype 38) is an optional element of the complete street name. It is a word or phrase that precedes all other elements of the street name and modifies it, but is separated from the street name by a street name pre-directional. An example is "Old" in "Old North First Street".
街道名称预修饰符：“街道名称预修饰符”（CAtype 38）是完整街道名称的可选元素。它是一个单词或短语，位于街道名称的所有其他元素之前并对其进行修改，但与街道名称之间由街道名称分隔。“旧北第一街”中的“旧”就是一个例子。
Street name post-modifier: The "street name post-modifier" (CAtype 39) is an optional element of the complete street name. It is a word or phrase that follows all other elements of the street name and modifies it, but is separated from the street name by a street name post-directional and/or street suffix. An example is "Extended" in "East End Avenue Extended".
街道名称张贴修改器：“街道名称张贴修改器”（CAtype 39）是完整街道名称的可选元素。它是一个单词或短语，跟随街道名称的所有其他元素并对其进行修改，但与街道名称之间通过街道名称的方向性和/或街道后缀分隔。“东端大道延伸”中的“延伸”就是一个例子。
In general, a recipient can construct a postal address by using all language-appropriate elements, including the postal code (ZIP, CAtype 24). However, certain elements override the civic address components to create a postal address. If the elements include a post office box (CAtype 31), the street address components (CAtype 34, PRD, POD, STS, HNO, HNS) are replaced with the post office box element. If a postal community name is specified, the civic community name (typically, A3) is replaced by the postal community name (PCN, CAtype 30). Country-specific knowledge is required to create a valid postal address. The formating of such addresses is beyond the scope of this document.
通常，收件人可以使用所有适合语言的元素（包括邮政编码（ZIP，CAtype 24））来构造邮政地址。但是，某些元素会覆盖civic address组件以创建邮政地址。如果元素包括邮政信箱（CAtype 31），则街道地址组件（CAtype 34、PRD、POD、STS、HNO、HNS）将替换为邮政信箱元素。如果指定了邮政社区名称，则公民社区名称（通常为A3）将替换为邮政社区名称（PCN，CAtype 30）。创建有效的邮政地址需要特定于国家/地区的知识。此类地址的格式超出了本文件的范围。
Rather than showing the precise byte layout of a DHCP option, we show a symbolic example below, representing the civic address of the Munich city hall in Bavaria, Germany. The city and state name are also conveyed in English and Italian in addition to German; the other items are assumed to be common across all languages. All languages use the latin script.
我们不显示DHCP选项的精确字节布局，而是在下面显示一个符号示例，代表德国巴伐利亚慕尼黑市政厅的市政地址。除了德语外，城市和州的名称也用英语和意大利语表达；其他项目假定在所有语言中都是通用的。所有语言都使用拉丁语。
+--------+---------------------+
| CAtype | CAvalue |
+--------+---------------------+
| 0 | de |
| | |
| 128 | Latn |
| | |
| 1 | Bayern |
| | |
| 2 | Oberbayern |
| | |
| 3 | M=U+00FCnchen |
| | |
| 6 | Marienplatz |
| | |
| 19 | 8 |
| | |
| 21 | Rathaus |
| | |
| 24 | 80331 |
| | |
| 29 | government-building |
| | |
| 31 | Postfach 1000 |
| | |
| 0 | en |
| | |
| 1 | Bavaria |
| | |
| 3 | Munich |
| | |
| 0 | it |
| | |
| 1 | Baviera |
| | |
| 3 | Monaco |
+--------+---------------------+
+--------+---------------------+
| CAtype | CAvalue |
+--------+---------------------+
| 0 | de |
| | |
| 128 | Latn |
| | |
| 1 | Bayern |
| | |
| 2 | Oberbayern |
| | |
| 3 | M=U+00FCnchen |
| | |
| 6 | Marienplatz |
| | |
| 19 | 8 |
| | |
| 21 | Rathaus |
| | |
| 24 | 80331 |
| | |
| 29 | government-building |
| | |
| 31 | Postfach 1000 |
| | |
| 0 | en |
| | |
| 1 | Bavaria |
| | |
| 3 | Munich |
| | |
| 0 | it |
| | |
| 1 | Baviera |
| | |
| 3 | Monaco |
+--------+---------------------+
The security considerations discussed in the GEOPRIV architecture defined by RFC 3693 [9] apply.
RFC 3693[9]定义的GEOPRIV架构中讨论的安全注意事项适用。
Where critical decisions might be based on the value of this GEOCONF_CIVIC option, DHCPv4 authentication in RFC 3118 [5] SHOULD be used to protect the integrity of the DHCP options.
如果关键决策可能基于此GEOCONF_CIVIC选项的值，则应使用RFC 3118[5]中的DHCPv4身份验证来保护DHCP选项的完整性。
Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover the information contained in this option. Thus, usage of this option on networks without access restrictions or network-layer or link-layer privacy mechanisms is NOT RECOMMENDED.
由于DHCP消息没有隐私保护，可以监视DHCP服务器和请求客户端之间链接的窃听者可以发现此选项中包含的信息。因此，不建议在没有访问限制或网络层或链路层隐私机制的网络上使用此选项。
To minimize the unintended exposure of location information, the GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when the DHCPv4 client has included this option in its 'parameter request list' (RFC 2131 [2], Section 3.5). Similarly, the OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only when the DHCPv6 client has included this option in its OPTION_ORO.
为了尽量减少位置信息的意外暴露，只有当DHCPv4客户端在其“参数请求列表”（RFC 2131[2]，第3.5节）中包含此选项时，DHCPv4服务器才应返回GEOCONF_CIVIC选项。类似地，只有当DHCPv6客户机将此选项包含在其选项\u ORO中时，DHCPv6服务器才应返回选项\u GEOCONF\u CIVIC选项。
After initial location information has been introduced, it MUST be afforded the protections defined in RFC 3694 [10]. Therefore, location information SHOULD NOT be sent from a DHCP client to a DHCP server. If a client decides to send location information to the server, it is implicitly granting that server unlimited retention and distribution permissions.
引入初始位置信息后，必须提供RFC 3694[10]中定义的保护。因此，不应将位置信息从DHCP客户端发送到DHCP服务器。如果客户机决定向服务器发送位置信息，则会隐式授予该服务器无限的保留和分发权限。
The IANA has registered new DHCPv4 and DHCPv6 option codes for the Civic Address (GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC, respectively).
IANA已为Civic地址注册了新的DHCPv4和DHCPv6选项代码（分别为GEOCONF_Civic和option_GEOCONF_Civic）。
This document establishes a new IANA registry for CAtypes designating civic address components. Referring to RFC 2434 [14], this registry operates under both "Expert Review" and "Specification Required" rules. The IESG will appoint an Expert Reviewer who will advise IANA promptly on each request for a new or updated CAtype.
本文件为指定civic address组件的CAType建立了一个新的IANA注册表。参考RFC 2434[14]，该注册中心在“专家评审”和“规范要求”规则下运行。IESG将任命一名专家评审员，该专家将在每次提出新的或更新的CAtype请求时立即向IANA提供建议。
CAtype: Numeric identifier, assigned by IANA.
CAtype：数字标识符，由IANA分配。
Brief description: Short description identifying the meaning of the element.
简短描述：识别元素含义的简短描述。
Reference to published specification: A stable reference to an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
对已发布规范的引用：对RFC或其他永久性且随时可用的引用的稳定引用，足够详细，以便独立实现之间的互操作性成为可能。
Country-specific considerations: If applicable, notes whether the element is only applicable or defined for certain countries.
特定国家的注意事项：如果适用，请注意该要素是否仅适用于或定义于某些国家。
The initial list of registrations is contained in Section 3.4.
注册的初始列表包含在第3.4节中。
Updates to country-specific considerations for previously-defined CAtypes are not defined by IANA registrations since they are purely descriptive, not a registration of identifiers. As noted earlier, country-specific conventions may optionally be written up in documents titled "Civic Addresses for [Country]".
IANA注册没有定义以前定义的CATYPE的国家特定注意事项的更新，因为它们纯粹是描述性的，而不是标识符的注册。如前所述，特定国家的公约可选择性地写在题为“国家公民地址”的文件中。
[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] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[4] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[4] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[5] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[6] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[8] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[8] Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9] Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[10] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[10] Danley，M.，Mulligan，D.，Morris，J.，和J.Peterson，“Geopriv协议的威胁分析”，RFC 36942004年2月。
[11] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[11] Schulzrinne，H.和H.Tschofenig，“位置类型注册表”，RFC 4589，2006年7月。
[12] International Organization for Standardization, ISO., "ISO 15924:2004. Information and documentation - Codes for the representation of names of scripts", January 2004.
[12] 国际标准化组织，ISO.，“ISO 15924:2004.信息和文件-脚本名称表示代码”，2004年1月。
[13] Phillips, A. and M. Davis, "Tags for Identifying Languages", Work in Progress, October 2005.
[13] Phillips，A.和M.Davis，“识别语言的标签”，正在进行的工作，2005年10月。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[14] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[15] Polk，J.，Schnizlein，J.，和M.Linsner，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 3825，2004年7月。
[16] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[16] Peterson，J.，“基于状态的GEOPRIV定位对象格式”，RFC 4119，2005年12月。
[17] United States Postal Service, "Postal Addressing Standards", November 2000.
[17] 美国邮政局，“邮政地址标准”，2000年11月。
[18] National Emergency Number Assocation, "NENA Recommended Formats and Protocols For ALI Data Exchange, ALI Response and GIS Mapping", NENA NENA-02-010, January 2002.
[18] 国家应急号码协会，“NENA推荐的ALI数据交换、ALI响应和GIS制图格式和协议”，NENA NENA-02-010，2002年1月。
Acknowledgements
致谢
Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson and Hannes Tschofenig provided helpful comments. Examples and inspiration were drawn from the Street Address Data Standard of the Federal Geographic Data Committee.
Harald Alvestrand、Stefan Berger、Peter Blatherwick、Joel M.Halpern、David Kessens、Cheng Hong Li、Rohan Mahy、James Polk、Martin Thomson和Hannes Tschofenig提供了有益的评论。示例和灵感来自联邦地理数据委员会的街道地址数据标准。
Author's Address
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs+geopriv@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs+geopriv@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。