Network Working Group H. Schulzrinne
Request for Comments: 4776 Columbia U.
Obsoletes: 4676 November 2006
Category: Standards Track
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option
for Civic Addresses Configuration Information
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 IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
RFC Editor Note
RFCエディタ注意
RFC 4776 is being published to correct an error in the assignment of the numeric value of the DHCPv6 option-code in RFC 4676 (Section 3.2). This document obsoletes RFC 4676.
RFC 4776は、RFC 4676でのDHCPv6オプションコードの数値の割り当て（3.2節）でエラーを修正するために、公開されています。この文書はRFC 4676を廃止します。
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.
この文書は、クライアントの都市ロケーションまたはDHCPサーバを含む動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションを指定します。ロケーションの設定情報（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 .............................................7
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.
地理空間座標を介して、または、いわゆる市民のアドレスのいずれかによって、オブジェクトの位置を識別するための2つの一般的な方法があります。市民アドレス番地を示しながら、地理空間座標は、経度、緯度、及び高度を示します。
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]のデバイスへの市民や住所を伝えるために使用する方法について説明します。地理空間と市民の両方のフォーマットは、緊急対応者に正確かつタイムリーな位置情報を提供する機会を増やし、同時に使用することができます。読者はまた、以下のプロトコル要素の多くはPIDF-LO要素と蟻に設計されている、[11]における概念に精通しなければなりません。
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によって定義されるようGEOPRIVアーキテクチャ内[9]、初期位置情報を伝達するため、この文書で定義されたメカニズムは、「照準」機能として知られています。照準機能は、セキュリティ機能を持つ必要はありませんとだけ信頼できると制御された環境で設定されることを意図しています。 （照準機能の古典的な例は、ネットワーク・ノードに直接接続グローバル・ポジショニング・システムである。）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.
地理空間情報とは違って、市民や郵便情報の形式は国によって異なります。データフィールドの初期設定は、[18]米国国立緊急番号協会（NENA）で公開されている標準に由来し、世界のさまざまな分野での国の数の規則への対応を考慮に入れています。他の国は、データ要素の多くを再利用できることが予想されますが、文書はまた、追加の都市ロケーションデータフィールドを定義するための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 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.
この文書では、さまざまな運用の意思決定のために呼び出します。たとえば、管理者は、これらが離れて、クライアントから良い距離であってもよい場合でも、DHCPサーバーの場所、または他のネットワーク要素を提供するタイミングを決定する必要があります。管理者は、これらが異なることがあれば、市民と地理空間情報の両方を含めるかどうかを検討する必要があります。これらの選択肢は、地域の実情に強く依存する可能性があり、地元、人間の知識に基づいてする必要があるよう文書では、これらの選択を行う際に使用する条件を指定しません。
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 the two protocols MUST be the same.
ネットワークは、DHCPv4とDHCPv6の両方を介して、市民の位置情報を提供する場合に加えて、2つのプロトコルによって搬送される情報は同じである必要があります。
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節）で説明したように、GEOCONF_CIVICオプションはDHCPv4のクライアントがその「パラメータ要求リスト」（RFC 2131 [2]、3.5節）には、このオプションを含めた場合のみのDHCPv4サーバによって返されるべきです。同様に、OPTION_GEOCONF_CIVICオプションは、DHCPv6クライアントはそのOPTION_OROでこのオプションを含めた場合のみのDHCPv6サーバによって返されるべきです。
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.
RFC 3396に記載のDHCPv4長オプション機構市民アドレスオプションは、255オクテットの最大のDHCPv4オプションのサイズを超える場合、[8]を使用しなければなりません。
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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
何：「何」要素が説明DHCPエントリが参照する場所。現在、3つのオプションが定義されています：DHCPサーバー（0の値）、クライアント（1の値）、またはクライアントの場所（の値に最も近いであると考えられ、ネットワーク要素の場所の場所2）。 （2）オプションを使用する必要があり、しかし知られていないかもしれません。オプション（0）、DHCPクライアントがサーバーまたはネットワーク要素に物理的に近接していることが知られていない限り、（1）使用されるべきではありません。
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.)
国コード：資本ASCII文字、例えば、DEまたは米国の2文字のISO 3166国コード。 （シビックアドレスは常にスペースを節約するために、固定フォーマットのフィールドの使用を示唆し、国の指定が含まれています。）
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]市民アドレスオプションは、全体としてクライアントを指します。
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 (36)
オプションコード：OPTION_GEOCONF_CIVIC（36）
option-len: Length of the Countrycode, 'what' and civic address elements in octets.
オプション-LEN：COUNTRYCODEの長さ、「何とオクテットで市民のアドレス要素。
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の両方のために、各市民のアドレス要素の形式は次のとおりです。
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：データ市民のアドレス値の1オクテット記述。
CAlength: The length, in octets, of the CAvalue, not including the CAlength field itself.
CAlength：CAlengthフィールド自体は含まないオクテットで、CAvalueの長さ、、。
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.
各国がしばしば同じ（英語）の名前で、異なる管理の階層を持っているので、この仕様は、それぞれの国のためにインスタンス化され、単純な階層の表記を採用しています。私たちは、5つのレベルがストリートレベル以上の準国家分裂のために十分であることを前提としています。
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
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はA2郡（CNA）、A3市、町、またはMSAGコミュニティ名（MCN）、州（STA）を指定します。
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).
DE（ドイツ）：A1はA2郡（ドイツの行政管区）、A3街（シュタット、Gemeinde）、A4区（Bezirk）、（Bundesstaat）状態を表しています。ストリートサフィックス（STS）は、のみ（例えば、Marienthalerシュトラーセ）別の単語である指定のために使用されます。
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）大都市を表し、または県（ケン、DO）、A2街（市）や農村地域（ガン）、A3区（区）や村（村）、A4町（チョウまたは町）、A5街区（Choume）、およびA6ブロック（番地または禁止）。
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はA2郡（郡）、A3街や村（RI）、A4市街地（GU）、A5近所（洞）、州（ド）を表しています。
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は、米国郵政公社公報28 [17]、付録B. A2は（郡、教区（ルイジアナ州）、または自治区（アラスカ）を指定CNAが推奨する2文字の州や所持略語を使用して、状態（STA）を指定します）。 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 |
| | | | | |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 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 |
| | | | | |
| 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].
2番目の列にラベルされたCAの種類は、[18] NENA「ALIデータ交換、ALI応答とGISマッピングするための推奨フォーマットとプロトコル」の項目に対応するが、ほとんどの国に適用されます。 「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-デフォルト」である[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：略語N、E、S、W、およびNE、NW、SE、SWは、英語圏の国ではPOD（末尾の通りの接尾辞）とPRD（大手通りの方向）には、使用されてください。
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は、通りの接尾辞またはタイプを指定します。米国（US）では、米国郵政公社公報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（「位置」、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オブジェクトは、ユーザーの場所（「ジョー・ミラー」、「アリスのドライクリーニング」）を支援するために使用されます。これは、通信デバイスを使用している人ではなく、アドレスに関連付けられた個人または組織を識別しません。
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.
部屋：A「部屋」（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.
SEAT：「シート」の項目（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）アドレスに関連付けられた道路または街路名に与えられます。 CAtypes 35〜37が指定されていない場合は、建物又は指定された場所は、その通りに見出されます。 37スルーCAtypes 35の一部が指定されている場合、これは、より小さな通りが分岐構造や建物が実際にどこに位置してオフれた、主要道路を指定します。
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.
道路区間：「道路区間」項目（CAtype 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）を含むすべての言語の適切な要素を使用して住所を構築することができます。しかし、特定の要素は、郵便アドレスを作成するために、市民のアドレス構成要素を上書きします。要素は、私書箱（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 |
+--------+---------------------+
The security considerations discussed in the GEOPRIV architecture defined by RFC 3693 [9] apply.
RFC 3693によって定義されるGEOPRIVアーキテクチャで議論したセキュリティ問題は、[9]適用します。
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でのDHCPv4認証は、[5] 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.
位置情報の意図しない露出を最小限に抑えるために、GEOCONF_CIVICオプションはDHCPv4のクライアントがその「パラメータ要求リスト」（RFC 2131 [2]、3.5節）には、このオプションを含めた場合のみのDHCPv4サーバによって返されるべきです。同様に、OPTION_GEOCONF_CIVICオプションは、DHCPv6クライアントはそのOPTION_OROでこのオプションを含めた場合のみのDHCPv6サーバによって返されるべきです。
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は（それぞれ、GEOCONF_CIVICとOPTION_GEOCONF_CIVIC）シビック住所のための新しいDHCPv4とDHCPv6のオプションコードを登録しています。
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.
この文書では、市民のアドレスコンポーネントを指定CAtypesための新しい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]".
国固有の、彼らは純粋に記述されているので、事前に定義されたCAtypesのための考慮事項は、IANA登録によって定義されていない、識別子のない登録の更新。先に述べたように、国固有の規則は、必要に応じて、「[国]のためのシビックアドレス」と題した文書にまで書かれていてもよいです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、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メッセージの認証"、RFC 3118、2001年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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、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]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（DHCPv4の）でエンコーディング長いオプション"、RFC 3396、2002年11月。
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、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.、マリガン、D.、モリス、J.、およびJ.ピーターソン、 "Geoprivプロトコルの脅威分析"、RFC 3694、2004年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.
標準化、ISOのための[12]国際組織、「ISO 15924：2004の情報とドキュメンテーション - スクリプトの名前の表現のためのコード。」、2004年1月。
[13] Phillips, A. and M. Davis, "Tags for Identifying Languages", Work in Progress, October 2005.
[13]フィリップス、A.とM.デイヴィス、「言語を識別するためのタグ」、進歩、2005年10月に作業。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[14] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[15]ポーク、J.、Schnizlein、J.、およびM. Linsner、 "座標ベースのロケーションの設定については、動的ホスト構成プロトコル・オプション"、RFC 3825、2004年7月。
[16] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[16]ピーターソン、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.
ハラルドAlvestrand、ステファン・バーガー、ピーターBlatherwick、ジョエルM.ハルパーン、デビッドKessens、チェン - 香港のLi、ロハンマーイ、ジェームズ・ポーク、マーティン・トムソンとハンネスTschofenigは役に立つコメントを提供しました。例とインスピレーションは、住所連邦地理データ委員会のデータ標準から引き出されました。
Author's Address
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+geopriv@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+geopriv@cs.columbia.edu URI：http://www.cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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, THE IETF TRUST, 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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。