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)
        

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)のために定義され、複雑な道路アイデンティティスキームに対処するために階層を追加します。 langの言語タグを、適切な要素のタイプを制限:フォーマットは、XMLをサポートしています。

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
        
1. Introduction
1. はじめに

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].

オリジナルPIDF-LO市民仕様の出版以来、[RFC4119]には、仕様がより正確に市民の場所を指定するために使用できる追加のパラメータの数を欠いていることが見出されました。これらの追加のパラメータは、主に[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市民フォームを修正します。文書はまた、いくつかの国で採用されている大通り(道路)の識別のための階層構造を導入します。新しい要素は、市民の位置を指定する際にも、より精度を可能にするために定義されています。

2. Terminology
2.用語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]で使用される定義と一致しています。

3. Changes from PIDF-LO
PIDF-LOから3の変更点
3.1. Additional Civic Address Types
3.1. 追加のシビックアドレス型

[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定義のサポートを必要とするいくつかの市民のアドレスタイプ(CAtypes)を示します。

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:新しいシビックPIDF-LOタイプ

A complete description of these types is included in [RFC4776].

これらのタイプの完全な記述は、[RFC4776]に含まれています。

3.2. New Thoroughfare Elements
3.2. 新しいいろいろな道の要素

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西アリスパレード」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.

彼らは彼らだけが交差した主要な大通りで区別できるように、細街路は、同じ名前を共有することができます。たとえば、「ウェスト・アリスパレード、第3節」と「ボブ・ストリート」の両方が両方とも「キャロル・レーン」が交差することができます。 「RDBR」要素は、枝の名前が一意に道路を識別しない道路の分岐を指定するために使用されます。主要な大通りをセクションに分割されている道路の枝を使用してもよいです。

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.          ||
                                           |               ||
        
3.2.1. Street Numbering
3.2.1. ストリート番号

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」から最初に指定された要素を適用します。

3.2.2. Directionals and Other Qualifiers
3.2.2. Directionalsおよびその他の修飾子

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」要素のテキストに含まれなければなりません。

3.3. Country Element
3.3. 国の要素

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].

「国」要素は、それが今[ISO.3166-1]におけるα-2コードに対応する2つの大文字への要素の値空間を制限することで、[RFC4119]で定義されたものとは異なります。

3.4. A1 Element
3.4. A1エレメント

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シリーズを使用する方法に関する国特有のガイドの不在下では、国の細分化のためのISO 3166-2コード[ISO.3166-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を含みます。ルクセンブルグは、わずか3つの文字コード、LU-D、LU-G、及びLU-Lを有します。オーストラリアは、2と3文字のコード、AU-ACT、AU-NSW、AU-NTの両方を使用しています。そして、フランスは、フランス本土と地域のための文字の数値コードを使用していますFR-75、FR-NC。これは、以下の破片のような結果になります。

<country>CA</country><A1>ON</A1>

<国> CA </国> <A1> ON </ A1>

<country>LU</country><A1>L</A1>

<国> LU </国> <A1> L </ A1>

<country>AU</country><A1>ACT</A1>

<国> AU </国> <A1> ACT </ A1>

<country>FR</country><A1>75</A1>

<国> FR </国> <A1> 75 </ A1>

3.5. Languages and Scripts
3.5. 言語とスクリプト

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].

両方は言語に依存した値が含まれている「国」と「PLC」を除くすべての要素に属性:市民のアドレスのために定義されたXMLスキーマは、「LANG XML」を追加できます。 「国」の許容値の範囲は[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]で定義された「スクリプト」フィールドが使用しての賛成で省略されている「XMLを:LANG」スクリプトサブタグ[RFC4646]の属性。

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つの言語だけ、または一貫性のある言語の組み合わせを使用することをお勧めします。市民の位置が複数の言語で表現される場合、複数の「civicAddress」要素は、PIDF-LOの文書に含まれるべきです。

For civic addresses that form a complex to describe the same location, these SHOULD be inserted into the same tuple.

同じ場所を説明する複合体を形成する市民のアドレスのため、これらは同じタプルに挿入されるべきです。

3.5.1. Converting from the DHCP Format
3.5.1. DHCPのフォーマットからの変換

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形式は、各要素の単一インスタンスを可能にします。いずれかの要素が異なる言語で重複している場合には、複数の「civicAddress」の要素が必要とされています。同じ言語やスクリプトは、すべての要素のために使用されている、あるいは全くの要素が重複されていない場合、フォーマットは、単一の市民のアドレスに変換することができます。

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.

異なる言語での重複要素がある場合には、「civicAddress」要素が存在している各言語用に作成されます。その言語であるすべての要素が含まれています。 「国」と「PLC」の要素のように、言語に依存している要素は、すべて「civicAddress」の要素に追加されます。

3.5.2. Combining Multiple Elements Based on Language Preferences
3.5.2. 言語設定に基づいて複数の要素を組み合わせます

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.

かかわらず、言語の一つの値だけを、持っているすべての要素は、使用されています。複数の値が存在する場合、それぞれの値は、言語設定に基づいて重みを割り当てられます。最も高い重みを持つ値が選択されます。二つの値が同じ嗜好を持っている場合、任意の値が使用可能な言語のための嗜好がない場合、または同じ言語と競合する値がある場合、選択されます。

3.6. Whitespace
3.6. 空白

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].

XMLスキーマは、[W3C.REC-XMLSCHEMA-2から20041028]セクション4で定義は、[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>

<A4>北ウロンゴン</ A4>

<A1>North Wollongong</A1>

<A1>北ウロンゴン</ A1>

<A1> North Wollongong </A1>

<A1>北ウロンゴン</ A1>

Whitespace may still be included in values by using character references, such as "&#x20;".

空白はまだのような、文字参照を使用して値に含まれることができる「&#のX20;」。

4. Civic Address Schema
4.シビック住所スキーマ

<?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 <xmlのバージョン= "1.0"?>:スキーマのtargetNamespace = "壷:IETF:のparams:XML:NS:PIDF:geopriv10:civicAddr" のxmlns:XS = "http://www.w3.org/2001/ XMLスキーマ」のxmlns:CA = "壷:IETF:のparams:XML:NS:PIDF:geopriv10:civicAddr" のxmlns:XML = "http://www.w3.org/XML/1998/namespace" のelementFormDefault = "資格" attributeFormDefault > = "修飾されていません"

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<XS:インポート名前空間= "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:simpleTypeの名前= "iso3166a2"> <XS:制限ベース= "XS:トークン"> <XS:パターン値= "[A-Z] {2}" /> </ XS:制限> </ 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:complexTypeの名前= "caType"> <XS:simpleContentを> <XS:増設ベース= "XS:トークン"> <XS:属性REF = "XML:LANG" 使用= "オプション" /> </ XS:拡張> </ 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>

<XS:要素名= "civicAddress" タイプ= "CA:civicAddress" /> <XS:complexTypeの名前= "civicAddress"> <XS:シーケンス> <XS:要素名= "国" タイプ= "CA:iso3166a2" のminOccurs = "0" /> <XS:要素名= "A1" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "A2" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "A3" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "A4" タイプ= "CA:caType" のminOccurs = "0" /> <XS :要素名= "A5" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "A6" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "PRM" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "PRD" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "RD" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "STS" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "POD" タイプ= "CA: caType」のminOccurs = "0" /> <XS:要素名= "POM" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "RDSEC" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "RDBR" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "RDSUBBR" タイプ= "CA:caType" minOc CURS = "0" /> <XS:要素名= "HNO" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "HNS" タイプ= "CA:caType" のminOccurs = "0 "/> <XS:要素名=" LMK」タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "LOC" タイプ= "CA:caType" のminOccurs = "0" /> < XS:要素名= "FLR" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "NAM" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "PC" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "BLD" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名は= "UNIT"タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "ROOM" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "SEAT" タイプ= "CA :caType」のminOccurs = "0" /> <XS:要素名= "PLC" タイプ= "XS:トークン" のminOccurs = "0" /> <XS:要素名= "PCN" タイプ= "CA:caType" minOccurs属性= "0" /> <XS:要素名= "POBOX" タイプ= "CA:caType" のminOccurs = "0" /> <XS:要素名= "ADDCODE" タイプ= "CA:caType" のminOccurs = "0" /> <XS:任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:シーケンス> <XS:anyAttributeは名前空間= "##任意の" PROC essContents = "緩い" /> </ XS:complexTypeの> </ XS:スキーマ>

5. Example
5.例

<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>

<civicAddressのXML:LANG = "EN-AU" のxmlns = "壷:IETF:のparams:XML:NS:PIDF:geopriv10:civicAddr"> <国> AU </国> <A1> NSW </ A1> <A3>ウロンゴン</ A3> <A4>北ウロンゴン</ A4> <RD>フリンダース</ RD> <STS>ストリート</ STS> <RDBR>キャンベルストリート</ RDBR> <LMK>ギリガン君SOS </ LMK> <LOC >コーナー</ LOC> <NAM>ビデオレンタル店</ NAM> <PC> 2500 </ PC> <ROOM>西部劇とクラシック</ ROOM> <PLC>店舗</ PLC> <POBOX>専用ボックス15 </ POBOX> </ civicAddress>

6. Security Considerations
6.セキュリティの考慮事項

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. IANA Considerations
7. IANAの考慮事項

7.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'

7.1. URNのためのサブ名前空間の登録 '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に登録されている([RFC3688]のガイドラインに従って)新しいXML名前空間を定義します。

URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr

URI:URN:IETF:Paramの: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@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
        
7.2. XML Schema Registration
7.2. XML Schemaの登録

This section registers an XML schema as per the procedures in [RFC3688].

このセクションでは、[RFC3688]の手順に従ってXMLスキーマを登録します。

URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr

URI:URN:IETF:Paramの:XML:スキーマ: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@andrew.com)。

The XML for this schema can be found as the entirety of Section 4 of this document.

このスキーマのXMLは、このドキュメントのセクション4の全体として求めることができます。

7.3. CAtype Registry Update
7.3. CAtypeレジストリの更新

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]によって確立された市民のアドレスタイプのレジストリを更新します。 CAtypesテーブルの「PIDF」の欄は、表1の第1欄に示すタイプを含むように更新されました。

8. References
8.参照文献
8.1. Normative References
8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2:データ型第二版"、World Wide Web Consortium(W3C)の勧告REC-XMLSCHEMA-2から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]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。

[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.

[RFC4589] Schulzrinneと、H.およびH. Tschofenig、 "場所の種類レジストリ"、RFC 4589、2006年7月。

[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.

[RFC4646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、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.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル(DHCPv4とDHCPv6の)オプションは、構成情報をアドレス"。

[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。

8.2. Informative References
8.2. 参考文献

[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]万国郵便連合(UPU)、 "国際郵便住所コンポーネントやテンプレート"、UPS SB42-4、2004年7月。

Appendix A. Acknowledgements

付録A.謝辞

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.

著者は、追加の市民のアドレスタイプを定義する際に彼の援助、大通り要素の導入につながった別のアドレス指定方式に特に彼の研究のためのヘニングSchulzrinneとに感謝したいと思います。ロハンマーイはA1のためのISO 3166-2勧告を示唆しました。また、当社は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/

電話:+61 2 4221 2915 Eメール: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/

電話:+61 2 4221 2938 Eメール:james.winterbottom@andrew.com URI:http://www.andrew.com/

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(C)IETFトラスト(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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に情報を記述してください。