Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
A richer XML format for street addresses inside a presence location object.
Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, February 2008, <https://www.rfc-editor.org/info/rfc5139>.
@misc{rfc5139,
series = {Request for Comments},
number = 5139,
howpublished = {RFC 5139},
publisher = {RFC Editor},
doi = {10.17487/RFC5139},
url = {https://www.rfc-editor.org/info/rfc5139},
author = {M. Thomson and J. Winterbottom},
title = {{Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)}},
pagetotal = 14,
year = 2008,
month = feb,
} RFC text
Contents
Network Working Group M. Thomson
Request for Comments: 5139 J. Winterbottom
Updates: 4119 Andrew
Category: Standards Track February 2008
Revised Civic Location Format for
Presence Information Data Format Location Object (PIDF-LO)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document defines an XML format for the representation of civic
location. This format is designed for use with Presence Information
Data Format Location Object (PIDF-LO) documents and replaces the
civic location format in RFC 4119. The format is based on the civic
address definition in PIDF-LO, but adds several new elements based on
the civic types defined for Dynamic Host Configuration Protocol
(DHCP), and adds a hierarchy to address complex road identity
schemes. The format also includes support for the xml:lang language
tag and restricts the types of elements where appropriate.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 3
3.1. Additional Civic Address Types . . . . . . . . . . . . . . 3
3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 4
3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 5
3.2.2. Directionals and Other Qualifiers . . . . . . . . . . 5
3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 6
3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 6
3.5.1. Converting from the DHCP Format . . . . . . . . . . . 7
3.5.2. Combining Multiple Elements Based on Language
Preferences . . . . . . . . . . . . . . . . . . . . . 7
3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 10
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11
7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
1. Introduction
Since the publication of the original PIDF-LO civic specification, in
[RFC4119], it has been found that the specification is lacking a
number of additional parameters that can be used to more precisely
specify a civic location. These additional parameters have been
largely captured in [RFC4776].
This document revises the GEOPRIV civic form to include the
additional civic parameters captured in [RFC4776]. The document also
introduces a hierarchical structure for thoroughfare (road)
identification, which is employed in some countries. New elements
are defined to allow for even more precision in specifying a civic
location.
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].
3. Changes from PIDF-LO
3.1. Additional Civic Address Types
[RFC4776] provides a full set of parameters that may be used to
describe a civic location. Specifically, [RFC4776] lists several
civic address types (CAtypes) that require support in the formal
PIDF-LO definition that are not in [RFC4119].
These changes include new elements that are required to support more
complex structures for naming street addresses. This is described in
more detail in Section 3.2.
+-----------+--------+-------------------------------+--------------+
| New Field | CAtype | Description | Example |
+-----------+--------+-------------------------------+--------------+
| BLD | 25 | Building (structure) | Hope Theatre |
| | | | |
| UNIT | 26 | Unit (apartment, suite) | 12a |
| | | | |
| ROOM | 28 | Room | 450F |
| | | | |
| PLC | 29 | Place-type | office |
| | | | |
| PCN | 30 | Postal community name | Leonia |
| | | | |
| POBOX | 31 | Post office box (P.O. box) | U40 |
| | | | |
| ADDCODE | 32 | Additional Code | 13203000003 |
| | | | |
| SEAT | 33 | Seat (desk, cubicle, | WS 181 |
| | | workstation) | |
| | | | |
| RD | 34 | Primary road or street | Broadway |
| | | | |
| RDSEC | 35 | Road section | 14 |
| | | | |
| RDBR | 36 | Road branch | Lane 7 |
| | | | |
| RDSUBBR | 37 | Road sub-branch | Alley 8 |
| | | | |
| PRM | 38 | Road pre-modifier | Old |
| | | | |
| POM | 39 | Road post-modifier | Extended |
+-----------+--------+-------------------------------+--------------+
Table 1: New Civic PIDF-LO Types
A complete description of these types is included in [RFC4776].
3.2. New Thoroughfare Elements
In some countries, a thoroughfare can be broken up into sections, and
it is not uncommon for street numbers to be repeated between
sections. A road section identifier is required to ensure that an
address is unique. For example, "West Alice Parade" in the figure
below has 5 sections, each numbered from 1; unless the section is
specified, "7 West Alice Parade" could exist in 5 different places.
The "RDSEC" element is used to specify the section.
Minor streets can share the same name, so that they can only be
distinguished by the major thoroughfare with which they intersect.
For example, both "West Alice Parade, Section 3" and "Bob Street"
could both be intersected by a "Carol Lane". The "RDBR" element is
used to specify a road branch where the name of the branch does not
uniquely identify the road. Road branches MAY also be used where a
major thoroughfare is split into sections.
Similar to the way that a road branch is associated with a road, a
road sub-branch is associated with a road branch. The "RDSUBBR"
element is used to identify road sub-branches.
The "A6" element is retained for use in those countries that require
this level of detail. Where "A6" was previously used for street
names in [RFC4119], it MUST NOT be used; the "RD" element MUST be
used for thoroughfare data.
The following figure shows a fictional arrangement of roads where
these new thoroughfare elements are applicable.
| ||
| ---------------||
| Carol La. Carol La. || Bob
| || St.
| West Alice Pde. ||
==========/=================/===============/==========||===========
Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5
| ||
----------| Carol ||
Alley 2 | La. ||
| ||
3.2.1. Street Numbering
The introduction of new thoroughfare elements affects the
interpretation of several aspects of more specific civic address
data. In particular, street numbering (the "HNO" element) applies to
the most specific road element specified, that is, the first
specified element from "RDSUBBR", "RDBR", "RDSEC", or "RD".
3.2.2. Directionals and Other Qualifiers
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 uppercase
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 formed of a country code and hyphen plus a code of
one, two, or three characters or numerals. For the "A1" element, the
leading country code and hyphen are omitted and only the subdivision
code is included.
For example, the codes for Canada include CA-BC, CA-ON, CA-QC;
Luxembourg has just three single-character codes, LU-D, LU-G, and
LU-L; Australia uses both two- and three-character codes, AU-ACT,
AU-NSW, AU-NT; and France uses numerical codes for mainland France
and letters for territories, FR-75, FR-NC. This results in the
following fragments:
<country>CA</country><A1>ON</A1>
<country>LU</country><A1>L</A1>
<country>AU</country><A1>ACT</A1>
<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 language-neutral values. The range of allowed
values for "country" is defined in [ISO.3166-1]; the range of allowed
values for "PLC" is described in the IANA registry defined by
[RFC4589].
The "script" field defined in [RFC4776] is omitted in favor of using
the "xml:lang" attribute with a script subtag [RFC4646].
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 [RFC4776] permits the inclusion
of an element multiple times with different languages or scripts.
However, this XML form only permits a single instance of each
element. Multiple "civicAddress" elements are required if any
element is duplicated with different languages. If the same language
and script are used for all elements, or no elements are duplicated,
the format can be converted into a single civic address.
Where there are duplicated elements in different languages, a
"civicAddress" element is created for each language that is present.
All elements that are in that language are included. Elements that
are language independent, like the "country" and "PLC" elements, are
added to all "civicAddress" elements.
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 are 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 " ".
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"/>
<xs:element name="LMK" type="ca:caType" minOccurs="0"/>
<xs:element name="LOC" type="ca:caType" minOccurs="0"/>
<xs:element name="FLR" type="ca:caType" minOccurs="0"/>
<xs:element name="NAM" type="ca:caType" minOccurs="0"/>
<xs:element name="PC" type="ca:caType" minOccurs="0"/>
<xs:element name="BLD" type="ca:caType" minOccurs="0"/>
<xs:element name="UNIT" type="ca:caType" minOccurs="0"/>
<xs:element name="ROOM" type="ca:caType" minOccurs="0"/>
<xs:element name="SEAT" type="ca:caType" minOccurs="0"/>
<xs:element name="PLC" type="xs:token" minOccurs="0"/>
<xs:element name="PCN" type="ca:caType" minOccurs="0"/>
<xs:element name="POBOX" type="ca:caType" minOccurs="0"/>
<xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
5. Example
<civicAddress xml:lang="en-AU"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AU</country>
<A1>NSW</A1>
<A3> Wollongong
</A3><A4>North Wollongong
</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<LMK>
Gilligan's Island
</LMK> <LOC>Corner</LOC>
<NAM> Video Rental Store </NAM>
<PC>2500</PC>
<ROOM> Westerns and Classics </ROOM>
<PLC>store</PLC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
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.
7. IANA Considerations
7.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
This document defines a new XML namespace (as per the guidelines in
[RFC3688]) that has been registered with IANA.
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>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt">
RFC5139</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.
7.3. CAtype Registry Update
This document updates the civic address type registry established by
[RFC4776]. The "PIDF" column of the CAtypes table has been updated
to include the types shown in the first column of Table 1.
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>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", RFC 4589, July 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 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.
[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.
8.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[UPU-S42] Universal Postal Union (UPU), "International Postal
Address Components and Templates", UPS SB42-4,
July 2004.
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 led
to the introduction of the thoroughfare elements. Rohan Mahy
suggested the ISO 3166-2 recommendation for A1. In addition, we
would like to thank Jon Peterson for his work in defining the
PIDF-LO.
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/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
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.
ISO Plain Language
On this page
§1What Is Being Revised
Since the publication of the original PIDF-LO civic specification in RFC 4119, it has been found that the specification lacks a number of additional parameters that can be used to specify a civic location more precisely. Those additional parameters have largely been captured in RFC 4776, the DHCP option for civic address configuration.
This document revises the GEOPRIV civic form to include the additional civic parameters of RFC 4776. It also introduces a hierarchical structure for identifying a road, a structure that is used in some countries, and defines new elements that allow still more precision in a civic location.
The document uses the term thoroughfare to mean a road, or part of a road, or another access route along which the final point is identified, which is the same sense used by the Universal Postal Union.
When the first version of this format was written, it turned out to be missing several parts of a real address. This RFC adds them back in, and adds a way to describe a street that has several sections with the same numbers on each.
§3.1The New Civic Address Types
RFC 4776 lists several civic address types that need support in the formal PIDF-LO definition and that are not in RFC 4119. The document adds them as new elements, each with a code in the civic address type registry.
Four of the new elements describe the destination inside a building: BLD for the building or structure, with the example Hope Theatre; UNIT for the unit, apartment or suite, for example 12a; ROOM for the room, for example 450F; and SEAT for the seat, desk or workstation, for example WS 181. Two more name the kind of place and the community: PLC for the place type, for example office, and PCN for the postal community name, for example Leonia. Two handle the post: POBOX for a post office box, for example U40, and ADDCODE for an additional code, for example 13203000003.
The remaining six are about the road itself and are described in the next section: RD for the primary road or street, RDSEC for a road section, RDBR for a road branch, RDSUBBR for a road sub-branch, PRM for a road pre-modifier and POM for a road post-modifier. Their codes run from 25 to 39, and the table in Section 3.1 lists each element with its code, its meaning and an example. A complete description of the types is in RFC 4776.
The new elements fill in the parts of an address that were missing: which building, which unit, which room, which seat, what kind of place it is, the post office box, and the parts of the road name that come before and after the main street name.
- 25BLD — Building or structure, for example Hope Theatre.
- 26UNIT — Unit, apartment or suite, for example 12a.
- 28ROOM — Room, for example 450F.
- 29PLC — Place type, for example office.
- 30PCN — Postal community name, for example Leonia.
- 31POBOX — Post office box, for example U40.
- 32ADDCODE — Additional code, for example 13203000003.
- 33SEAT — Seat, desk or workstation, for example WS 181.
- 34RD — Primary road or street, for example Broadway.
- 35RDSEC — Road section, for example 14.
- 36RDBR — Road branch, for example Lane 7.
- 37RDSUBBR — Road sub-branch, for example Alley 8.
- 38PRM — Road pre-modifier, for example Old.
- 39POM — Road post-modifier, for example Extended.
§3.2Breaking a Road Name into Parts
In some countries a thoroughfare is broken into sections, and street numbers are repeated between the sections. A road section identifier is needed so that an address is unique. The example given is a street with five sections, each numbered from one, so that without the section the number seven could exist in five different places. The RDSEC element names that section.
Minor streets can share a name, so that they can only be told apart by the major thoroughfare they intersect. Both a street section and another street could be crossed by the same lane, so the RDBR element names a road branch where the branch name does not uniquely identify the road. Road branches may also be used where a major thoroughfare is split into sections. A road sub-branch is associated with a road branch in the same way, and the RDSUBBR element identifies it.
Two rules follow from this. The street numbering, held in the HNO element, applies to the most specific road element given, that is, the first one of RDSUBBR, RDBR, RDSEC or RD that is specified. And the PRM, POM, PRD, POD and STS elements always apply to the value of the RD element alone. If a road branch or sub-branch needs a suffix or a qualifier, that text must be included in the RDBR or RDSUBBR element instead.
The A6 element is retained for the countries that require that level of detail, but where A6 was previously used for street names in RFC 4119 it must not be used; the RD element must be used for thoroughfare data.
Some streets are split into sections that each start their numbering again, and side streets can share a name. So the format has an element for the section, one for a branch off the main road and one for a lane off that branch. The house number belongs to the most specific of those that is given.
- RD the primary road, for example Flinders Street
- RDSEC a section of the road
- RDBR a branch off the section
- RDSUBBR a sub-branch off the branch
- RDBR a branch off the section
- RDSEC a section of the road
§3.3The Country and the Top-Level Subdivision
The country element differs from the one defined in RFC 4119: it now restricts the value to two uppercase characters, which are the alpha-2 codes of ISO 3166-1.
The A1 element holds 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 for a country subdivision should be used. That code is made of a country code and a hyphen plus a code of one, two or three characters or numerals. For the A1 element the leading country code and the hyphen are omitted, and only the subdivision code is included.
The examples given show how different countries code their subdivisions. Canada uses CA-BC, CA-ON and CA-QC. Luxembourg has just three single-character codes, LU-D, LU-G and LU-L. Australia uses both two-character and three-character codes, AU-ACT, AU-NSW and AU-NT. France uses numerical codes for mainland France and letters for its territories, FR-75 and FR-NC. These produce the fragments <country>CA</country><A1>ON</A1>, <country>LU</country><A1>L</A1>, <country>AU</country><A1>ACT</A1> and <country>FR</country><A1>75</A1>.
The country is written as the two-letter code from the ISO list, such as AU. The region within the country uses the ISO subdivision code with the country part left off, so New South Wales is NSW and Paris is 75.
- countryTwo uppercase letters from the ISO 3166-1 list, such as AU.
- A1The ISO 3166-2 subdivision code without the country part, such as NSW.
- HNOThe street number, which applies to the most specific road element given.
- LMKA landmark near the address, such as a shop or a building.
- PCThe postal code of the address.
- PLCThe kind of place, such as store or office.
§3.5Languages, Scripts and Whitespace
The schema allows the xml:lang attribute on every element except country and PLC, which hold language-neutral values. The script field of RFC 4776 is omitted in favour of using the xml:lang attribute with a script subtag, as described in RFC 4646.
It is recommended that each civicAddress element uses one language only, or a combination of languages that is consistent. Where a civic location is represented in several languages, several civicAddress elements should be included in the PIDF-LO document, and for civic addresses that together describe the same location they should go into the same tuple.
The DHCP format allows an element to appear several times with different languages or scripts, while the XML form permits only one instance of each element, so a conversion needs several civicAddress elements if any element is duplicated in a different language. One civicAddress element is created for each language present, holding all the elements in that language, and the language-independent elements such as country and PLC are added to all of them. Where the receiver is known and has stated its language preferences, for instance through the Accept-Language header of SIP or HTTP, a single document can be built from those preferences: every value that occurs once is used, and where several values exist each is weighted by the preferences and the highest one is chosen. An arbitrary value is selected if two values have the same preference, if there is no preference for the available languages, or if there are conflicting values in the same language.
The schema uses the base type token rather than string, which RFC 4119 used. The token type makes sure that whitespace inside a document is normalized and collapsed before it reaches a processor, so that three fragments that differ only in spacing are treated as the same value. Whitespace can still be included in a value by writing a character reference such as  .
Each part of the address can say which language it is written in, and an address given in two languages is written as two civicAddress elements. The format also tidies up whitespace, so that an address written with extra spaces is treated the same as one written tightly.
§4The Schema and Its Registration
The schema for civic addresses has the target namespace urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr. The civicAddress element holds a sequence of optional elements in a fixed order: country, then A1 to A6, then the qualifiers and the road, then the house number and its suffix, then the landmark and location, the floor and the name, the postal code, then the building, unit, room and seat, the place type, the postal community name, the post office box and the additional code. Elements from other namespaces may follow, and any attributes from any namespace are allowed.
The country element uses a simple type restricted to two uppercase letters, while the other elements use a type based on token with an optional xml:lang attribute, except PLC which uses token alone.
The document registers the namespace with IANA under the guidelines of RFC 3688, with the registrant contact of the IETF GEOPRIV working group, and registers the XML schema under urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr, with the schema itself being the whole of Section 4. It also updates the civic address type registry established by RFC 4776, adding the new types to the PIDF column of the registry table.
The document gives the XML schema that says which elements may appear, in which order, and what each one may hold. It also registers the namespace and the schema with IANA, and adds the new address types to the registry.
§5A Worked Address
The example in Section 5 is a civic address in English for Australia, with the country AU and the state NSW. It names the locality Wollongong and the district North Wollongong, the thoroughfare Flinders Street, a branch called Campbell Street, the landmark Gilligan's Island, the location Corner, the name of the place Video Rental Store, the postal code 2500, the room Westerns and Classics, the place type store, and a post office box, Private Box 15. The whitespace inside some elements is deliberate in the example, and the token type collapses it when the document is processed.
The example shows an address for a video rental store: the country and state, the town and district, the street and the lane off it, a landmark, the name of the shop, the postal code, the room, and a post office box.
<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>§6Security Considerations
The XML representation described in this document is designed for inclusion in a PIDF-LO document, and it is therefore subject to the same security considerations as those described in RFC 4119. Considerations about including the representation in other XML documents are outside the scope of this document.
These addresses say where somebody is, so the format inherits the same privacy and security rules as the presence location format it was written for. Using it in other kinds of XML document is not covered here.