[要約] RFC 6848は、PIDF-LO（Presence Information Data Format Location Object）で市民住所拡張を指定するための仕様です。このRFCの目的は、PIDF-LOの機能を拡張し、市民住所情報を正確に表現することです。
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6848 CommScope
Updates: 4776, 5222 M. Thomson
Category: Standards Track Skype
ISSN: 2070-1721 R. Barnes
BBN Technologies
B. Rosen
NeuStar, Inc.
R. George
Huawei Technologies
January 2013
Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
プレゼンス情報データ形式のロケーションオブジェクト（PIDF-LO）でのCivicアドレス拡張の指定
Abstract
概要
New fields are occasionally added to civic addresses. A backward-compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process.
新しいフィールドが市民の住所に追加されることがあります。 Geoprivの市民の住所形式に市民の住所要素を追加するための下位互換性のあるメカニズムについて説明します。この変換を実行する必要があるエンティティに対して、XMLとDHCPのシビックアドレスフォーム間の変換時にサポートされていない拡張を処理するための正式なメカニズムが定義されています。一部の新しい要素の初期拡張も定義されています。ロケーション情報の検証に使用されるシビックアドレス要素名を返すロケーションからサービスへの変換（LoST）プロトコルメカニズム（RFC 5222で定義）が明確化され、一部として返される各シビックアドレス要素に適格な名前空間識別子を要求するように規範的に更新されています検証プロセスの。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6848.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6848で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9
5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
5.6. Extension Examples . . . . . . . . . . . . . . . . . . . . 11
6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CAtype Registration for Extensions . . . . . . . . . . . . 13
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
8.4. Registration of the CAtypes Defined in this Document . . . 15
8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
8.6. URN Sub-Namespace Registration . . . . . . . . . . . . . . 17
8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
The Geopriv civic location specifications ([RFC4776], [RFC5139]) define an XML and binary representations for civic addresses that allow for the expression of civic addresses. Guidance for the use of these formats for the civic addresses in different countries is included in [RFC5774].
Geoprivの市民の場所の仕様（[RFC4776]、[RFC5139]）は、市民の住所の表現を可能にする市民の住所のXMLおよびバイナリ表現を定義します。さまざまな国の市民の住所にこれらの形式を使用するためのガイダンスは、[RFC5774]に含まれています。
Subsequent to these specifications being produced, use cases for
extending the civic address format with new elements have emerged.
[RFC5774] describes a mechanism for mapping long-standing address
formats into the civic address elements defined in [RFC4776] and
[RFC5139]. However, some of these existing address elements do not
readily fit into the civic address elements defined in [RFC4776] and
[RFC5139]. In these cases, creating new civic address elements
provides a better solution than overloading existing civic address
fields, which may cause confusion.
The XML format for civic addresses [RFC5139] provides a mechanism that allows for the addition of standardized or privately understood elements. A similar facility for private extension is not provided for the DHCP format [RFC4776], though new specifications are able to define new CAtypes (civic address types).
市民の住所のXML形式[RFC5139]は、標準化された要素または私的に理解された要素の追加を可能にするメカニズムを提供します。 DHCPフォーマット[RFC4776]では、プライベート拡張用の同様の機能は提供されていませんが、新しい仕様では新しいCAタイプ（シビックアドレスタイプ）を定義できます。
A recipient of a civic address in either format currently has no option other than to ignore elements that it does not understand. This results in any elements that are unknown to that recipient being discarded if a recipient performs a translation between the two formats. In order for a new extension to be preserved through translation by any recipient, the recipient has to understand the extension and know how to correlate an XML element with a CAtype.
現在、どちらの形式の市民住所の受信者も、理解できない要素を無視する以外に選択肢はありません。これにより、受信者が2つの形式間の変換を実行した場合、その受信者にとって不明な要素は破棄されます。受信者が翻訳を通じて新しい拡張機能を保持するには、受信者は拡張機能を理解し、XML要素をCAtypeと関連付ける方法を知っている必要があります。
This document describes how new civic address elements are added. Extensions always start with the definition of XML elements. A mechanism for carrying the extension in the DHCP format is described. A new XML namespace containing a small number of additional civic elements is also defined and can be used as a template to illustrate how other extensions can be defined as required.
このドキュメントでは、新しい市民住所要素が追加される方法について説明します。拡張機能は常にXML要素の定義から始まります。 DHCP形式で拡張機能を伝送するメカニズムについて説明します。少数の追加のCivic要素を含む新しいXML名前空間も定義されており、必要に応じて他の拡張を定義する方法を示すテンプレートとして使用できます。
These mechanisms ensure that any translation between formats can be performed consistently and without loss of information. Translation between formats can occur without knowledge of every extension that is present.
これらのメカニズムにより、フォーマット間の変換を一貫して、情報を失うことなく実行できます。フォーマット間の変換は、存在するすべての拡張子を知らなくても発生する可能性があります。
The registry of numeric CAtypes is modified so that the creators of extensions can advertise new namespaces and civic elements to encourage maximum reuse.
数値CAtypeのレジストリが変更され、拡張機能の作成者が新しい名前空間とシビックエレメントをアドバタイズして、最大限の再利用を促進できるようになりました。
The additions described in this document are backwardly compatible. Existing implementations may cause extension information to be lost, but the presence of extensions does not affect an implementation that conforms to either [RFC4776] or [RFC5139].
このドキュメントで説明する追加機能には、下位互換性があります。既存の実装では拡張情報が失われる可能性がありますが、拡張の存在は[RFC4776]または[RFC5139]のいずれかに準拠する実装には影響しません。
This document also normatively updates [RFC5222] to clarify that the namespace must be included with the element name in the lists of valid, invalid, and not checked elements in the <locationValidation> part of a Location-to-Service Translation (LoST) response. While the LoST schema does not need to be changed, the example in the document is updated to show the namespaces in the lists.
また、このドキュメントは[RFC5222]を規範的に更新して、Location-to-Service Translation（LoST）応答の<locationValidation>部分の有効、無効、およびチェックされていない要素のリストに要素名とともに名前空間を含める必要があることを明確にします。 LoSTスキーマを変更する必要はありませんが、ドキュメントの例が更新され、リストに名前空間が表示されます。
One instance where translation might be necessary is where a device receives location configuration using DHCP [RFC4776]. Conversion of DHCP information to an XML form is necessary if the device wishes to use the DHCP-provided information in a range of applications, including location-based presence services [RFC4079] and emergency calling [RFC5012].
変換が必要になる可能性がある1つの例は、デバイスがDHCP [RFC4776]を使用して位置設定を受信する場合です。ロケーションベースのプレゼンスサービス[RFC4079]や緊急通話[RFC5012]など、さまざまなアプリケーションでDHCPが提供する情報を使用したい場合は、DHCP情報をXML形式に変換する必要があります。
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
Figure 1: Conversion Scenario
図1：変換シナリオ
The device that performs the translation between the DHCP and XML formats might not be aware of some of the extensions that are in use. Without knowledge of these extensions and how they are represented in XML, the device is forced to discard them.
DHCP形式とXML形式の間の変換を実行するデバイスは、使用されている一部の拡張機能を認識していない場合があります。これらの拡張機能とそれらがXMLでどのように表現されるかについての知識がなければ、デバイスはそれらを破棄する必要があります。
These extensions could be useful, or may be critical, to the ultimate consumers of this information. For instance, an extension element might provide a presence watcher with important information in locating the device, or an extension might be significant in choosing a particular call route.
これらの拡張機能は、この情報の最終的な消費者にとって有用であるか、または重要である可能性があります。たとえば、内線要素は、デバイスの位置を特定する上で重要な情報をプレゼンスウォッチャーに提供したり、特定の通話ルートを選択する際に重要な場合があります。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The civic schema in [RFC5139] defines an ordered structure of elements that can be combined to describe a civic address. The XML extension point at the end of this sequence is used to extend the address.
[RFC5139]の都市スキーマは、都市の住所を記述するために組み合わせることができる要素の順序付けられた構造を定義します。このシーケンスの最後にあるXML拡張ポイントは、アドレスを拡張するために使用されます。
New elements are defined in a new XML namespace [XMLNS]. This is true of address elements with significance within private or localized domains as well as those that are intended for global applicability.
新しい要素は、新しいXML名前空間[XMLNS]で定義されます。これは、プライベートまたはローカライズされたドメイン内で重要なアドレス要素だけでなく、グローバルな適用を目的とするアドレス要素にも当てはまります。
New elements SHOULD use the basic "caType" schema type defined in [RFC5139]. This type provides an optional "xml:lang" attribute.
新しい要素は、[RFC5139]で定義されている基本的な「caType」スキーマタイプを使用する必要があります（SHOULD）。このタイプは、オプションの「xml：lang」属性を提供します。
For example, suppose the (fictitious) Central Devon Canals Authority wishes to introduce a new civic element called "bridge". The authority defines an XML namespace that includes a "bridge" element. The namespace needs to be a unique URI, for example "http://devon.canals.example.com/civic".
たとえば、（架空の）Central Devon Canals Authorityが「bridge」と呼ばれる新しい市民要素を導入したいとします。機関は、「ブリッジ」要素を含むXML名前空間を定義します。名前空間は、「http://devon.canals.example.com/civic」などの一意のURIである必要があります。
A civic address that includes the new "bridge" element is shown in Figure 2.
新しい「ブリッジ」要素を含む市民の住所を図2に示します。
<civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cdc="http://devon.canals.example.com/civic">
<country>UK</country>
<A1>Devon</A1>
<A3>Monkokehampton</A3>
<RD>Deckport</RD>
<STS>Cross</STS>
<cdc:bridge>21451338</cdc:bridge>
</civicAddress>
Figure 2: Extended Civic Address Example
図2：拡張された市民の住所の例
An entity that receives this location information might not understand the extension address element. As long as the added element is able to be safely ignored, the remainder of the civic address can be used. The result is that the information is not as useful as it could be, but the added element does not prevent the use of the remainder of the address.
このロケーション情報を受信するエンティティは、拡張アドレス要素を理解していない可能性があります。追加された要素を安全に無視できる限り、市民の住所の残りの部分を使用できます。その結果、情報はそれほど有用ではありませんが、追加された要素はアドレスの残りの使用を妨げません。
The address can be passed to other applications, such as a LoST server [RFC5222], without modification. If the application understands the added element(s), it is able to make use of that information. For example, if this civic address is acquired using HTTP-Enabled Location Delivery (HELD) [RFC5985], it can be included in a LoST request directly.
アドレスは変更せずに、LoSTサーバー[RFC5222]などの他のアプリケーションに渡すことができます。アプリケーションが追加された要素を理解すると、その情報を利用することができます。たとえば、この市民アドレスがHTTP対応ロケーション配信（HELD）[RFC5985]を使用して取得された場合、LoSTリクエストに直接含めることができます。
Unsupported civic address elements can be carried without consequence as long as the format of the address does not change. However, conversion between formats has been shown to be necessary.
住所の形式が変更されない限り、サポートされていない市民住所要素を問題なく運ぶことができます。ただし、フォーマット間の変換が必要であることが示されています。
Format conversion requires knowledge of the format of the address elements. An entity performing a conversion between XML and DHCP address formats is forced to discard unrecognized elements. The entity performing the conversion has no way to know the correct element to use in the target format.
フォーマット変換には、住所要素のフォーマットに関する知識が必要です。 XMLとDHCPアドレス形式間の変換を実行するエンティティは、認識されない要素を破棄するように強制されます。変換を実行するエンティティは、ターゲット形式で使用する正しい要素を知る方法がありません。
This document defines a single extension element for the DHCP format that makes knowledge of extensions unnecessary during conversion. This extension element relies on the extension mechanisms defined for the XML format. New extensions to the civic address format MUST be defined only for the XML format; these extensions are then conveyed in DHCP using the extension element.
このドキュメントでは、変換中に拡張機能の知識を不要にするDHCP形式の単一の拡張要素を定義します。この拡張要素は、XML形式用に定義された拡張メカニズムに依存しています。市民住所形式の新しい拡張は、XML形式に対してのみ定義する必要があります。これらの拡張は、拡張要素を使用してDHCPで伝達されます。
Further extensions to the DHCP format are prohibited; these extensions cannot be safely conveyed in environments where conversion is possible.
DHCP形式へのそれ以上の拡張は禁止されています。これらの拡張機能は、変換が可能な環境では安全に伝達できません。
Extensions to the XML format [RFC5139] are defined in a new XML namespace [XMLNS]. The XML namespace received in DHCP is expressed as a URL, however, it should not be dereferenced or treated as a source location for the actual schema and doing so will serve no useful purpose.
XML形式[RFC5139]の拡張は、新しいXML名前空間[XMLNS]で定義されています。 DHCPで受信したXML名前空間はURLとして表現されますが、逆参照したり、実際のスキーマのソースの場所として処理したりしないでください。これを行うことは、有用な目的にはなりません。
Extensions in the XML format can be added to a DHCP format civic address using an extension CAtype.
XML形式の拡張は、拡張CAtypeを使用してDHCP形式の市民アドレスに追加できます。
The extension CAtype (CAtype code 40) includes three values that uniquely identify the XML extension and its value: a namespace URI, the local name of the XML element, and the text content of that element. These three values are all included in the value of the CAtype, each separated by a single whitespace character.
拡張CAtype（CAtypeコード40）には、XML拡張とその値を一意に識別する3つの値が含まれています。名前空間URI、XML要素のローカル名、およびその要素のテキストコンテンツです。これら3つの値はすべてCAtypeの値に含まれ、それぞれが1つの空白文字で区切られています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAtype (40) | Length | Namespace URI ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Namespace URI (continued) .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | XML element local name .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | Extension type value .
+---------------+ .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: XML Civic Address Extension CAtype
図3：XML Civicアドレス拡張CAtype
CAtype (40) identifies the extension CAtype.
CAtype（40）は拡張CAtypeを識別します。
Length is the number of octets used to represent the namespace URI, local name, and value. The length includes the space between the namespace URI and local name and the space between the local name and value fields.
長さは、名前空間URI、ローカル名、および値を表すために使用されるオクテットの数です。長さには、名前空間URIとローカル名の間のスペース、およびローカル名と値フィールドの間のスペースが含まれます。
The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. Octets consumed by the namespace URI and local name reduce the space available for values.
CAtypeのコンテンツ（CAtypeコードと長さの後）は、UTF-8でエンコードされたUnicodeテキスト[RFC3629]です。最大255オクテットが許可されます。名前空間URIとローカル名によって消費されるオクテットは、値に使用できるスペースを減らします。
This conversion only works for elements that have textual content and an optional "xml:lang" attribute. Elements with complex content or other attributes -- aside from namespace bindings -- MUST be ignored if they are not understood.
この変換は、テキストコンテンツとオプションの「xml：lang」属性を持つ要素に対してのみ機能します。複雑なコンテンツまたは他の属性を持つ要素（名前空間バインディングを除く）は、理解されない場合は無視する必要があります。
The registration of a new CAtype following the process in [RFC4776] means that a recipient that does not know the equivalent XML is unable to produce a complete XML representation of the DHCP civic address. For this reason, this document ends the registration of new numeric CAtypes. No new registrations of numeric CAtypes can be made.
[RFC4776]のプロセスに従って新しいCAtypeを登録すると、同等のXMLを知らない受信者は、DHCPの市民アドレスの完全なXML表現を生成できません。このため、このドキュメントでは、新しい数値CAtypeの登録を終了します。数値CAtypeの新規登録はできません。
In lieu of making new numerical CAtype assignments, this document creates a new extensionCA type that is defined in a manner that lets new civic elements be described in DHCP form by carrying the namespace and type name of the extension in parameters of the extensionCA type.
新しい数値CAタイプの割り当てを作成する代わりに、このドキュメントは、extensionCAタイプのパラメーターで拡張の名前空間とタイプ名を運ぶことにより、新しい市民要素をDHCP形式で記述できるように定義された新しいextensionCAタイプを作成します。
When converting to XML, the namespace prefix used for the extension element is selected by the entity that performs the conversion.
XMLに変換する場合、拡張要素に使用される名前空間プレフィックスは、変換を実行するエンティティによって選択されます。
The following example civic address contains two extensions:
次の例の市民住所には2つの拡張子が含まれています。
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.example.com/ns"
xmlns:ap="http://example.com/airport/5.0">
<country>US</country>
<A1>CA</A1>
<post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
Figure 4: XML Example with Multiple Extensions
図4：複数の拡張子を持つXMLの例
This is converted to a DHCP form as follows:
これは、次のようにDHCPフォームに変換されます。
country = US
CAtype[0] = en-US
CAtype[1] = CA
CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471
CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
CAtype[40] = http://example.com/airport/5.0 airport LAX
CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley
CAtype[40] = http://example.com/airport/5.0 concourse G
CAtype[40] = http://example.com/airport/5.0 gate 36B
Figure 5: Converted DHCP Example with Multiple Extensions
図5：複数の拡張機能を持つ変換されたDHCPの例
[RFC4776] created the CAtype registry. Among other things, this registry advertised available civic elements. While it has always been possible to use an extension namespace to define civic elements that are not in the CAtype registry, and this document does not change that, the registry is valuable to alert implementors of commonly used civic elements and provides guidance to clients of what elements they should support.
[RFC4776]はCAtypeレジストリを作成しました。とりわけ、このレジストリは利用可能な市民的要素を宣伝しました。拡張ネームスペースを使用してCAtypeレジストリにない市民要素を定義することは常に可能であり、このドキュメントはそれを変更しませんが、レジストリは、一般的に使用される市民要素の実装者に警告するのに役立ち、クライアントにガイダンスを提供します彼らがサポートすべき要素。
This document alters the CAtype registry in several ways. It closes the registry to new numeric CAtypes. It deletes the "NENA" column, which is not needed. It adds columns for a namespace and contact, and changes the name of the column currently called "PIDF" to "Local Name". It also adds a column to the registry called "Type". "Type" can have one of two values "A" and "B". Type A elements are intended for wide use with many applications and SHOULD be implemented by all clients unless the client is certain the element will not be encountered. Type B civic elements MAY be implemented by any client.
このドキュメントは、いくつかの方法でCAtypeレジストリを変更します。レジストリを新しい数値CAtypeに閉じます。不要な「NENA」列を削除します。名前空間と連絡先の列を追加し、現在「PIDF」と呼ばれている列の名前を「ローカル名」に変更します。また、「Type」というレジストリに列を追加します。 「タイプ」には、「A」と「B」の2つの値のいずれかを指定できます。タイプA要素は、多くのアプリケーションで広く使用することを目的としており、クライアントが要素に遭遇しないことが確実でない限り、すべてのクライアントによって実装されるべきです（SHOULD）。タイプBの市民要素は、どのクライアントでも実装できます（MAY）。
Type A civic elements require IETF review, while Type B elements only require an expert review.
タイプAの要素にはIETFのレビューが必要ですが、タイプBの要素には専門家のレビューのみが必要です。
We use this new extension method to define some additional civic address elements that are needed to correctly encode civic locations in several countries. The definition of these new civic address elements also serves as an example of how to define additional elements using the mechanisms described in this document.
この新しい拡張方法を使用して、いくつかの国の都市の場所を正しくエンコードするために必要な追加の都市の住所要素を定義します。これらの新しい市民住所要素の定義は、このドキュメントで説明されているメカニズムを使用して追加の要素を定義する方法の例としても役立ちます。
In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the label on the lamp post also carries the local emergency service number, such as "110", encouraging callers to use the pole number to identify their location.
一部の地域では、ユーティリティとランプの支柱に一意の識別子が付いています。このドキュメントでは、これを極番号と呼びます。一部の国では、街灯のラベルに「110」などの地域の緊急サービス番号も記載されているため、発信者は極番号を使用して場所を特定することができます。
_.-----,===.
| | (''''')
| | `---'
| |
| | ,---------,
| | ,---, |Emergency|
| | /|,-.|----->| Number |
| | / |110| '---------'
| | / |`-'|
|_|/ | 2 | ,---------,
| | | 1 | |Lamp Post|
| | | 2 |----->| Number |
|-| | 1 | '---------'
| |\ | 0 |
| | \ | 1 |
| | \ | 4 |
| | \|,,,|
_ | |
``-..|.|
``--.._
`'--.._
Figure 6: Lamp Post with Emergency Number
図6：緊急番号のあるランプポスト
On some roads, trails, railroad rights of way, and other linear features, a post with a mile or kilometer distance from one end of the feature may be found (a "milepost"). There are other cases of poles or markers with numeric indications that are not the same as a "house number" or street address number.
一部の道路、歩道、鉄道の通行権、およびその他の線形フィーチャでは、フィーチャの一端から1マイルまたは1キロの距離にある投稿（「マイルポスト」）が見つかることがあります。 「家番号」または番地番号と同じではない数値表示のポールまたはマーカーの他のケースがあります。
The civic schema defined in [RFC5139] allows the definition of address "123 Colorado Boulevard", but it does not allow for the easy expression of "123 Boulevard Colorado". Adding a street type prefix, allows a street named in this manner to be more easily represented.
[RFC5139]で定義されている市民のスキーマでは、アドレス「123コロラドブールバード」を定義できますが、「123ブールバードコロラド」を簡単に表現することはできません。ストリートタイプのプレフィックスを追加すると、この方法で名前が付けられたストリートをより簡単に表すことができます。
The civic schema defined in [RFC5139] provides a house number suffix element, allowing one to express an address like "123A Main Street", but it does not contain a corresponding house number prefix. The house number prefix element allows the expression of address such as "Z123 Main Street".
[RFC5139]で定義されている市民スキーマは、家番号の接尾辞要素を提供し、「123A Main Street」のような住所を表現できるようにしますが、対応する家番号の接頭辞は含まれません。家番号プレフィックス要素は、「Z123 Main Street」などの住所の表現を可能にします。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
<!-- Post Number -->
<xs:element name="PN" type="ca:caType"/>
<!-- Milepost -->
<xs:element name="MP" type="ca:caType"/>
<!-- Street Type Prefix -->
<xs:element name="STP" type="ca:caType"/>
<!-- House Number Prefix -->
<xs:element name="HNP" type="ca:caType"/>
</xs:schema>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>I5</RD>
<cae:MP>248</cae:MP>
<cae:PN>22-109-689</cae:PN>
</civicAddress>
Figure 7: XML Example with Post Number and Milepost
図7：投稿番号とマイルポストを含むXMLの例
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country>
<A1>CA</A1>
<A2>Sacramento</A2>
<RD>Colorado</RD>
<HNO>223</HNO>
<cae:STP>Boulevard</cae:STP>
<cae:HNP>A</cae:HNP>
</civicAddress>
Figure 8: XML Example with Street Type Prefix and House Number Prefix
図8：ストリートタイププレフィックスと家番号プレフィックスを含むXMLの例
One critical use of civic location information is in next generation emergency services applications, in particular, call routing applications. In such cases, location information is provided to a location-based routing service using the LoST protocol [RFC5222]. LoST is used to provide call routing information, but it is also used to validate location information to ensure that it can route to an emergency center when required.
都市の位置情報の重要な用途の1つは、次世代の緊急サービスアプリケーション、特にコールルーティングアプリケーションです。このような場合、位置情報は、LoSTプロトコル[RFC5222]を使用して位置ベースのルーティングサービスに提供されます。 LoSTは、コールルーティング情報を提供するために使用されますが、ロケーション情報を検証して、必要なときに緊急センターにルーティングできることを確認するためにも使用されます。
LoST is an XML-based protocol, and so the namespace extension mechanisms described in this document do not impact LoST. When LoST is used for validation, a <locationValidation> element is returned containing a list of valid, a list of invalid, and a list of unchecked civic elements. Figure 9 is an extract of the validation response in Figure 6 from [RFC5222].
LoSTはXMLベースのプロトコルであるため、このドキュメントで説明する名前空間拡張メカニズムはLoSTに影響を与えません。検証にLoSTを使用すると、有効なリスト、無効なリスト、およびチェックされていないシビックエレメントのリストを含む<locationValidation>エレメントが返されます。図9は、[RFC5222]からの図6の検証応答の抜粋です。
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
Figure 9: Location Validation Example from LoST (RFC5222)
図9：LoSTからのロケーション検証の例（RFC5222）
The RelaxNG schema in [RFC5222] requires the elements in each of these lists to be namespace qualified, which makes the example in Figure 6 of [RFC5222] erroneous. This issue is especially significant when local-civic extensions are used as the domain to which the extensions are attributed may impact their interpretation by the server or client. To ensure that local-civic extensions do not cause issues with the LoST server and client implementations, all elements listed in a <valid>, <invalid>, or <unchecked> element MUST be qualified with a namespace. To illustrate this, the extract above from Figure 6 in [RFC5222] becomes Figure 10.
[RFC5222]のRelaxNGスキーマでは、これらの各リストの要素を名前空間で修飾する必要があるため、[RFC5222]の図6の例は誤りです。この問題は、ローカルシビック拡張がサーバーまたはクライアントによる解釈に影響を与える可能性があるドメインとして使用されている場合に特に重要です。ローカルシビック拡張がLoSTサーバーとクライアントの実装で問題を引き起こさないようにするには、<valid>、<invalid>、または<unchecked>要素にリストされているすべての要素を名前空間で修飾する必要があります。これを説明するために、[RFC5222]の図6の上記の抜粋は、図10になります。
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<valid>ca:country ca:A1 ca:A3 ca:A6</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO</unchecked>
</locationValidation>
Figure 10: Corrected Location Validation Example
図10：修正された位置検証の例
If a validation request has also included the extensions defined in Section 5, then the validation response would look like Figure 11.
検証リクエストにセクション5で定義された拡張機能も含まれている場合、検証レスポンスは図11のようになります。
<locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>
<invalid>ca:PC</invalid>
<unchecked>ca:HNO cae:MP cae:HNP</unchecked>
</locationValidation>
Figure 11: Corrected Location Validation Example
図11：修正された位置検証の例
This document defines a formal way to extend the existing Geopriv civic address schema. While no security threats are directly introduced by this document, creators of new civic address extensions should refer to Sections 4.3.1 and 5.1 of [RFC3694] to understand the environments in which these new elements will be used. New elements should only be registered if the person or organization performing the registration understands any associated risks.
このドキュメントは、既存のGeoprivの市民住所スキーマを拡張する正式な方法を定義しています。このドキュメントによってセキュリティの脅威が直接紹介されることはありませんが、新しい市民アドレス拡張の作成者は、[RFC3694]のセクション4.3.1および5.1を参照して、これらの新しい要素が使用される環境を理解する必要があります。新しい要素は、登録を行う人物または組織が関連するリスクを理解している場合にのみ登録する必要があります。
Security threats applicable to the civic address formats are described in [RFC4776] DHCP and [RFC5139] XML.
市民のアドレス形式に該当するセキュリティの脅威は、[RFC4776] DHCPおよび[RFC5139] XMLで説明されています。
This document alters the "CAtypes" registry in the Civic Address Types Registry established by [RFC4776].
このドキュメントは、[RFC4776]によって確立されたCivic Address Types Registryの「CAtypes」レジストリを変更します。
IANA has allocated a CAtype code of 40 for the extension CAtype. Registrations using this code will be made below, in Section 8.4.
IANAは拡張CAtypeに40のCAtypeコードを割り当てました。このコードを使用した登録は、以下のセクション8.4で行います。
IANA has made the following changes to the CAtype registry:
IANAはCAtypeレジストリに次の変更を加えました。
o No registrations of new CAtype numbers in the Civic Address Types Registry are permitted, except by IESG Approval [RFC5226] under unusual circumstances.
o 異常な状況下でのIESG承認[RFC5226]による場合を除き、Civic Address Types Registryに新しいCAtype番号を登録することはできません。
o The following note has been placed in the header of the CAtypes registry, above the table:
o 次のメモは、表の上にあるCAtypesレジストリのヘッダーに配置されています。
Note: As specified in RFC 6848, new registrations are only accepted for CAtype 40, using the template specified in Section 8.3.
注：RFC 6848で指定されているように、新しい登録は、セクション8.3で指定されたテンプレートを使用するCAtype 40に対してのみ受け入れられます。
o The registration procedures are changed: IETF Review (if Type=A), Expert Review (if Type=B). The designated expert is unchanged.
o 登録手順が変更されました：IETFレビュー（Type = Aの場合）、エキスパートレビュー（Type = Bの場合）。指定されたエキスパートは変更されていません。
o The reference for the table is changed: [RFC4776], RFC 6848
o テーブルの参照が変更されました：[RFC4776]、RFC 6848
o The column called "NENA" is removed.
o 「ネナ」というコラムを削除。
o The column called "PIDF" is renamed to "Local Name".
o 「PIDF」という列の名前が「ローカル名」に変更されます。
o New columns are added named "Namespace URI", "Contact", "Schema" and "Type". All existing entries will have the following values for those new columns:
o 「名前空間URI」、「連絡先」、「スキーマ」、「タイプ」という名前の新しい列が追加されます。既存のすべてのエントリには、これらの新しい列について次の値が含まれます。
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Type: A
タイプ：A
New registrations in the Civic Address Types Registry require the following information:
Civic Address Types Registryに新規登録するには、次の情報が必要です。
CAtype: The assigned numeric CAtype. All new registrations will use the value 40.
CAtype：割り当てられた数値CAtype。すべての新規登録は値40を使用します。
Namespace URI: A unique identifier for the XML namespace used for the extension element.
名前空間URI：拡張要素に使用されるXML名前空間の一意の識別子。
Local Name: The local name of an XML element that carries the civic address element.
ローカル名：市民の住所要素を含むXML要素のローカル名。
Description: A brief description of the semantics of the civic address element.
説明：市民住所要素のセマンティクスの簡単な説明。
Example (optional): One or more simple examples of the element.
例（オプション）：要素の1つ以上の単純な例。
Contact: Contact details for the person providing the extension.
連絡先：拡張機能を提供する人の連絡先の詳細。
Specification (optional): A reference to a specification for the civic address element.
仕様（オプション）：市民住所要素の仕様への参照。
Schema (optional): A reference to a formal schema (XML schema, RelaxNG, or other form) that defines the extension.
スキーマ（オプション）：拡張を定義する正式なスキーマ（XMLスキーマ、RelaxNG、またはその他のフォーム）への参照。
Type: "A" or "B". If Type is "A", all clients SHOULD implement this element. If Type is "B", clients MAY implement this element.
タイプ：「A」または「B」。 Typeが "A"の場合、すべてのクライアントがこの要素を実装する必要があります（SHOULD）。 Typeが "B"の場合、クライアントはこの要素を実装できます（MAY）。
This section registers the following four new CAtypes in the Civic Address Types Registry.
このセクションでは、次の4つの新しいCAtypeをCivic Address Typesレジストリに登録します。
Post Number (see Section 5.1):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: PN
Description: Post number that is attributed to a lamp post or
utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Milepost (see Section 5.2):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP
Description: Milepost: a marker indicating distance to or from a
place (often a town).
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Street Type Prefix (see Section 5.3):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP
Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
House Number Prefix (see Section 5.4):
CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP
Description: House Number Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
The "CAtypes" registry is altered to operate on a registration policy of "Expert Review", and optionally "Specification Required" [RFC5226] if the element being registered has a Type value of "B".
「CAtypes」レジストリは、「エキスパートレビュー」の登録ポリシーで動作するように変更され、登録されている要素のタイプ値が「B」の場合はオプションで「指定が必要」[RFC5226]になります。
The registration rules for "Specification Required" are followed only if a registration includes a reference to a specification. Registrations can be made without a specification reference.
"Specification Required"の登録ルールは、登録に仕様への参照が含まれている場合にのみ従います。登録は仕様参照なしで行うことができます。
If the element being registered has a Type value of "A", then the registration policy is "IETF Review" [RFC5226].
登録されている要素のタイプ値が「A」の場合、登録ポリシーは「IETFレビュー」[RFC5226]です。
All registrations are reviewed to identify potential duplication between registered elements. Duplicated semantics are not prohibited in the registry, though it is preferred if existing elements are used. The expert review is advised to recommend the use of existing elements following the guidance in [RFC5774]. Any registration that is a duplicate or could be considered a close match for the semantics of an existing element SHOULD include a discussion of the reasons that the existing element was not reused.
すべての登録は、登録された要素間の潜在的な重複を識別するために見直されます。重複したセマンティクスはレジストリで禁止されていませんが、既存の要素が使用されている場合は推奨されます。専門家によるレビューは、[RFC5774]のガイダンスに従って既存の要素の使用を推奨することをお勧めします。重複する登録、または既存の要素のセマンティクスに近いと見なされる可能性のある登録には、既存の要素が再利用されなかった理由の説明を含める必要があります（SHOULD）。
[RFC6280] provides a comprehensive framework concerning the privacy of location information as pertaining to its use in Internet applications. The expert reviewer is asked to keep the spirit of this document in mind when reviewing new CAtype registrations.
[RFC6280]は、インターネットアプリケーションでの使用に関する位置情報のプライバシーに関する包括的なフレームワークを提供します。エキスパートレビューアは、新しいCAtype登録をレビューするときに、このドキュメントの趣旨に留意するよう求められます。
IANA has registered a new XML namespace, as per the guidelines in [RFC3688].
[RFC3688]のガイドラインに従って、IANAは新しいXML名前空間を登録しました。
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com)
登録者の連絡先：IETF GEOPRIVワーキンググループ（geopriv@ietf.org）、James Winterbottom（james.Winterbottom@commscope.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 Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt">
RFC 6848</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:ext
Registrant Contact: IETF GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com)
登録者の連絡先：IETF GEOPRIVワーキンググループ（geopriv@ietf.org）、James Winterbottom（james.Winterbottom@commscope.com）
XML: The XML for this schema can be found as the entirety of Section 5.5 of this document.
XML：このスキーマのXMLは、このドキュメントのセクション5.5全体として見つかります。
Thanks to anyone who has tried to extend the civic schema and found it a little less than intuitive.
市民のスキーマを拡張しようとして、直感的ではないことに気付いた方に感謝します。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3694] Danley、M.、Mulligan、D.、Morris、J。、およびJ. Peterson、「Threat Analysis of the Geopriv Protocol」、RFC 3694、2004年2月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Divamic Host Configuration Protocol（DHCPv4 and DHCPv6）Option for Civic Addresses Configuration Information」、RFC 4776、2006年11月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson、M。、およびJ. Winterbottom、「Presence Information Data Format Location Object（PIDF-LO）の改訂されたCivic Location Format」、RFC 5139、2008年2月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「LoST：A Location-to-Service Translation Protocol」、RFC 5222、2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, "Namespaces in XML 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[XMLNS] Hollander、D.、Layman、A.、Tobin、R。、およびT. Bray、「Namespaces in XML 1.1（Second Edition）」、World Wide Web Consortium Recommendation REC-xml-names11-20060816、2006年8月、 <http://www.w3.org/TR/2006/REC-xml-names11-20060816>。
[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
[RFC4079] Peterson、J。、「GEOPRIVロケーションオブジェクトの配布のためのプレゼンスアーキテクチャ」、RFC 4079、2005年7月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition", BCP 154, RFC 5774, March 2010.
[RFC5774]ウルフ、K。およびA.マイヤーホーファー、「プレゼンス情報データ形式のロケーションオブジェクト（PIDF-LO）における市民のアドレスに関する考慮事項：ガイドラインとIANAレジストリ定義」、BCP 154、RFC 5774、2010年3月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
Authors' Addresses
著者のアドレス
James Winterbottom CommScope Suit 1, Level 2 iC Enterprise 1, Innovation Campus Squires Way North Wollongong, NSW 2500 AU
James Winterbottomコムスコープスーツ1、レベル2 iCエンタープライズ1、イノベーションキャンパススクワイアズウェイノースウロンゴン、NSW 2500 AU
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Martin Thomson Skype 3210 Porter Drive Palo Alto, CA 94304 US
Martin Thomson Skype 3210 Porter Drive Palo Alto、CA 94304 US
EMail: martin.thomson@gmail.com
Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US
リチャードバーンズBBN Technologies 9861 Broken Land Parkway Columbia、MD 21046 US
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US
Brian Rosen NeuStar、Inc. 470 Conrad Dr Mars、PA 16046 US
EMail: br@brianrosen.net Robins George Huawei Technologies Huawei Base, Bantian, Longgan District Shenzhen, Guangdong 518129 P. R. China
メール：たとえば、@ブライアンローズN.netロビンは、ジョージhu Aはテクノロジー、hu Aはベース、禁止日、長い地区は非常に現実的であると述べました。GUケースGビル518129 P. R.中国
Phone: +86 755 2878 8314
EMail: robinsgv@gmail.com