[要約] RFC 5139は、PIDF-LOのための改訂された市民の位置情報フォーマットに関するものです。その目的は、プレゼンス情報データフォーマットの位置オブジェクトにおける市民の位置情報のフォーマットを改善することです。
Network Working Group M. Thomson
Request for Comments: 5139 J. Winterbottom
Updates: 4119 Andrew
Category: Standards Track February 2008
Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
存在情報データフォーマットロケーションオブジェクト（PIDF-LO）の改訂されたシビックロケーション形式
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate.
このドキュメントでは、市民の場所を表現するためのXML形式を定義しています。この形式は、プレゼンス情報データ形式の場所オブジェクト（PIDF-LO）ドキュメントで使用するために設計されており、RFC 4119のシビックロケーション形式を置き換えます。この形式は、PIDF-LOのシビックアドレス定義に基づいていますが、に基づいていくつかの新しい要素を追加します。動的ホスト構成プロトコル（DHCP）用に定義されたシビックタイプは、複雑な道路IDスキームに対処するための階層を追加します。この形式には、XML：Lang Languageタグのサポートも含まれており、必要に応じて要素の種類を制限します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 3
3.1. Additional Civic Address Types . . . . . . . . . . . . . . 3
3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 4
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 5
3.2.2. Directionals and Other Qualifiers . . . . . . . . . . 5
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 6
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 6
3.5.1. Converting from the DHCP Format . . . . . . . . . . . 7
3.5.2. Combining Multiple Elements Based on Language
Preferences . . . . . . . . . . . . . . . . . . . . . 7
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 10
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Since the publication of the original PIDF-LO civic specification, in [RFC4119], it has been found that the specification is lacking a number of additional parameters that can be used to more precisely specify a civic location. These additional parameters have been largely captured in [RFC4776].
[RFC4119]で元のPIDF-LO CIVIC仕様の公開以来、仕様には、市民の場所をより正確に指定するために使用できる多くの追加パラメーターがないことがわかっています。これらの追加のパラメーターは、[RFC4776]で主にキャプチャされています。
This document revises the GEOPRIV civic form to include the additional civic parameters captured in [RFC4776]. The document also introduces a hierarchical structure for thoroughfare (road) identification, which is employed in some countries. New elements are defined to allow for even more precision in specifying a civic location.
この文書は、[RFC4776]でキャプチャされた追加の市民パラメーターを含めるために、Geopriv市民形式を修正します。このドキュメントでは、一部の国で採用されている大通り（道路）識別のための階層構造も導入されています。新しい要素は、市民の場所を指定する際にさらに精度を可能にするために定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The term "thoroughfare" is used in this document to describe a road or part of a road or other access route along which a final point is identified. This is consistent with the definition used in [UPU-S42].
このドキュメントでは、「大通り」という用語が使用されており、道路または道路またはその他のアクセスルートの一部を説明し、最終的なポイントが特定されます。これは、[UPU-S42]で使用される定義と一致しています。
[RFC4776] provides a full set of parameters that may be used to describe a civic location. Specifically, [RFC4776] lists several civic address types (CAtypes) that require support in the formal PIDF-LO definition that are not in [RFC4119].
[RFC4776]は、市民の場所を説明するために使用できるパラメーターの完全なセットを提供します。具体的には、[RFC4776]は、[RFC4119]にない正式なPIDF-LO定義でサポートを必要とするいくつかの市民アドレスタイプ（CATYPE）をリストしています。
These changes include new elements that are required to support more complex structures for naming street addresses. This is described in more detail in Section 3.2.
これらの変更には、通りの住所を命名するためのより複雑な構造をサポートするために必要な新しい要素が含まれます。これについては、セクション3.2で詳しく説明します。
+-----------+--------+-------------------------------+--------------+
| New Field | CAtype | Description | Example |
+-----------+--------+-------------------------------+--------------+
| BLD | 25 | Building (structure) | Hope Theatre |
| | | | |
| UNIT | 26 | Unit (apartment, suite) | 12a |
| | | | |
| ROOM | 28 | Room | 450F |
| | | | |
| PLC | 29 | Place-type | office |
| | | | |
| PCN | 30 | Postal community name | Leonia |
| | | | |
| POBOX | 31 | Post office box (P.O. box) | U40 |
| | | | |
| ADDCODE | 32 | Additional Code | 13203000003 |
| | | | |
| SEAT | 33 | Seat (desk, cubicle, | WS 181 |
| | | workstation) | |
| | | | |
| RD | 34 | Primary road or street | Broadway |
| | | | |
| RDSEC | 35 | Road section | 14 |
| | | | |
| RDBR | 36 | Road branch | Lane 7 |
| | | | |
| RDSUBBR | 37 | Road sub-branch | Alley 8 |
| | | | |
| PRM | 38 | Road pre-modifier | Old |
| | | | |
| POM | 39 | Road post-modifier | Extended |
+-----------+--------+-------------------------------+--------------+
Table 1: New Civic PIDF-LO Types
表1：新しいCivic PIDF-LOタイプ
A complete description of these types is included in [RFC4776].
これらのタイプの完全な説明は[RFC4776]に含まれています。
In some countries, a thoroughfare can be broken up into sections, and it is not uncommon for street numbers to be repeated between sections. A road section identifier is required to ensure that an address is unique. For example, "West Alice Parade" in the figure below has 5 sections, each numbered from 1; unless the section is specified, "7 West Alice Parade" could exist in 5 different places. The "RDSEC" element is used to specify the section.
一部の国では、大通りがセクションに分割される可能性があり、セクション間で街路番号を繰り返すことは珍しくありません。住所が一意であることを確認するには、道路セクション識別子が必要です。たとえば、下の図の「ウェストアリスパレード」には5つのセクションがあり、それぞれが1から数字があります。セクションが指定されていない限り、「7 West Aliceパレード」は5つの異なる場所に存在する可能性があります。「RDSEC」要素は、セクションを指定するために使用されます。
Minor streets can share the same name, so that they can only be distinguished by the major thoroughfare with which they intersect. For example, both "West Alice Parade, Section 3" and "Bob Street" could both be intersected by a "Carol Lane". The "RDBR" element is used to specify a road branch where the name of the branch does not uniquely identify the road. Road branches MAY also be used where a major thoroughfare is split into sections.
Similar to the way that a road branch is associated with a road, a road sub-branch is associated with a road branch. The "RDSUBBR" element is used to identify road sub-branches.
道路枝が道路に関連付けられている方法と同様に、道路サブブランチは道路枝に関連付けられています。「rdsubbr」要素は、道路サブブランチを識別するために使用されます。
The "A6" element is retained for use in those countries that require this level of detail. Where "A6" was previously used for street names in [RFC4119], it MUST NOT be used; the "RD" element MUST be used for thoroughfare data.
「A6」要素は、このレベルの詳細を必要とする国で使用するために保持されます。[A6]は以前[RFC4119]のストリート名に使用されていた場合、使用してはなりません。「RD」要素は、大通りデータに使用する必要があります。
The following figure shows a fictional arrangement of roads where these new thoroughfare elements are applicable.
次の図は、これらの新しい大通り要素が適用される道路の架空の配置を示しています。
| ||
| ---------------||
| Carol La. Carol La. || Bob
| || St.
| West Alice Pde. ||
==========/=================/===============/==========||===========
Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5
| ||
----------| Carol ||
Alley 2 | La. ||
| ||
The introduction of new thoroughfare elements affects the interpretation of several aspects of more specific civic address data. In particular, street numbering (the "HNO" element) applies to the most specific road element specified, that is, the first specified element from "RDSUBBR", "RDBR", "RDSEC", or "RD".
新しい大通り要素の導入は、より具体的な市民住所データのいくつかの側面の解釈に影響します。特に、通りの番号（「HNO」要素）は、指定された最も特定の道路要素、つまり「rdsubbr」、「rdbr」、「rdsec」、または「rd」の最初の指定要素に適用されます。
The "PRM", "POM", "PRD", "POD", and "STS" elements always apply to the value of the "RD" element only. If road branches or sub-branches require street suffixes or qualifiers, they MUST be included in the "RDBR" or "RDSUBBR" element text.
「PRM」、「POM」、「PRD」、「POD」、および「STS」要素は、常に「RD」要素の値にのみ適用されます。道路枝またはサブブランチが通りの接尾辞または予選を必要とする場合、それらは「RDBR」または「RDSUBBR」要素テキストに含める必要があります。
The "country" element differs from that defined in [RFC4119] in that it now restricts the value space of the element to two uppercase characters, which correspond to the alpha-2 codes in [ISO.3166-1].
「国」要素は、[RFC4119]で定義されている要素とは異なります。これは、[ISO.3166-1]のアルファ-2コードに対応する2つの大文字に要素の値空間を2つの大文字に制限するという点では異なります。
The "A1" element is used for the top-level subdivision within a country. In the absence of a country-specific guide on how to use the A-series of elements, the second part of the ISO 3166-2 code [ISO.3166-2] for a country subdivision SHOULD be used. The ISO 3166-2 code is formed of a country code and hyphen plus a code of one, two, or three characters or numerals. For the "A1" element, the leading country code and hyphen are omitted and only the subdivision code is included.
「A1」要素は、国内のトップレベルの区画に使用されます。A-Series of Elementsの使用方法に関する国固有のガイドがない場合、ISO 3166-2コード[ISO.3166-2]の第2部を使用する必要があります。ISO 3166-2コードは、カントリーコードとハイフンに加えて、1、2、または3つの文字または数字のコードで形成されます。「A1」要素の場合、主要な国のコードとハイフンは省略されており、区画コードのみが含まれています。
For example, the codes for Canada include CA-BC, CA-ON, CA-QC; Luxembourg has just three single-character codes, LU-D, LU-G, and LU-L; Australia uses both two- and three-character codes, AU-ACT, AU-NSW, AU-NT; and France uses numerical codes for mainland France and letters for territories, FR-75, FR-NC. This results in the following fragments:
たとえば、カナダのコードには、CA-BC、CA-ON、CA-QCが含まれます。ルクセンブルクには、Lu-D、Lu-G、Lu-Lの3つのシングルキャラクターコードしかありません。オーストラリアは、2文字と3文字の両方のコード、Au-act、au-nsw、au-ntを使用しています。フランスは、フランス本土の数値コードと、領土の手紙、FR-75、FR-NCを使用しています。これにより、次のフラグメントが得られます。
<country>CA</country><A1>ON</A1>
<country>LU</country><A1>L</A1>
<country>AU</country><A1>ACT</A1>
<country>FR</country><A1>75</A1>
The XML schema defined for civic addresses allows for the addition of the "xml:lang" attribute to all elements except "country" and "PLC", which both contain language-neutral values. The range of allowed values for "country" is defined in [ISO.3166-1]; the range of allowed values for "PLC" is described in the IANA registry defined by [RFC4589].
市民アドレス用に定義されたXMLスキーマは、言語中立値を含む「国」と「PLC」を除くすべての要素に「XML：LANG」属性を追加できます。「国」の許容値の範囲は[ISO.3166-1]で定義されています。「PLC」の許容値の範囲は、[RFC4589]で定義されたIANAレジストリで説明されています。
The "script" field defined in [RFC4776] is omitted in favor of using the "xml:lang" attribute with a script subtag [RFC4646].
[RFC4776]で定義されている「スクリプト」フィールドは、スクリプトサブタグ[RFC4646]を使用して「XML：Lang」属性を使用することを支持して省略されています。
It is RECOMMENDED that each "civicAddress" element use one language only, or a combination of languages that is consistent. Where a civic location is represented in multiple languages, multiple "civicAddress" elements SHOULD be included in the PIDF-LO document.
それぞれの「CivicAddress」要素は、1つの言語のみ、または一貫した言語の組み合わせを使用することをお勧めします。市民の場所が複数の言語で表されている場合、複数の「市民」要素をPIDF-LOドキュメントに含める必要があります。
For civic addresses that form a complex to describe the same location, these SHOULD be inserted into the same tuple.
同じ場所を記述する複合施設を形成する市民住所の場合、これらは同じタプルに挿入する必要があります。
The DHCP format for civic addresses [RFC4776] permits the inclusion of an element multiple times with different languages or scripts. However, this XML form only permits a single instance of each element. Multiple "civicAddress" elements are required if any element is duplicated with different languages. If the same language and script are used for all elements, or no elements are duplicated, the format can be converted into a single civic address.
市民アドレス[RFC4776]のDHCP形式では、異なる言語やスクリプトで要素を複数回含めることができます。ただし、このXMLフォームは、各要素の単一のインスタンスのみを許可します。異なる言語で複数の要素が複製されている場合、複数の「市民」要素が必要です。すべての要素に同じ言語とスクリプトが使用されている場合、または要素が複製されていない場合、形式は単一の市民アドレスに変換できます。
Where there are duplicated elements in different languages, a "civicAddress" element is created for each language that is present. All elements that are in that language are included. Elements that are language independent, like the "country" and "PLC" elements, are added to all "civicAddress" elements.
異なる言語に複製された要素がある場合、存在する各言語に対して「市民」要素が作成されます。その言語にあるすべての要素が含まれています。「国」や「PLC」要素のような言語に依存しない要素は、すべての「市民装飾」要素に追加されます。
If the receiver of the XML representation is known, and that receiver has indicated language preferences, a single XML format can be constructed using those preferences. For example, language preferences can be indicated by the "Accept-Language" header in the SIP or HTTP protocols.
XML表現の受信機が既知であり、その受信機が言語の好みを示している場合、それらの設定を使用して単一のXML形式を構築できます。たとえば、言語の好みは、SIPまたはHTTPプロトコルの「受け入れ言語」ヘッダーで示すことができます。
All elements that have only one value, irrespective of language, are used. Where multiple values exist, each value is assigned a weighting based on the language preferences. The value with the highest weighting is selected. An arbitrary value is selected if two values have the same preference, if there is no preference for the available languages, or if there are conflicting values with the same language.
言語に関係なく、値が1つしかないすべての要素が使用されます。複数の値が存在する場合、各値には言語設定に基づいて重みが割り当てられます。最高の重み付けの値が選択されます。2つの値が同じ好みを持っている場合、利用可能な言語の好みがない場合、または同じ言語で競合する値がある場合、任意の値が選択されます。
The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 uses a base type of "token" instead of "string" as used in [RFC4119].
セクション4で定義されているXMLスキーマ[W3C.REC-XMLSCHEMA-2-20041028]は、[RFC4119]で使用される「文字列」の代わりに「トークン」のベースタイプを使用します。
The "token" type ensures that whitespace within instance documents is normalized and collapsed before being passed to a processor. This ensures that the following fragments are considered equivalent by XML processors:
「トークン」タイプは、インスタンスドキュメント内の白人が正規化され、崩壊してからプロセッサに渡されることを保証します。これにより、次のフラグメントがXMLプロセッサと同等と見なされることが保証されます。
<A4>North Wollongong</A4>
<A1>North
Wollongong</A1>
<A1> North Wollongong </A1>
<a1>ノースウロンゴン</a1>
Whitespace may still be included in values by using character references, such as " ".
「＆＃x20;」などの文字参照を使用することにより、Whitespaceは引き続き値に含まれる場合があります。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="iso3166a2">
<xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="caType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="civicAddress" type="ca:civicAddress"/>
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="ca:iso3166a2" minOccurs="0"/>
<xs:element name="A1" type="ca:caType" minOccurs="0"/>
<xs:element name="A2" type="ca:caType" minOccurs="0"/>
<xs:element name="A3" type="ca:caType" minOccurs="0"/>
<xs:element name="A4" type="ca:caType" minOccurs="0"/>
<xs:element name="A5" type="ca:caType" minOccurs="0"/>
<xs:element name="A6" type="ca:caType" minOccurs="0"/>
<xs:element name="PRM" type="ca:caType" minOccurs="0"/>
<xs:element name="PRD" type="ca:caType" minOccurs="0"/>
<xs:element name="RD" type="ca:caType" minOccurs="0"/>
<xs:element name="STS" type="ca:caType" minOccurs="0"/>
<xs:element name="POD" type="ca:caType" minOccurs="0"/>
<xs:element name="POM" type="ca:caType" minOccurs="0"/>
<xs:element name="RDSEC" type="ca:caType" minOccurs="0"/>
<xs:element name="RDBR" type="ca:caType" minOccurs="0"/>
<xs:element name="RDSUBBR" type="ca:caType" minOccurs="0"/>
<xs:element name="HNO" type="ca:caType" minOccurs="0"/>
<xs:element name="HNS" type="ca:caType" minOccurs="0"/>
<xs:element name="LMK" type="ca:caType" minOccurs="0"/>
<xs:element name="LOC" type="ca:caType" minOccurs="0"/>
<xs:element name="FLR" type="ca:caType" minOccurs="0"/>
<xs:element name="NAM" type="ca:caType" minOccurs="0"/>
<xs:element name="PC" type="ca:caType" minOccurs="0"/>
<xs:element name="BLD" type="ca:caType" minOccurs="0"/>
<xs:element name="UNIT" type="ca:caType" minOccurs="0"/>
<xs:element name="ROOM" type="ca:caType" minOccurs="0"/>
<xs:element name="SEAT" type="ca:caType" minOccurs="0"/>
<xs:element name="PLC" type="xs:token" minOccurs="0"/>
<xs:element name="PCN" type="ca:caType" minOccurs="0"/>
<xs:element name="POBOX" type="ca:caType" minOccurs="0"/>
<xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
<civicAddress xml:lang="en-AU"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AU</country>
<A1>NSW</A1>
<A3> Wollongong
</A3><A4>North Wollongong
</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<LMK>
Gilligan's Island
</LMK> <LOC>Corner</LOC>
<NAM> Video Rental Store </NAM>
<PC>2500</PC>
<ROOM> Westerns and Classics </ROOM>
<PLC>store</PLC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
The XML representation described in this document is designed for inclusion in a PIDF-LO document. As such, it is subject to the same security considerations as are described in [RFC4119]. Considerations relating to the inclusion of this representation in other XML documents are outside the scope of this document.
このドキュメントで説明されているXML表現は、PIDF-LOドキュメントに含めるように設計されています。そのため、[RFC4119]で説明されているのと同じセキュリティ上の考慮事項の対象となります。他のXMLドキュメントにこの表現を含めることに関する考慮事項は、このドキュメントの範囲外です。
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
This document defines a new XML namespace (as per the guidelines in [RFC3688]) that has been registered with IANA.
このドキュメントでは、IANAに登録されている新しいXML名前空間（[RFC3688]のガイドラインに従って）を定義しています。
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@andrew.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Civic Address</title>
</head>
<body>
<h1>Format for Distributing Civic Address in GEOPRIV</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt">
RFC5139</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順に従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Martin Thomson（martin.thomson@andrew.com）。
The XML for this schema can be found as the entirety of Section 4 of this document.
このスキーマのXMLは、このドキュメントのセクション4の全体として見つけることができます。
This document updates the civic address type registry established by [RFC4776]. The "PIDF" column of the CAtypes table has been updated to include the types shown in the first column of Table 1.
このドキュメントは、[RFC4776]によって確立されたCivic Address Typeレジストリを更新します。Catypesテーブルの「PIDF」列が更新され、表1の最初の列に示されているタイプが含まれています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2-20041028] Biron、P。およびA. Malhotra、「XML Schema Part 2：DataTypes Second Edition」、World Wide Webコンソーシアムの推奨REC-XMLSCHEMA-20041028、2004年10月、<http：//www.w3.org/tr/2004/rec-xmlschema-2-20041028>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[RFC4589] Schulzrinne、H。およびH. Tschofenig、「Location Types Registry」、RFC 4589、2006年7月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 4646、2006年9月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Dynamic Host Configuration Protocol（DHCPV4およびDHCPV6）オプションCIVICアドレス構成情報」、RFC 4776、2006年11月。
[ISO.3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166- 1:1997, 1997.
[ISO.3166-1]国際標準化機関、「国の名前とその下位区分の表現のためのコード - パート1：国コード」、ISO標準3166- 1：1997、1997。
[ISO.3166-2] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO Standard 3166-2:1998, 1998.
[ISO.3166-2]国際標準化機関、「国の名前とその下位区分の表現のためのコード - パート2：国区分コード」、ISO標準3166-2：1998、1998。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[UPU-S42] Universal Postal Union (UPU), "International Postal Address Components and Templates", UPS SB42-4, July 2004.
[UPU-S42] Universal Postal Union（UPU）、「国際郵便住所コンポーネントとテンプレート」、UPS SB42-4、2004年7月。
The authors would like to thank Henning Schulzrinne for his assistance in defining the additional civic address types, particularly his research into different addressing schemes that led to the introduction of the thoroughfare elements. Rohan Mahy suggested the ISO 3166-2 recommendation for A1. In addition, we would like to thank Jon Peterson for his work in defining the PIDF-LO.
著者は、追加の市民住所タイプ、特に大通りの要素の導入につながったさまざまなアドレス指定スキームに関する彼の研究を定義する際の彼の支援について、ヘニング・シュルツリンヌに感謝したいと思います。Rohan Mahyは、A1のISO 3166-2の推奨を提案しました。さらに、Jon PetersonがPIDF-LOを定義する際の彼の仕事に感謝したいと思います。
Authors' Addresses
著者のアドレス
Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
マーティントムソンアンドリューポックスU40ウロンゴン大学キャンパス、NSW 2500 AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
ジェームズウィンターボトムアンドリューポックスU40ウロンゴン大学キャンパス、NSW 2500 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。