draft-ietf-geopriv-revised-civic-lo-07.txt   rfc5139.txt 
GEOPRIV WG M. Thomson Network Working Group M. Thomson
Internet-Draft J. Winterbottom Request for Comments: 5139 J. Winterbottom
Updates: 4119 (if approved) Andrew Updates: 4119 Andrew
Intended status: Standards Track December 7, 2007 Category: Standards Track February 2008
Expires: June 9, 2008
Revised Civic Location Format for PIDF-LO
draft-ietf-geopriv-revised-civic-lo-07.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 June 9, 2008. Revised Civic Location Format for
Presence Information Data Format Location Object (PIDF-LO)
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). 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 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 Presence Information
(PIDF-LO) documents and replaces the civic location format in RFC Data Format Location Object (PIDF-LO) documents and replaces the
4119. The format is based on the civic address definition in civic location format in RFC 4119. The format is based on the civic
PIDF-LO, but adds several new elements based on the civic types address definition in PIDF-LO, but adds several new elements based on
defined for DHCP, and adds a hierarchy to address complex road the civic types defined for Dynamic Host Configuration Protocol
identity schemes. The format also includes support for the xml:lang (DHCP), and adds a hierarchy to address complex road identity
language tag and restricts the types of elements where appropriate. schemes. The format also includes support for the xml:lang language
tag and restricts the types of elements where appropriate.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 3
3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 3
3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 4
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 5
3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7 3.2.2. Directionals and Other Qualifiers . . . . . . . . . . 5
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 6
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 6
3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 7
3.5.2. Combining Multiple Elements Based on Language 3.5.2. Combining Multiple Elements Based on Language
Preferences . . . . . . . . . . . . . . . . . . . . . 8 Preferences . . . . . . . . . . . . . . . . . . . . . 7
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
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' . . . . 10
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 15 7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
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 [RFC4776]. largely captured in [RFC4776].
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 [RFC4776]. The document also additional civic parameters captured in [RFC4776]. The document also
introduces a hierarchical structure for thoroughfare (road) introduces a hierarchical structure for thoroughfare (road)
identification which is employed in some countries. New elements are identification, which is employed in some countries. New elements
defined to allow for even more precision in specifying a civic are defined to allow for even more precision in specifying a civic
location. 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 identified. This is consistent with the definition used in
[UPU-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
[RFC4776] provides a full set of parameters that may be used to [RFC4776] provides a full set of parameters that may be used to
describe a civic location. Specifically [RFC4776] lists several describe a civic location. Specifically, [RFC4776] lists several
civic address types (CAtypes) that require support in the formal civic address types (CAtypes) that require support in the formal
PIDF-LO definition that are not in [RFC4119]. PIDF-LO definition that are not in [RFC4119].
These changes include and new elements that are required to support These changes include new elements that are required to support more
more complex structures for naming street addresses, this is complex structures for naming street addresses. This is described in
described in more detail in Section 3.2. more detail in Section 3.2.
+-----------+--------+-------------------------------+--------------+ +-----------+--------+-------------------------------+--------------+
| New Field | CAtype | Description | Example | | New Field | CAtype | Description | Example |
+-----------+--------+-------------------------------+--------------+ +-----------+--------+-------------------------------+--------------+
| BLD | 25 | Building (structure) | Hope Theatre | | BLD | 25 | Building (structure) | Hope Theatre |
| | | | | | | | | |
| UNIT | 26 | Unit (apartment, suite) | 12a | | UNIT | 26 | Unit (apartment, suite) | 12a |
| | | | | | | | | |
| ROOM | 28 | Room | 450F | | ROOM | 28 | Room | 450F |
| | | | | | | | | |
skipping to change at page 6, line 4 skipping to change at page 4, line 39
| 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 [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 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" in the figure
each numbered from 1; unless the section is specified "7 West Alice below has 5 sections, each numbered from 1; unless the section is
Parade" could exist in 5 different places. The "RDSEC" element is specified, "7 West Alice Parade" could exist in 5 different places.
used to specify the section. The "RDSEC" element is used to specify the section.
Minor streets can share the same name, so that they can only be Minor streets can share the same name, so that they can only be
distinguished by the major thoroughfare with which they intersect. distinguished by the major thoroughfare with which they intersect.
For example, both "West Alice Parade, Section 3" and "Bob Street" For example, both "West Alice Parade, Section 3" and "Bob Street"
could both be interested by a "Carol Lane". The "RDBR" element is 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 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 uniquely identify the road. Road branches MAY also be used where a
major thoroughfare is split into sections. major thoroughfare is split into sections.
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. used for thoroughfare data.
The following example figure shows a fictional arrangement of roads The following figure shows a fictional arrangement of roads where
where these new thoroughfare elements are applicable. these new thoroughfare elements are applicable.
| || | ||
| ---------------|| | ---------------||
| Carol La. Carol La. || Bob | Carol La. Carol La. || Bob
| || St. | || St.
| West Alice Pde. || | West Alice Pde. ||
==========/=================/===============/==========||=========== ==========/=================/===============/==========||===========
Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5
| || | ||
----------| Carol || ----------| Carol ||
Alley 2 | La. || Alley 2 | La. ||
| || | ||
3.2.1. Street Numbering 3.2.1. Street Numbering
The introduction of new thoroughfare elements affects the The introduction of new thoroughfare elements affects the
interpretation of several of more specific civic address data. In interpretation of several aspects of more specific civic address
particular, street numbering (the "HNO" element) applies to the most data. In particular, street numbering (the "HNO" element) applies to
specific road element specified. That is, the first specified the most specific road element specified, that is, the first
element from: "RDSUBBR", "RDBR", "RDSEC", or "RD". 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 The "PRM", "POM", "PRD", "POD", and "STS" elements always apply to
value of the "RD" element only. If road branches or sub-branches the value of the "RD" element only. If road branches or sub-branches
require street suffixes or qualifiers, they MUST be included in the require street suffixes or qualifiers, they MUST be included in the
"RDBR" or "RDSUBBR" element text. "RDBR" or "RDSUBBR" element text.
3.3. Country Element 3.3. Country Element
The "country" element differs from that defined in [RFC4119] in that The "country" element differs from that defined in [RFC4119] in that
it now restricts the value space of the element to two upper case 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]. 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 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 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 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 [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 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 one, two, or three characters or numerals. For the "A1" element, the
leading country code and hyphen are omitted and only the subdivision leading country code and hyphen are omitted and only the subdivision
code is included. code is included.
For example, the codes for Canada include CA-BC, CA-ON, CA-QC; 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 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- LU-L; Australia uses both two- and three-character codes, AU-ACT,
NSW, AU-NT; France uses numerical codes for mainland France and AU-NSW, AU-NT; and France uses numerical codes for mainland France
letters for territories: FR-75, FR-NC. This results in the following and letters for territories, FR-75, FR-NC. This results in the
fragments: 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 schema defined for civic addresses allows for the addition of
the "xml:lang" attribute to all elements except "country" and "PLC", the "xml:lang" attribute to all elements except "country" and "PLC",
which both contain language-neutral values. The range of allowed which both contain language-neutral values. The range of allowed
values for "country" are defined in [ISO.3166-1]; the range of values for "country" is defined in [ISO.3166-1]; the range of allowed
allowed values for "PLC" are defined in the IANA registry defined by values for "PLC" is described in the IANA registry defined by
[RFC4589]. [RFC4589].
The "script" field defined in [RFC4776] is omitted in favour of using The "script" field defined in [RFC4776] is omitted in favor of using
the "xml:lang" attribute with a script subtag [RFC4646]. the "xml:lang" attribute with a script subtag [RFC4646].
It is RECOMMENDED that each "civicAddress" element use one language It is RECOMMENDED that each "civicAddress" element use one language
only, or a combination of languages that is consistent. Where a only, or a combination of languages that is consistent. Where a
civic location is represented in multiple languages multiple civic location is represented in multiple languages, multiple
"civicAddress" elements SHOULD be included in the PIDF-LO document. "civicAddress" elements SHOULD be included in the PIDF-LO document.
For civic addresses that form a complex to describe the same For civic addresses that form a complex to describe the same
location, these SHOULD be inserted into the same tuple. 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 The DHCP format for civic addresses [RFC4776] permits the inclusion
of an element multiple times with different languages or scripts. of an element multiple times with different languages or scripts.
However, this XML form only permits a single instance of each However, this XML form only permits a single instance of each
element. Multiple "civicAddress" elements are required if any element. Multiple "civicAddress" elements are required if any
element is duplicated with different languages. If the same language element is duplicated with different languages. If the same language
skipping to change at page 8, line 31 skipping to change at page 7, line 15
For civic addresses that form a complex to describe the same For civic addresses that form a complex to describe the same
location, these SHOULD be inserted into the same tuple. 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 The DHCP format for civic addresses [RFC4776] permits the inclusion
of an element multiple times with different languages or scripts. of an element multiple times with different languages or scripts.
However, this XML form only permits a single instance of each However, this XML form only permits a single instance of each
element. Multiple "civicAddress" elements are required if any element. Multiple "civicAddress" elements are required if any
element is duplicated with different languages. If the same language element is duplicated with different languages. If the same language
and script is used for all elements, or no elements are duplicated, and script are used for all elements, or no elements are duplicated,
the format can be converted into a single civic address. the format can be converted into a single civic address.
Where there are duplicated elements in different languages, a Where there are duplicated elements in different languages, a
"civicAddress" element is created for each language that is present. "civicAddress" element is created for each language that is present.
All elements that are in that language are included. Elements that All elements that are in that language are included. Elements that
are language independent, like the "country" and "PLC" elements, are are language independent, like the "country" and "PLC" elements, are
added to all "civicAddress" elements. 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
skipping to change at page 14, line 10 skipping to change at page 10, line 39
inclusion in a PIDF-LO document. As such, it is subject to the same inclusion in a PIDF-LO document. As such, it is subject to the same
security considerations as are described in [RFC4119]. security considerations as are described in [RFC4119].
Considerations relating to the inclusion of this representation in Considerations relating to the inclusion of this representation in
other XML documents are outside the scope of this document. other XML documents are outside the scope of this document.
7. IANA Considerations 7. IANA Considerations
7.1. URN sub-namespace registration for 7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
This document calls for IANA to register a new XML namespace, as per This document defines a new XML namespace (as per the guidelines in
the guidelines in [RFC3688]. [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), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>GEOPRIV Civic Address</title> <title>GEOPRIV Civic Address</title>
</head> </head>
<body> <body>
<h1>Format for Distributing Civic Address in GEOPRIV</h1> <h1>Format for Distributing Civic Address in GEOPRIV</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt">
with the RFC number for this specification.]] RFC5139</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
7.2. XML Schema Registration 7.2. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688]. [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), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com). Martin Thomson (martin.thomson@andrew.com).
The XML for this schema can be found as the entirety of Section 4 The XML for this schema can be found as the entirety of Section 4
of this document. of this document.
7.3. CAtype Registry Update 7.3. CAtype Registry Update
This document updates the civic address type registry established by This document updates the civic address type registry established by
[RFC4776]. The "PIDF" column of the CAtypes table has been updated [RFC4776]. The "PIDF" column of the CAtypes table has been updated
to include the types shown in the first column of Table 1. to include the types shown in the first column of Table 1.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", RFC 4589, July 2006. Registry", RFC 4589, July 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006. Languages", BCP 47, RFC 4646, September 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[ISO.3166-1] [ISO.3166-1] International Organization for Standardization, "Codes
International Organization for Standardization, "Codes for for the representation of names of countries and their
the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard
subdivisions - Part 1: Country codes", ISO Standard 3166- 3166- 1:1997, 1997.
1:1997, 1997.
[ISO.3166-2] [ISO.3166-2] International Organization for Standardization, "Codes
International Organization for Standardization, "Codes for for the representation of names of countries and their
the representation of names of countries and their
subdivisions - Part 2: Country subdivision code", subdivisions - Part 2: Country subdivision code",
ISO Standard 3166-2:1998, 1998. ISO Standard 3166-2:1998, 1998.
8.2. Informative References 8.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[UPU-S42] Universal Postal Union (UPU), "International Postal [UPU-S42] Universal Postal Union (UPU), "International Postal
Address Components and Templates", UPS SB42-4, July 2004. Address Components and Templates", UPS SB42-4,
July 2004.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank Henning Schulzrinne for his The authors would like to thank Henning Schulzrinne for his
assistance in defining the additional civic address types, assistance in defining the additional civic address types,
particularly his research into different addressing schemes that lead particularly his research into different addressing schemes that led
to the introduction of the thoroughfare elements. Rohan Mahy to the introduction of the thoroughfare elements. Rohan Mahy
suggested the ISO 3166-2 recommendation for A1. In addition we would suggested the ISO 3166-2 recommendation for A1. In addition, we
like to thank Jon Peterson for his work in defining the PIDF-LO. would like to thank Jon Peterson for his work in defining the
PIDF-LO.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
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/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 19, line 44 skipping to change at line 561
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 41 change blocks. 
123 lines changed or deleted 101 lines changed or added

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