RFC5139 日本語訳
5139 Revised Civic Location Format for Presence Information DataFormat Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2008. (Format: TXT=27470 bytes) (Updates RFC4119) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Thomson Request for Comments: 5139 J. Winterbottom Updates: 4119 Andrew Category: Standards Track February 2008
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)
Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
Status of This Memo
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.
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.
Abstract
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.
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.
Thomson & Winterbottom Standards Track [Page 1] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 1] RFC 5139 Revised Civic LO February 2008
Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
Thomson & Winterbottom Standards Track [Page 2] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 2] RFC 5139 Revised Civic LO February 2008
1. Introduction
1. Introduction
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].
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].
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.
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.
2. Terminology
2. Terminology
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].
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].
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].
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].
3. Changes from PIDF-LO
3. Changes from PIDF-LO
3.1. Additional Civic Address Types
3.1. Additional Civic Address Types
[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] 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].
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.
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.
Thomson & Winterbottom Standards Track [Page 3] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 3] RFC 5139 Revised Civic LO February 2008
+-----------+--------+-------------------------------+--------------+ | 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 | +-----------+--------+-------------------------------+--------------+
+-----------+--------+-------------------------------+--------------+ | 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
Table 1: New Civic PIDF-LO Types
A complete description of these types is included in [RFC4776].
A complete description of these types is included in [RFC4776].
3.2. New Thoroughfare Elements
3.2. New Thoroughfare Elements
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.
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.
Thomson & Winterbottom Standards Track [Page 4] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 4] RFC 5139 Revised Civic LO February 2008
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.
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.
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.
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.
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.
The following figure shows a fictional arrangement of roads where these new thoroughfare elements are applicable.
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. ||
| ||
| || | ---------------|| | 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. Street Numbering
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".
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".
3.2.2. Directionals and Other Qualifiers
3.2.2. Directionals and Other Qualifiers
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.
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.
Thomson & Winterbottom Standards Track [Page 5] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 5] RFC 5139 Revised Civic LO February 2008
3.3. Country Element
3.3. Country Element
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].
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].
3.4. A1 Element
3.4. A1 Element
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.
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.
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:
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:
<country>CA</country><A1>ON</A1>
<country>CA</country><A1>ON</A1>
<country>LU</country><A1>L</A1>
<country>LU</country><A1>L</A1>
<country>AU</country><A1>ACT</A1>
<country>AU</country><A1>ACT</A1>
<country>FR</country><A1>75</A1>
<country>FR</country><A1>75</A1>
3.5. Languages and Scripts
3.5. Languages and Scripts
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].
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].
The "script" field defined in [RFC4776] is omitted in favor of using the "xml:lang" attribute with a script subtag [RFC4646].
The "script" field defined in [RFC4776] is omitted in favor of using the "xml:lang" attribute with a script subtag [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.
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.
Thomson & Winterbottom Standards Track [Page 6] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 6] RFC 5139 Revised Civic LO February 2008
For civic addresses that form a complex to describe the same location, these SHOULD be inserted into the same tuple.
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. Converting from the DHCP Format
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.
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.
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.
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.
3.5.2. Combining Multiple Elements Based on Language Preferences
3.5.2. Combining Multiple Elements Based on Language Preferences
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.
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.
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.
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. Whitespace
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].
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].
Thomson & Winterbottom Standards Track [Page 7] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 7] RFC 5139 Revised Civic LO February 2008
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:
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:
<A4>North Wollongong</A4>
<A4>North Wollongong</A4>
<A1>North
Wollongong</A1>
<A1>North Wollongong</A1>
<A1>
North Wollongong
</A1>
<A1> North Wollongong </A1>
Whitespace may still be included in values by using character references, such as " ".
Whitespace may still be included in values by using character references, such as " ".
4. Civic Address Schema
4. Civic Address Schema
<?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">
<?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: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: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:complexType name="caType"> <xs:simpleContent> <xs:extension base="xs:token"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType>
Thomson & Winterbottom Standards Track [Page 8] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 8] RFC 5139 Revised Civic LO February 2008
<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: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>
Thomson & Winterbottom Standards Track [Page 9] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 9] RFC 5139 Revised Civic LO February 2008
5. Example
5. Example
<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="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>
6. Security Considerations
6. Security Considerations
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.
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.
7. IANA Considerations
7. IANA Considerations
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
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.
This document defines a new XML namespace (as per the guidelines in [RFC3688]) that has been registered with IANA.
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
Thomson & Winterbottom Standards Track [Page 10] RFC 5139 Revised Civic LO February 2008
Thomson & Winterbottom Standards Track [Page 10] RFC 5139 Revised Civic LO February 2008
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
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 Registration
This section registers an XML schema as per the procedures in [RFC3688].
This section registers an XML schema as per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Registrant Contact: IETF, GEOPRIV working group (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.
The XML for this schema can be found as the entirety of Section 4 of this document.
7.3. CAtype Registry Update
7.3. CAtype Registry Update
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.
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.
Thomson & Winterbottom Standards Track [Page 11] RFC 5139 Revised Civic LO February 2008
都市の最低気温2008年2月に改訂されたトムソンとWinterbottom標準化過程[11ページ]RFC5139
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.Malhotra、「XML図式第2部:」 「データ型式第2版」、ワールドワイドウェブコンソーシアム推薦REC-xmlschema-2-20041028、<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028 2004年10月の>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4119] ピーターソン、J.、「存在ベースのGEOPRIV位置の物の形式」、RFC4119、2005年12月。
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", RFC 4589, July 2006.
[RFC4589] SchulzrinneとH.とH.Tschofenig、「位置は登録をタイプする」RFC4589、2006年7月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]フィリップス、A.とM.デイヴィス、「言語を特定するためのタグ」BCP47、2006年9月のRFC4646。
[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)オプション」、RFC4776、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部:、」 1997、「国名略号」、ISO Standard3166- 1: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部:、」 1998、「国の下位区分コード」、ISO Standard3166-2:1998。
8.2. Informative References
8.2. 有益な参照
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[UPU-S42] Universal Postal Union (UPU), "International Postal
Address Components and Templates", UPS SB42-4,
July 2004.
[UPU-S42]万国郵便連合(UPU)「国際郵便の宛先コンポーネントとテンプレート」というはSB42-4、2004年7月を上げます。
Thomson & Winterbottom Standards Track [Page 12] RFC 5139 Revised Civic LO February 2008
都市の最低気温2008年2月に改訂されたトムソンとWinterbottom標準化過程[12ページ]RFC5139
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がタイプするのをヘニングに感謝したがっています、特に往来要素の挿入につながった異なったアドレシング計画の彼の研究。 RohanマーイはA1のためにISO3166-2推薦を勧めました。 さらに、彼の仕事についてPIDF-LOを定義する際にジョン・ピーターソンに感謝申し上げます。
Authors' Addresses
作者のアドレス
Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
マーチントムソンアンドリュー私書箱U40ウォロンゴンの大学構内、NSW2500Au
Phone: +61 2 4221 2915 EMail: martin.thomson@andrew.com URI: http://www.andrew.com/
以下に電話をしてください。 +61 2 4221 2915はメールされます: martin.thomson@andrew.com ユリ: http://www.andrew.com/
James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU
ジェームスWinterbottomアンドリュー私書箱U40ウォロンゴンの大学構内、NSW2500Au
Phone: +61 2 4221 2938 EMail: james.winterbottom@andrew.com URI: http://www.andrew.com/
以下に電話をしてください。 +61 2 4221 2938はメールされます: james.winterbottom@andrew.com ユリ: http://www.andrew.com/
Thomson & Winterbottom Standards Track [Page 13] RFC 5139 Revised Civic LO February 2008
都市の最低気温2008年2月に改訂されたトムソンとWinterbottom標準化過程[13ページ]RFC5139
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Thomson & Winterbottom Standards Track [Page 14]
トムソンとWinterbottom標準化過程[14ページ]
一覧
スポンサーリンク
