draft-ietf-geopriv-revised-civic-lo-03.txt   draft-ietf-geopriv-revised-civic-lo-04.txt 
GEOPRIV WG M. Thomson GEOPRIV WG M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Expires: March 19, 2007 Andrew Intended status: Informational Andrew
September 15, 2006 Expires: March 24, 2007 September 20, 2006
Revised Civic Location Format for PIDF-LO Revised Civic Location Format for PIDF-LO
draft-ietf-geopriv-revised-civic-lo-03.txt draft-ietf-geopriv-revised-civic-lo-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2007. This Internet-Draft will expire on March 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines an XML format for the representation of civic This document defines an XML format for the representation of civic
location. This format is designed for use with PIDF Location Object location. This format is designed for use with PIDF Location Object
(PIDF-LO) documents. The format is based on the civic address (PIDF-LO) documents. The format is based on the civic address
skipping to change at page 2, line 19 skipping to change at page 2, line 30
3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5
3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5
3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7
3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8
3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8
3.5.2. Combining Multiple Elements Based on Language 3.5.2. Combining Multiple Elements Based on Language
Preferences . . . . . . . . . . . . . . . . . . . . . 8 Preferences . . . . . . . . . . . . . . . . . . . . . 9
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. URN sub-namespace registration for 7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Introduction 1. Introduction
Since the publication of the original PIDF-LO civic specification, in Since the publication of the original PIDF-LO civic specification, in
[RFC4119], it has been found that the specification is lacking a [RFC4119], it has been found that the specification is lacking a
number of additional parameters that can be used to more precisely number of additional parameters that can be used to more precisely
specify a civic location. These additional parameters have been specify a civic location. These additional parameters have been
largely captured in [I-D.ietf-geopriv-dhcp-civil]. largely captured in [I-D.ietf-geopriv-dhcp-civil].
This document revises the GEOPRIV civic form to include the This document revises the GEOPRIV civic form to include the
additional civic parameters captured in [I-D.ietf-geopriv-dhcp- additional civic parameters captured in
civil]. The document also introduces a hierarchical structure for [I-D.ietf-geopriv-dhcp-civil]. The document also introduces a
thoroughfare (road) identification which is employed in some hierarchical structure for thoroughfare (road) identification which
countries. New elements are defined to allow for even more precision is employed in some countries. New elements are defined to allow for
in specifying a civic location. even more precision in specifying a civic location.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "thoroughfare" is used in this document to describe a road 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 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- identified. This is consistent with the definition used in
S42]. [UPU-S42].
3. Changes from PIDF-LO 3. Changes from PIDF-LO
3.1. Additional Civic Address Types 3.1. Additional Civic Address Types
[I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that [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- may be used to describe a civic location. Specifically
geopriv-dhcp-civil] lists several civic address types (CAtypes) that [I-D.ietf-geopriv-dhcp-civil] lists several civic address types
require support in the formal PIDF-LO definition that are not in (CAtypes) that require support in the formal PIDF-LO definition that
[RFC4119]. are not in [RFC4119].
These changes include and new elements that are required to support These changes include and new elements that are required to support
more complex structures for naming street addresses, this is more complex structures for naming street addresses, this is
described in more detail in Section 3.2. described in more detail in Section 3.2.
+--------------+--------+-----------------------------+-------------+ +---------------+--------+----------------------------+-------------+
| New Civic | CAtype | Description | Example | | New Civic | CAtype | Description | Example |
| Field | | | | | Field | | | |
+--------------+--------+-----------------------------+-------------+ +---------------+--------+----------------------------+-------------+
| BLD | 25 | Building (structure) | Hope | | BLD | 25 | Building (structure) | Hope |
| | | | Theatre | | | | | Theatre |
| | | | | | | | | |
| UNIT | 26 | Unit (apartment, suite) | 12a | | UNIT | 26 | Unit (apartment, suite) | 12a |
| | | | | | | | | |
| ROOM | 28 | Room | 450F | | ROOM | 28 | Room | 450F |
| | | | | | | | | |
| PLC | 29 | Place-type | office | | PLC | 29 | Place-type | office |
| | | | | | | | | |
| PCN | 30 | Postal community name | Leonia |
| | | | |
| POBOX | 31 | Post office box (P.O. box) | U40 | | POBOX | 31 | Post office box (P.O. box) | U40 |
| | | | | | | | | |
| ADDCODE | 32 | Additional Code | 13203000003 | | ADDCODE | 32 | Additional Code | 13203000003 |
| | | | | | | | | |
| SEAT | 33 | Seat (desk, cubicle, | WS 181 | | SEAT | 33 | Seat (desk, cubicle, | WS 181 |
| | | workstation) | | | | | workstation) | |
| | | | | | | | | |
| RD | 34 | Primary road or street | Broadway | | RD | 34 | Primary road or street | Broadway |
| | | | | | | | | |
| RDSEC | 35 | Road section | 14 | | RDSEC | 35 | Road section | 14 |
| | | | | | | | | |
| RDBR | 36 | Road branch | Lane 7 | | RDBR | 36 | Road branch | Lane 7 |
| | | | | | | | | |
| RDSUBBR | 37 | Road sub-branch | Alley 8 | | RDSUBBR | 37 | Road sub-branch | Alley 8 |
| | | | | | | | | |
| PRM | 38 | Road pre-modifier | Old | | PRM | 38 | Road pre-modifier | Old |
| | | | | | | | | |
| POM | 39 | Road post-modifier | Extended | | 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 [I-D.ietf-
geopriv-dhcp-civil]. A complete description of these types is included in
[I-D.ietf-geopriv-dhcp-civil].
3.2. New Thoroughfare Elements 3.2. New Thoroughfare Elements
In some countries a thoroughfare can be broken up into sections, and In some countries a thoroughfare can be broken up into sections, and
it is not uncommon for street numbers to be repeated between it is not uncommon for street numbers to be repeated between
sections. A road section identifier is required to ensure that an sections. A road section identifier is required to ensure that an
address is unique. For example, "West Alice Parade" has 5 sections, address is unique. For example, "West Alice Parade" has 5 sections,
each numbered from 1; unless the section is specified "7 West Alice each numbered from 1; unless the section is specified "7 West Alice
Parade" could exist in 5 different places. The "RDSEC" element is Parade" could exist in 5 different places. The "RDSEC" element is
used to specify the section. used to specify the section.
skipping to change at page 6, line 35 skipping to change at page 6, line 37
Similar to the way that a road branch is associated with a road, a 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" road sub-branch is associated with a road branch. The "RDSUBBR"
element is used to identify road sub-branches. element is used to identify road sub-branches.
The "A6" element is retained for use in those countries that require The "A6" element is retained for use in those countries that require
this level of detail. Where "A6" was previously used for street this level of detail. Where "A6" was previously used for street
names in [RFC4119], it MUST NOT be used, the "RD" element MUST be names in [RFC4119], it MUST NOT be used, the "RD" element MUST be
used for thoroughfare data. However, without additional information used for thoroughfare data. However, without additional information
these fields MUST not be interchanged when converting between these fields MUST not be interchanged when converting between
different civic formats. Where civic address information is obtained different civic formats. Where civic address information is obtained
from another format, such as the DHCP form [I-D.ietf-geopriv-dhcp- from another format, such as the DHCP form
civil], the "A6" element MUST be copied directly from the source [I-D.ietf-geopriv-dhcp-civil], the "A6" element MUST be copied
format. directly from the source format.
The following example figure shows a fictional arrangement of roads The following example figure shows a fictional arrangement of roads
where these new thoroughfare elements are applicable. where these new thoroughfare elements are applicable.
| || | ||
| ---------------|| | ---------------||
| Carol La. Carol La. || Bob | Carol La. Carol La. || Bob
| || St. | || St.
| West Alice Pde. || | West Alice Pde. ||
==========/=================/===============/==========||=========== ==========/=================/===============/==========||===========
skipping to change at page 9, line 4 skipping to change at page 9, line 18
has indicated language preferences, a single XML format can be has indicated language preferences, a single XML format can be
constructed using those preferences. For example, language constructed using those preferences. For example, language
preferences can be indicated by the "Accept-Language" header in the preferences can be indicated by the "Accept-Language" header in the
SIP or HTTP protocols. SIP or HTTP protocols.
All elements that have only one value, irrespective of language, are All elements that have only one value, irrespective of language, are
used. Where multiple values exist, each value is assigned a used. Where multiple values exist, each value is assigned a
weighting based on the language preferences. The value with the weighting based on the language preferences. The value with the
highest weighting is selected. An arbitrary value is selected if two highest weighting is selected. An arbitrary value is selected if two
values have the same preference, if there is no preference for the values have the same preference, if there is no preference for the
available languages, or if there a conflicting values with the same available languages, or if there are conflicting values with the same
language. language.
3.6. Whitespace 3.6. Whitespace
The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 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]. uses a base type of "token" instead of "string" as used in [RFC4119].
The "token" type ensures that whitespace within instance documents is The "token" type ensures that whitespace within instance documents is
normalized and collapsed before being passed to a processor. This normalized and collapsed before being passed to a processor. This
ensures that the following fragments are considered equivalent by XML ensures that the following fragments are considered equivalent by XML
skipping to change at page 11, line 14 skipping to change at page 11, line 14
<xs:element name="LMK" 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="LOC" type="ca:caType" minOccurs="0"/>
<xs:element name="FLR" 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="NAM" type="ca:caType" minOccurs="0"/>
<xs:element name="PC" 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="BLD" type="ca:caType" minOccurs="0"/>
<xs:element name="UNIT" 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="ROOM" type="ca:caType" minOccurs="0"/>
<xs:element name="SEAT" 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="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="POBOX" type="ca:caType" minOccurs="0"/>
<xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/> <xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
5. Example 5. Example
skipping to change at page 18, line 5 skipping to change at page 18, line 5
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Intellectual Property Statement Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 29 skipping to change at page 18, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 18 change blocks. 
43 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/