GEOPRIV WG M. Thomson
Internet-Draft J. Winterbottom
Expires: March 19, 2007 Andrew
September 15, 2006
Revised Civic Location Format for PIDF-LO
draft-ietf-geopriv-revised-civic-lo-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines an XML format for the representation of civic
location. This format is designed for use with PIDF Location Object
(PIDF-LO) documents. The format is based on the civic address
definition in PIDF-LO, but adds several new elements based on the
civic types defined for 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 Expires March 19, 2007 [Page 1]
Internet-Draft Revised Civic LO September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5
3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5
3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7
3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8
3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8
3.5.2. Combining Multiple Elements Based on Language
Preferences . . . . . . . . . . . . . . . . . . . . . 8
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Thomson & Winterbottom Expires March 19, 2007 [Page 2]
Internet-Draft Revised Civic LO September 2006
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 [I-D.ietf-geopriv-dhcp-civil].
This document revises the GEOPRIV civic form to include the
additional civic parameters captured in [I-D.ietf-geopriv-dhcp-
civil]. 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.
Thomson & Winterbottom Expires March 19, 2007 [Page 3]
Internet-Draft Revised Civic LO September 2006
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 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].
Thomson & Winterbottom Expires March 19, 2007 [Page 4]
Internet-Draft Revised Civic LO September 2006
3. Changes from PIDF-LO
3.1. Additional Civic Address Types
[I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that
may be used to describe a civic location. Specifically [I-D.ietf-
geopriv-dhcp-civil] lists several civic address types (CAtypes) that
require support in the formal PIDF-LO definition that are not in
[RFC4119].
These changes include and new elements that are required to support
more complex structures for naming street addresses, this is
described in more detail in Section 3.2.
+--------------+--------+-----------------------------+-------------+
| New Civic | CAtype | Description | Example |
| Field | | | |
+--------------+--------+-----------------------------+-------------+
| BLD | 25 | Building (structure) | Hope |
| | | | Theatre |
| | | | |
| UNIT | 26 | Unit (apartment, suite) | 12a |
| | | | |
| ROOM | 28 | Room | 450F |
| | | | |
| PLC | 29 | Place-type | office |
| | | | |
| 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
Thomson & Winterbottom Expires March 19, 2007 [Page 5]
Internet-Draft Revised Civic LO September 2006
A complete description of these types is included in [I-D.ietf-
geopriv-dhcp-civil].
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" 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.
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 interested 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.
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. However, without additional information
these fields MUST not be interchanged when converting between
different civic formats. Where civic address information is obtained
from another format, such as the DHCP form [I-D.ietf-geopriv-dhcp-
civil], the "A6" element MUST be copied directly from the source
format.
The following example 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. ||
Thomson & Winterbottom Expires March 19, 2007 [Page 6]
Internet-Draft Revised Civic LO September 2006
| ||
3.2.1. Street Numbering
The introduction of new thoroughfare elements affects the
interpretation of several 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
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.
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 upper case
characters, which correspond to the alpha-2 codes in [ISO.3166-1].
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 a 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; 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>LU</country><A1>L</A1>
<country>AU</country><A1>ACT</A1>
Thomson & Winterbottom Expires March 19, 2007 [Page 7]
Internet-Draft Revised Civic LO September 2006
<country>FR</country><A1>75</A1>
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 enumerated values.
The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is
omitted in favour of using the "xml:lang" attribute.
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.
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
The DHCP format for civic addresses [I-D.ietf-geopriv-dhcp-civil]
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 is 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.
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.
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
Thomson & Winterbottom Expires March 19, 2007 [Page 8]
Internet-Draft Revised Civic LO September 2006
available languages, or if there a conflicting values with the same
language.
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 "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>
<A1>North
Wollongong</A1>
<A1>
North Wollongong
</A1>
Whitespace may still be included in values by using character
references, such as " ".
Thomson & Winterbottom Expires March 19, 2007 [Page 9]
Internet-Draft Revised Civic LO September 2006
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">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="iso3166a2">
<xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="caType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="civicAddress" type="ca:civicAddress"/>
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="ca:iso3166a2" minOccurs="0"/>
<xs:element name="A1" type="ca:caType" minOccurs="0"/>
<xs:element name="A2" type="ca:caType" minOccurs="0"/>
<xs:element name="A3" type="ca:caType" minOccurs="0"/>
<xs:element name="A4" type="ca:caType" minOccurs="0"/>
<xs:element name="A5" type="ca:caType" minOccurs="0"/>
<xs:element name="A6" type="ca:caType" minOccurs="0"/>
<xs:element name="PRM" type="ca:caType" minOccurs="0"/>
<xs:element name="PRD" type="ca:caType" minOccurs="0"/>
<xs:element name="RD" type="ca:caType" minOccurs="0"/>
<xs:element name="STS" type="ca:caType" minOccurs="0"/>
<xs:element name="POD" type="ca:caType" minOccurs="0"/>
<xs:element name="POM" type="ca:caType" minOccurs="0"/>
<xs:element name="RDSEC" type="ca:caType" minOccurs="0"/>
<xs:element name="RDBR" type="ca:caType" minOccurs="0"/>
<xs:element name="RDSUBBR" type="ca:caType" minOccurs="0"/>
<xs:element name="HNO" type="ca:caType" minOccurs="0"/>
<xs:element name="HNS" type="ca:caType" minOccurs="0"/>
Thomson & Winterbottom Expires March 19, 2007 [Page 10]
Internet-Draft Revised Civic LO September 2006
<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="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:attribute ref="xml:lang" use="optional"/>
</xs:complexType>
</xs:schema>
Thomson & Winterbottom Expires March 19, 2007 [Page 11]
Internet-Draft Revised Civic LO September 2006
5. Example
<?xml version="1.0"?>
<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>
Thomson & Winterbottom Expires March 19, 2007 [Page 12]
Internet-Draft Revised Civic LO September 2006
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.
Thomson & Winterbottom Expires March 19, 2007 [Page 13]
Internet-Draft Revised Civic LO September 2006
7. IANA Considerations
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
This document calls for IANA to register a new XML namespace, as per
the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
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>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
7.2. XML Schema Registration
This section registers an XML schema as per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
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.
Thomson & Winterbottom Expires March 19, 2007 [Page 14]
Internet-Draft Revised Civic LO September 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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>.
[I-D.ietf-geopriv-dhcp-civil]
Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information",
draft-ietf-geopriv-dhcp-civil-09 (work in progress),
January 2006.
[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,
<http://www.iso.org/iso/en/prods-services/iso3166ma/>.
[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,
<http://www.iso.org/iso/en/prods-services/iso3166ma/>.
8.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[UPU-S42] Universal Postal Union (UPU), "International Postal
Address Components and Templates", UPS SB42-4, July 2004.
Thomson & Winterbottom Expires March 19, 2007 [Page 15]
Internet-Draft Revised Civic LO September 2006
Appendix A. Acknowledgements
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 lead
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.
Thomson & Winterbottom Expires March 19, 2007 [Page 16]
Internet-Draft Revised Civic LO September 2006
Authors' Addresses
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Thomson & Winterbottom Expires March 19, 2007 [Page 17]
Internet-Draft Revised Civic LO September 2006
Intellectual Property Statement
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.
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.
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Thomson & Winterbottom Expires March 19, 2007 [Page 18]