RFC4776 日本語訳
4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Optionfor Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT=45495 bytes) (Obsoletes RFC4676) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne Request for Comments: 4776 Columbia U. Obsoletes: 4676 November 2006 Category: Standards Track
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4776 コロンビアU.は以下を時代遅れにします。 4676 2006年11月のカテゴリ: 標準化過程
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option
for Civic Addresses Configuration Information
都市のアドレス設定情報のためのDynamic Host Configuration Protocol(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
RFC4776は、RFC4676(セクション3.2)のDHCPv6オプションコードの数値の課題で誤りを改めるために発行されています。 このドキュメントはRFC4676を時代遅れにします。
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サーバを含むDynamic Host Configuration Protocol(DHCPv4とDHCPv6)オプションを指定します。Location Configuration情報(LCI)は国、州や、州や、都市などの行政単位、および住所の情報、郵便の共同体名、およびビル情報を含んでいます。 オプションは異なったスクリプトと言語における、同じアドレスの複数の表現を許します。
Schulzrinne Standards Track [Page 1] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[1ページ]RFC4776DHCP
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
1. 序論…2 2. 用語…5 3. DHCPの都市の位置のオプションの形式…5 3.1. DHCPv4のための総合的な形式…5 3.2. DHCPv6のための総合的な形式…6 3.3. 要素形式…7 3.4. 都市のアドレス構成要素…7 4. 郵便のアドレス…13 5. 例…14 6. セキュリティ問題…15 7. IANA問題…15 8. 参照…16 8.1. 標準の参照…16 8.2. 有益な参照…17の承認…17
1. Introduction
1. 序論
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.
geospatial座標を通して、または、いわゆる都市のアドレスでオブジェクトの位置を特定する2つの一般的な方法があります。 都市のアドレスが住所を示している間、Geospatial座標は経度、緯度、および高度を示します。
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
関連するドキュメント[15]はgeospatial情報をデバイスに伝えるためのDHCPv4[2]オプションについて説明します。 このドキュメントは都市の、そして、郵便のアドレスをデバイスに伝えるのにどうDHCPv4とDHCPv6[6]を使用できるかを説明します。 正確であって、タイムリーな状態で配送する可能性を増強して、同時に、geospatialと都市の形式の両方を使用できます。
Schulzrinne Standards Track [Page 2] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[2ページ]RFC4776DHCP
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.
緊急要員への位置情報。 また、読者も[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を使用すると関連する安全上の配慮のため。 RFC3693[9]によって定義されるGEOPRIVアーキテクチャの中では、本書では初期の位置情報を伝えるための定義されたメカニズムは「目撃例」機能として知られています。 目撃例機能は、セキュリティ能力を持つのが必要でなく、信じられて制御された環境で構成されることを意図するだけです。 (目撃例機能に関する典型例は直接ネットワーク・ノードに配線された全地球測位システムです。) RFC3694[10]に応じて提供しなければならない保護のさらなる議論がSecurity Considerations(セクション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.
特にビルの中でしばしば追加していて、人間使用可能な情報を提供するので、都市の情報は役に立ちます。 また、geospatial情報と比べて、それを容易にほとんどの占領された構造に得て、不完全であっても、しばしば解釈できます。 例えば、多くの大きい大学の、または、法人のキャンパスには、ビルへのジオコーディング情報と余地の粒状は容易に利用可能でないかもしれません。
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.
そして、情報、形式をgeospatialする、都市、郵便案内は国から国まで異なります。 データ・フィールドの始発は、合衆国National Emergency Number Association(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
しばしば同じ都市の、そして、郵便のアドレス情報を複数の言語とスクリプトに表すことができます。 例えば、韓国のアドレスはハングル、ラテン語、およびKanjiにしばしば示されます、いくつかの、より古い都市には複数の言語異形(例えば、ミュンヘン、Muenchen、およびモナコ)がありますが。 以来、DHCPv4とDHCPv6は現在、特定のスクリプトのために質問するメカニズムか言語(SHOULDがすべての一般的なレンダリングをクライアントに提供して、言語で少なくともレンダリングを提供しなければならなくて、位置に適切なスクリプトが示したDHCPサーバ)をサポートしません。 例えば、存在情報における使用のための目標は、外国から訪問しているかもしれなくて、運びたがっています。
Schulzrinne Standards Track [Page 3] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[3ページ]RFC4776DHCP
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].
自国のウォッチャーに適任の形式の情報。 緊急サービスに関しては、レンダリングは現地の言葉で最も適切である傾向があります。 複数のレンダリングを提供するために、サーバはアドレス要素の系列を繰り返します、'言語'、そして/または、'スクリプト'要素でそれぞれを前に置いて(セクション3.3を見てください)。 言語とスクリプトは別の言語かスクリプト要素によってくつがえされるまでその後の要素に有効なままで残っています。 DHCPクライアントが位置情報の最終消費者であるためにありそうもないので、DHCPサーバは存在ベースのGEOPRIV位置のオブジェクト形式[16]で通常コード化されたプロトコルを使用することですべての適切な言語とスクリプトにバージョンを提供しなければなりません。(次に、クライアントはある他のGEOPRIVを通してバージョンを伝えます)。
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サーバか他のネットワーク要素の位置を提供するかを決めなければなりません。 また、これらが異なるかもしれないなら、管理者は、ともに都市とgeospatial情報を含んでいるかどうか考えなければなりません。 ドキュメントはこれらの選択をする際に使用されるために評価基準を指定しません、これらの選択が強く地元の事情に依存して、地方の、そして、人間の知識に基づくのが必要でありそうなときに。
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:
aが構成されて、DHCPが依存しているというDHCPシステムの管理者が十分慎重である前部の位置の情報に付番している状態で動作する以下などのシステム
- if information about one location is provided in multiple forms
(e.g., in multiple languages), is it consistent?
- 複数のフォーム(例えば、複数の言語の)に1つの位置の情報を提供するなら、一貫していますか?
- 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
位置情報が特に非常時のサービスのために安全に即座に扱われるのを確実にするのにおいて他の多くの問題があります。 それらがアプリケーションの州にいる、どれ
Schulzrinne Standards Track [Page 4] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[4ページ]RFC4776DHCP
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構成SHOULD NOT、緊急サービスには、これらの問題に関するガイドラインなしで使用されてください。 これらに対する仕事はこのドキュメントの公表時点で、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_シビックはSecurity Considerationsで議論するようにSHOULDにゆだねます。DHCPv4クライアントが'パラメタ要求リスト'(RFC2131[2]、セクション3.5)にこのオプションを含んでいたDHCPv4サーバだけで、返してください。 同様に、OPTION_GEOCONF_シビックはSHOULDにゆだねます。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.
都市のアドレスオプションが255の八重奏の最大のDHCPv4オプションサイズを超えているなら、RFC3396[8]で説明されたDHCPv4長いオプションメカニズムを使用しなければなりません。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[1]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Format of the DHCP Civic Location Option
3. DHCPの都市の位置のオプションの形式
3.1. Overall Format for DHCPv4
3.1. DHCPv4のための総合的な形式
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_都市です。| N| 何| 国| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 都市のアドレス要素… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code GEOCONF_CIVIC: The code for this DHCP option is 99.
コードGEOCONF_都市: このDHCPオプションのためのコードは99です。
N: The length of this option is variable. The minimum length is 3
octets.
N: このオプションの長さは可変です。 最小の長さは3つの八重奏です。
Schulzrinne Standards Track [Page 5] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[5ページ]RFC4776DHCP
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)SHOULDは使用されますが、知られていないかもしれません。 オプション(0)と(1)SHOULD NOT、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.)
国名略号: 資本ASCII手紙、例えば、DEの2文字のISO3166国名略号か米国。 (記憶空間を節約するために固定フォーマット分野の使用を示して、都市のアドレスはいつも国の名称を含んでいます。)
civic address elements: Zero or more elements comprising the civic
and/or postal address, with the format described below
(Section 3.3).
都市のアドレス要素: 形式が(セクション3.3)の下で説明されている状態で都市の、そして/または、郵便のアドレスを含むゼロか、より多くの要素。
3.2. Overall Format for DHCPv6
3.2. DHCPv6のための総合的な形式
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 .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_都市です。| オプション-len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 何| 国名略号| . +++++++++++++++++++++++++、都市、要素を扱ってください… . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_GEOCONF_CIVIC (36)
オプションコード: オプション_GEOCONF_都市です。(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)の上で見てください。
Schulzrinne Standards Track [Page 6] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[6ページ]RFC4776DHCP
3.3. Element Format
3.3. 要素形式
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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 詳細な以下の説明されるとしての都市のアドレス値。
3.4. Civic Address Components
3.4. 都市のアドレス構成要素
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.
すべての要素が、OPTIONALであり、順不同に現れることができます。
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]として成分値をコード化しなければなりません。 それら、複雑なケースに書かれていて、通例のスペルに従うSHOULD。 複雑なケース、最初の手紙による大文字でスクリプト指示(CAtype128)を書かなければなりません。
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.
特定のスクリプト(CAtype128)と言語(CAtype0)のすべての要素が一緒に分類されるのは、RECOMMENDEDです、それが識別子が必要としたスクリプトと言語の数を減少させるのに従って。
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.
各スクリプトと言語、要素SHOULDに関しては、番号順で最も低いのからそれらのCAtypeで最も高くなるまで含められてください。 一般に、要素はそれに先行する最新の'言語タグ'(CAtype)要素によってその言語とスクリプトでラベルされます。 すべての要素がスクリプトと言語によるというわけではないので、同じCAtypeにおいて複数の要素があれば、クライアントは、CAtypeで要素を蓄積して、次に、最も望ましい言語とスクリプト表現を選択します。
Schulzrinne Standards Track [Page 7] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[7ページ]RFC4776DHCP
+--------+-------+--------------------------------------------------+
| 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| ラベル| 記述| +--------+-------+--------------------------------------------------+ | 1 | A1| 国家の区画分譲地(| | | 状態、州、領域、| 州、県)| | | | | | 2 | A2| カウンティー(教区)は(JP)、地区(IN)を銃撃します。| | | | | | 3 | A3| 都市、郡区、shi(JP)| | | | | | 4 | A4| 都市の分割(自治区、都市の地区)は避けられます。| | | | キャベツ(JP)| | | | | | 5 | A5| 近所、ブロック| | | | | | 6 | A6| 近所レベルの下の通りのグループ| +--------+-------+--------------------------------------------------+ テーブル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).
カリフォルニア(カナダ): 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).
DE(ドイツ): A1は状態(Bundesstaat)、カウンティー(Regierungsbezirk)、都市(Stadt、ゲマインデ)、A2A3A4地区(Bezirk)を表します。 通り接尾語(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が大都会を表す、(フー、)、A2のA3のA4のA5の都市の地区の県(ケン、Do)か都市(シャイ)か農村地域(銃)か区(Ku)か村(ムーラ)と、町(町か町)と、(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が州(する)を表して、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
米国(合衆国): NENA名称へのマッピングは括弧に示されます。 A1は(STA)と状態を命名しています、州と所有物略語が郵政公社Publication28[17]で推薦した2文字を使用してAppendix B. A2はカウンティー、教区(ルイジアナ)、または自治区(アラスカ)を(CNA)に指定します。 A3は都市の共同体名、例えば、都市または町を指定します。 また、それは市の管轄かMSAG共同体名(MCN)として知られています。 都市の共同体名(A3)は反射します。
Schulzrinne Standards Track [Page 8] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[8ページ]RFC4776DHCP
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.
政治上の境界。 これらの境界は歴史的であるか実際的な理由で郵便物の配達課題、郵便の共同体名(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:
追加カリフォルニアタイプは、多くの国に現れて、それらが必要でない、または知られていないところで単に省略されます:
+--------+------+------+---------------------------+----------------+ | 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| 記述| 例| +--------+------+------+---------------------------+----------------+ | 0 | | | 言語| i-デフォルト[3]| | | | | | | | 16 | PRD| PRD| 主な通りの方向| N| | | | | | | | 17 | さや| さや| 引きずっている通りの接尾語| SW| | | | | | | | 18 | 通り| 通り| 通りの接尾語かタイプ| Ave、プラッツ| | | | | | | | 19 | HNO| HNO| 番地| 123 | | | | | | | | 20 | HNS| HNS| 番地接尾語| A、1/2| | | | | | | | 21 | LMK| LMK| 目印か虚栄| コロンビア| | | | | アドレス| 大学| | | | | | | | 22 | LOC| LOC| 追加位置| 南部では、飛んで行ってください。| | | | | 情報| | | | | | | | | 23 | NAM| NAM| (| ジョーのもの| | | | | 住居とオフィス占有者)を命名してください。| 理髪店| | 24 | ファスナ| PC| 郵便の/郵便番号| 10027-1234 | | | | | | | | 25 | | | ビル(構造)| 低い図書館| | | | | | | +--------+------+------+---------------------------+----------------+
Schulzrinne Standards Track [Page 9] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[9ページ]RFC4776DHCP
+--------+------+------+---------------------------+----------------+ | 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 | | +--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+ | CAtype| NENA| PIDF| 記述| 例| +--------+------+------+---------------------------+----------------+ | 26 | | | ユニット(アパート、スイート)| しやすい42| | | | | | | | 27 | | FLR| 床| 4 | | | | | | | | 28 | | | 余地| 450F| | | | | | | | 29 | | | 場所のタイプ| オフィス| | | | | | | | 30 | PCN| | 郵便の共同体名| レオニヤ| | | | | | | | 31 | | | 私書箱(P.O。| 12345 | | | | | 箱) | | | | | | | | | 32 | | | 追加コード| 13203000003 | | | | | | | | 33 | | 席| (| WS181| | | | | 机、小寝室、ワークステーション)を着席させてください。| | | | | | | | | 34 | | | 第一の道路名| ブロードウェイ| | | | | | | | 35 | | | ロードセクション| 14 | | | | | | | | 36 | | | ブランチ道路名| レーン7| | | | | | | | 37 | | | サブブランチ道路名| 路地8| | | | | | | | 38 | | | 通り名プレ修飾語| 古い| | | | | | | | 39 | | | 通り名ポスト修飾語| サービス| | | | | | | | 128 | | | スクリプト| Latn| | | | | | | | 255 | | | 予約されます。| | +--------+------+------+---------------------------+----------------+
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コラムでレッテルを貼られたカリフォルニアタイプがNENAから項目に文通している、「ALIデータ交換、ALI応答、および」 [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同等物がありません。)
Schulzrinne Standards Track [Page 10] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[10ページ]RFC4776DHCP
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].
言語: 「言語」項目(CAtype0)は任意にアドレス情報を提示するのに使用される言語を特定します、[4]で言語を特定するためのタグからの図面、[13]で議論するように。 省略されるなら、このタグのためのデフォルト値は「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".
スクリプト: 「スクリプト」項目(CAtype128)は任意にアドレス情報を提示するのに使用されるスクリプトを特定します、とスクリプトを特定するためのタグからの図面は[13]について[12]で説明して、セクション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.
さや、PRD: 略語N、E、S、WとNE、NW、SE、SW SHOULD、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は通りの接尾語かタイプを任命します。 合衆国(米国)では、略語は、郵政公社Publication28[17]、Appendix C、SHOULDで使用されるように勧めました。
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、CAtype21)がそうすることができる間、ビルの集合体を示してください、と'ビル'は位置を特定しながら、住所が、1つ以上のビルかそれともビル名が役立っているかどうかを含んでいるなら建てられるシングルの名前を伝えます(CAtype25)。
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(「位置」、CAtype22)は位置に関する追加情報を指定する不統一なストリングです、ビルか他の不統一な情報の部分などのように。
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: 郵便の共同体名(CAtype30)と私書箱(CAtype31)で、受取人は郵便の宛先を構成できます。 私書箱分野は「私書箱」という言葉の、または、他の局所的に適切な郵便の名称を含むべきです。
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、CAtype21)はビルの集合体を示すことができますが、(CAtype25)を'建てる'と、住所が位置を特定する際に役立っている1つ以上のビルか存在というビル名を含んでいるなら、単一のビルの名前は伝えられます。 (例えば、ビルの上に大学構内では、しばしば番地を表示するというわけではありませんが、ビル名を顕著に示します。)
Schulzrinne Standards Track [Page 11] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[11ページ]RFC4776DHCP
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.
ユニット: 「ユニット」物(CAtype26)は別々の行政単位、所有者、またはテナントがいる構造の一部の名前か数を含んでいます、その構造を占領する別々の会社や家族のように。 一般的な例はスイートかアパート名称を含んでいます。
Room: A "room" (CAtype 28) is the smallest identifiable subdivision
of a structure.
余地: 「余地」(CAtype28)は構造の最も小さい身元保証可能な下位区分です。
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.
場所のタイプ: 「場所のタイプ」項目(CAtype29)は都市の座標によって説明された場所のタイプについて説明します。 例えば、それは、家、オフィス、通り、または他のパブリックスペースであるかを説明します。 位置のタイプ登録[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.
追加コード: 「追加コード」項目(CAtype32)は位置を特定する追加していて、国の特有のコードを提供します。 例えば、日本に関して、それは日本Industry Standard(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.
以下を着席させてください。 「席」項目(CAtype33)は人が座るかもしれない場所を指定します、スタジアムか劇場の席、または見本市におけるオープン・プラン式のオフィスかブースの小寝室などのように。
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.
第一の道路名: 「第一の道路」項目(CAtype34)をアドレスに関連している道路か通り名に与えます。 CAtypes35〜37が指定されないなら、ビルか指定の場所がその通りで見つけられます。 いくつかのCAtypes35〜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.
ロードセクション: 「ロードセクション」項目(CAtype35)は第一の道路の特定のセクションか広がりを指定します。 これは、新しい往来要素であり、第一の道路が同じ街路番号範囲を再使用するセクションに分割されるところで役に立ちます。
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
支店道路名: 項目という「ブランチ道路名」(CAtype36)は、横切られる道路か通りに関する名前か識別子を表すか、または第一の道路に関連しています。 存在という横町が自治体か他の行政単位の中にユニークな名前を持っていない国だけ、しかし、むしろ使用されるブランチ道路名はそうであるに違いありません。
Schulzrinne Standards Track [Page 12] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[12ページ]RFC4776DHCP
qualified by the name of the primary road name that they branch
off of.
それらが分岐する第一の道路名の名前で、資格を得ました。
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.
サブ支店道路名: 項目という「サブブランチ道路名」(CAtype37)はブランチ道路(CAtype36)で分岐する通りの名前を表します。 サブブランチ道路名はそのような通りがそれらが接続する第一の道路名とブランチ道路に比例して命名される国だけで使用されます。
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".
通り名プレ修飾語: 「通り名プレ修飾語」(CAtype38)は完全な通り名の随意的な要素です。 それは、通り名の他のすべての原理に先行して、それを変更しますが、通り名によって通り名とプレ方向上の状態で切り離される単語か句です。 例は「Old North First通り」で「古いです」。
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".
通り名ポスト修飾語: 「通り名ポスト修飾語」(CAtype39)は完全な通り名の随意的な要素です。 それは、通り名の他のすべての原理に従って、それを変更しますが、通り名によるポスト方向の通り名、そして/または、通りの接尾語と切り離される単語か句です。 例は「イースト・エンドアベニューは広がったところ」で「広げられます」。
4. Postal Addresses
4. 郵便の宛先
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、CAtype24)を含んでいて。 しかしながら、ある要素は、郵便の宛先を作成するために都市のアドレス構成要素をくつがえします。 要素が私書箱(CAtype31)を含んでいるなら、住所コンポーネント(CAtype34、PRD、POD、STS、HNO、HNS)を私書箱要素に取り替えます。 郵便の共同体名を指定するなら、都市の共同体名(通常A3)を郵便の共同体名(PCN、CAtype30)に取り替えます。 国の特有の知識が、有効な郵便の宛先を作成するのに必要です。 そのようなアドレスのフォーマットはこのドキュメントの範囲を超えています。
Schulzrinne Standards Track [Page 13] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[13ページ]RFC4776DHCP
5. Example
5. 例
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 | バイエルン| | | | | 2 | Oberbayern| | | | | 3 | MはU+00FCnchenと等しいです。| | | | | 6 | Marienplatz| | | | | 19 | 8 | | | | | 21 | ラートハウス| | | | | 24 | 80331 | | | | | 29 | 政府建物| | | | | 31 | Postfach1000| | | | | 0 | アン| | | | | 1 | バイエルン| | | | | 3 | ミュンヘン| | | | | 0 | それ| | | | | 1 | Baviera| | | | | 3 | モナコ| +--------+---------------------+
Schulzrinne Standards Track [Page 14] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[14ページ]RFC4776DHCP
6. Security Considerations
6. セキュリティ問題
The security considerations discussed in the GEOPRIV architecture defined by RFC 3693 [9] apply.
RFC3693[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.
[5] 批判的な決定がどこにあるかもしれないかがこのGEOCONF_シビックオプションの値を基礎づけて、RFC3118でのDHCPv4認証はSHOULDです。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サーバとクライアントを要求するとのリンクをモニターできる立ち聞きする者はこのオプションに含まれた情報を発見できます。 したがって、アクセス制限もネットワーク層かリンクレイヤプライバシーメカニズムのないネットワークにおけるこのオプションの用法はNOT RECOMMENDEDです。
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_シビックオプションSHOULDを最小にするには、DHCPv4サーバで、DHCPv4クライアントが'パラメタ要求リスト'(RFC2131[2]、セクション3.5)でこのオプションを入れただけときには、返してください。 同様に、OPTION_GEOCONF_シビックはSHOULDにゆだねます。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.
初期の位置情報を紹介した後に、RFC3694[10]で定義された保護をそれに提供しなければなりません。 DHCPクライアントからDHCPサーバに送ってください。クライアントが、位置情報をサーバに送ると決めるなら、それとなくそのサーバの無制限な保有と分配許容を承諾しているというしたがって、位置の情報SHOULD NOT。
7. IANA Considerations
7. IANA問題
The IANA has registered new DHCPv4 and DHCPv6 option codes for the Civic Address (GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC, respectively).
IANAはシビックAddress(それぞれGEOCONF_シビックとOPTION_GEOCONF_シビック)のために新しい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登録を確立します。 RFC2434[14]について言及して、この登録は「専門のレビュー」と「仕様が必要である」という規則の両方の下で作動します。 IESGは新しいかアップデートされたCAtypeを求める各要求に関して即座にIANAにアドバイスするExpert Reviewerを任命するでしょう。
CAtype: Numeric identifier, assigned by IANA.
CAtype: IANAによって割り当てられた数値識別子。
Brief description: Short description identifying the meaning of the
element.
記述に事情を知らせてください: 要素の意味を特定する短い記述。
Schulzrinne Standards Track [Page 15] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[15ページ]RFC4776DHCP
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登録証明書で定義されません。 より早く注意されるように、国の特有のコンベンションは「[国]への都市のアドレス」と題をつけられたドキュメントに任意に詳しく書かれるかもしれません。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[4] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[4]、BCP47、RFC3066、2001年1月。
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[7]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[8] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002.
[8] レモンとT.とS.チェーシャー州、「Dynamic Host Configuration Protocol(DHCPv4)における長いオプションをコード化します」、RFC3396、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要件」、RFC3693、2004年2月。
Schulzrinne Standards Track [Page 16] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[16ページ]RFC4776DHCP
[10] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
2004年2月の[10]DanleyとM.とマリガンとD.とモリス、J.とJ.ピーターソン、「Geoprivプロトコルの脅威分析」RFC3694。
[11] Schulzrinne, H. and H. Tschofenig, "Location Types Registry",
RFC 4589, July 2006.
[11]SchulzrinneとH.とH.Tschofenig、「位置は登録をタイプする」RFC4589、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、「ISO15924: 2004。」 「情報と文書--、スクリプトの名前の表現のためのコード、」、1月2004日
8.2. Informative References
8.2. 有益な参照
[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.
[14]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(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] ポーク、J.、Schnizlein、J.、およびM.Linsner、「座標ベースの位置の設定情報のためのDynamic Host Configuration Protocolオプション」、RFC3825(2004年7月)。
[16] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[16] ピーターソン、J.、「存在ベースのGEOPRIV位置の物の形式」、RFC4119、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] 有事数のAssocation、「NENAが書式とALIデータ交換のためのプロトコルを推薦して、ALIは応答と地理的情報システムマッピングです」、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、チェン-Hong李、Rohanマーイ、ジェイムズ・ポーク、マーチン・トムソン、およびハンネスTschofenigは役に立つコメントを提供しました。 連邦政府のGeographic Data Committeeの通りAddress Data Standardから例とインスピレーションを得ました。
Schulzrinne Standards Track [Page 17] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[17ページ]RFC4776DHCP
Author's Address
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7004 EMail: hgs+geopriv@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7004年の212 939メール: hgs+ geopriv@cs.columbia.edu URI: http://www.cs.columbia.edu
Schulzrinne Standards Track [Page 18] RFC 4776 DHCP Civic November 2006
2006年11月の都市のSchulzrinne標準化過程[18ページ]RFC4776DHCP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne Standards Track [Page 19]
Schulzrinne標準化過程[19ページ]
一覧
スポンサーリンク
