draft-ietf-geopriv-revised-civic-lo-02.txt   draft-ietf-geopriv-revised-civic-lo-03.txt 
GEOPRIV WG M. Thomson GEOPRIV WG M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Expires: October 30, 2006 Andrew Expires: March 19, 2007 Andrew
April 28, 2006 September 15, 2006
Revised Civic Location Format for PIDF-LO Revised Civic Location Format for PIDF-LO
draft-ietf-geopriv-revised-civic-lo-02.txt draft-ietf-geopriv-revised-civic-lo-03.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 October 30, 2006. This Internet-Draft will expire on March 19, 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 11 skipping to change at page 2, line 11
road identity schemes. The format also includes support for the road identity schemes. The format also includes support for the
xml:lang language tag and restricts the types of elements where xml:lang language tag and restricts the types of elements where
appropriate. appropriate.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 7 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 8 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7
3.2.2. Directionals and other Qualifiers . . . . . . . . . . 8 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 9 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 9 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 11 3.5.2. Combining Multiple Elements Based on Language
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Preferences . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
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' . . . . 15 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 18
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
[I-D.ietf-geopriv-pidf-lo], it has been found that the specification [RFC4119], it has been found that the specification is lacking a
is lacking a number of additional parameters that can be used to more number of additional parameters that can be used to more precisely
precisely specify a civic location. These additional parameters have specify a civic location. These additional parameters have been
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 [I-D.ietf-geopriv-dhcp-
civil]. The document also introduces a hierarchical structure for civil]. The document also introduces a hierarchical structure for
thoroughfare (road) identification which is employed in some thoroughfare (road) identification which is employed in some
countries. New elements are defined to allow for even more precision countries. New elements are defined to allow for even more precision
in specifying a civic location. in specifying a civic location.
2. Terminology 2. Terminology
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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 [UPU-
S42]. 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 used to describe a civic location. Specifically [I-D.ietf- may be used to describe a civic location. Specifically [I-D.ietf-
geopriv-dhcp-civil] lists several civic address types (CAtypes) that geopriv-dhcp-civil] lists several civic address types (CAtypes) that
require support in the formal PIDF-LO definition that are not in require support in the formal PIDF-LO definition that are not in
[I-D.ietf-geopriv-pidf-lo]. [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 | 24 | 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 |
| | | | | | | | | |
| POBOX | 31 | Post office box (P.O. box) | U40 | | POBOX | 31 | Post office box (P.O. box) | U40 |
| | | | | | | | | |
skipping to change at page 6, line 4 skipping to change at page 6, line 4
| 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
Building: The "building" (BLD) conveys the name of a single building A complete description of these types is included in [I-D.ietf-
if the street address includes more than one building or the geopriv-dhcp-civil].
building name is helpful in identifying the location. (For
example, on university campuses, the house number is often not
displayed on buildings, while the building name is prominently
shown.)
Unit: The "unit" (UNIT) contains the name or number of a part of a
structure where there are separate administrative units, owners or
tenants, such as separate companies or families who occupy that
structure. Common examples include suite or apartment
designations.
Room: A "room" (ROOM) is the smallest identifiable subdivision of a
structure.
Place type: The "type of place" element (PLC) describes the type of
place described by the civic coordinates. For example, it
describes whether it is a home, office, street or other public
space. The values are drawn from the items in the location types
registry [I-D.ietf-geopriv-location-types-registry]. This
information makes it easy, for example, for the DHCP client to
then populate the presence information.
Post office box: The "post office box" element (POBOX) describes a
container, such as a pigeon hole, at a central mailing location,
where mail is held.
Additional code: The "additional code" item (ADDCODE) provides an
additional, country-specific code identifying the location. For
example, for Japan, it contains the Japan Industry Standard (JIS)
address code. The JIS address code provides a unique address
inside of Japan, down to the level of indicating the floor of the
building.
Seat: The "seat" element (SEAT) describes a single place where a
person might sit. Common examples include a seat in a theatre and
a cubicle in a cube farm.
Primary Road Name: The "primary road name" item (RD) is the name
given to the root road or street associated with the address. In
many cases this will the name of the road or street on which an
office or house exists, in some cases it will be the name of road
or street from which more granular information stems. In most
countries, this field should be used in preference to the "A6"
element, which was previously used for street information.
Road Section: The "road section" item (RDSEC) is an identifier that
represents a specific section or stretch of a primary road. This
is a new thoroughfare element and is useful where a primary road
reuses street numbering, or branch street names and there is no
other way to identify that this has occurred, such as a change in
municipality or suburb.
Branch Road Name: The "branch road name" item (RDBR) represents the
name or identifier of a road/street that intersects or is
associated with a primary road. The road branch is a new
thoroughfare element and is envisaged being used where branch
roads along a primary road reuse names and there is no other way,
other than the road section (RDSEC) identifier, to discern a
difference between them, such as a change in municipality or
suburb.
Sub-Branch Road Name: The "sub-branch road name" item (RDSUBBR)
represents the name or identifier of a road/street that intersects
or is associated with a branch road (RDBR). The road sub-branch
is a new thoroughfare element and is envisaged being used where
sub-branch roads reuse names and there is no way, other than the
road section (RDSEC) identifier, to discern a difference between
them, such as a change in municipality or suburb.
Road Pre-Modifier: The "road pre-modifier" item (PRM) is an optional
element of the complete street name. It is a word or phrase that
precedes all other elements of the street name and modifies it,
but is separated from the street name by a street name pre-
directional. An example is "Old" in "Old North First Street".
Road Post-Modifier: The "road post-modifier" item (POM) is an
optional element of the complete street name. It is a word or
phrase that follows all other elements of the street name and
modifies it, but is separated from the street name by a street
name post-directional and/or street suffix. An example is
"Extended" in "East End Avenue Extended".
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 8, line 17 skipping to change at page 6, line 31
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, it MUST NOT be used, the "RD" element MUST be used for names in [RFC4119], it MUST NOT be used, the "RD" element MUST be
thoroughfare data. 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 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 7 skipping to change at page 7, line 23
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 the
value of the "RD" element only. If road branches or sub-branches 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 [I-D.ietf-geopriv- The "country" element differs from that defined in [RFC4119] in that
pidf-lo] in that it now restricts the value space of the element to it now restricts the value space of the element to two upper case
two upper case characters, which correspond to the alpha-2 codes in characters, which correspond to the alpha-2 codes in [ISO.3166-1].
[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 a 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
skipping to change at page 10, line 4 skipping to change at page 8, line 19
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 enumerated values. which both contain enumerated values.
The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is
omitted in favour of using the "xml:lang" attribute. omitted in favour of using the "xml:lang" attribute.
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
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
available languages, or if there a conflicting values with the same
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 [I-D.ietf- uses a base type of "token" instead of "string" as used in [RFC4119].
geopriv-pidf-lo].
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
processors: processors:
<A4>North Wollongong</A4> <A4>North Wollongong</A4>
<A1>North <A1>North
Wollongong</A1> Wollongong</A1>
skipping to change at page 14, line 9 skipping to change at page 13, line 9
<PC>2500</PC> <PC>2500</PC>
<ROOM> Westerns and Classics </ROOM> <ROOM> Westerns and Classics </ROOM>
<PLC>store</PLC> <PLC>store</PLC>
<POBOX>Private Box 15</POBOX> <POBOX>Private Box 15</POBOX>
</civicAddress> </civicAddress>
6. Security Considerations 6. Security Considerations
The XML representation described in this document is designed for The XML representation described in this document is designed for
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 security considerations as are described in [RFC4119].
[I-D.ietf-geopriv-pidf-lo]. Considerations relating to the inclusion Considerations relating to the inclusion of this representation in
of this representation in other XML documents are outside the scope other XML documents are outside the scope of this document.
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 calls for IANA to register a new XML namespace, as per
the guidelines in [RFC3688]. the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
skipping to change at page 16, line 13 skipping to change at page 15, line 13
of this document. of this document.
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", W3C REC REC-xmlschema-2-20041028, Second Edition", World Wide Web Consortium
October 2004. Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[I-D.ietf-geopriv-dhcp-civil] [I-D.ietf-geopriv-dhcp-civil]
Schulzrinne, H., "Dynamic Host Configuration Protocol Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", Configuration Information",
draft-ietf-geopriv-dhcp-civil-09 (work in progress), draft-ietf-geopriv-dhcp-civil-09 (work in progress),
January 2006. January 2006.
[I-D.ietf-geopriv-location-types-registry]
Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", draft-ietf-geopriv-location-types-registry-05
(work in progress), March 2006.
[ISO.3166-1] [ISO.3166-1]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries and their the representation of names of countries and their
subdivisions - Part 1: Country codes", ISO Standard 3166- subdivisions - Part 1: Country codes", ISO Standard 3166-
1:1997, 1997, 1:1997, 1997,
<http://www.iso.org/iso/en/prods-services/iso3166ma/>. <http://www.iso.org/iso/en/prods-services/iso3166ma/>.
[ISO.3166-2] [ISO.3166-2]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes 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,
<http://www.iso.org/iso/en/prods-services/iso3166ma/>. <http://www.iso.org/iso/en/prods-services/iso3166ma/>.
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.
[I-D.ietf-geopriv-pidf-lo] [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 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 lead
to the introduction of the thoroughfare elements. Rohan Mahy to the introduction of the thoroughfare elements. Rohan Mahy
 End of changes. 18 change blocks. 
137 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/