]> Andrew

PO Box U40 Wollongong University Campus NSW 2500 AU +61 2 4221 2915 martin.thomson@andrew.com http://www.andrew.com/

Andrew

PO Box U40 Wollongong University Campus NSW 2500 AU +61 2 4221 2938 james.winterbottom@andrew.com http://www.andrew.com/

Application GEOPRIV WG Location Civic Location PIDF-LO Civic Address 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&wj;:&wj;lang language tag and restricts the types of elements where appropriate.

Since the publication of the original PIDF-LO civic specification, in , 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 . This document revises the GEOPRIV civic form to include the additional civic parameters captured in . 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.

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 . 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 .

provides a full set of parameters that may be used to describe a civic location. Specifically, lists several civic address types (CAtypes) that require support in the formal PIDF-LO definition that are not in . These changes include new elements that are required to support more complex structures for naming street addresses. This is described in more detail in . New Field CAtype Description Example BLD25Building (structure)Hope Theatre UNIT26Unit (apartment, suite)12a ROOM28Room450F PLC29Place-typeoffice PCN30Postal community nameLeonia POBOX31Post office box (P.O. box)U40 ADDCODE32Additional Code13203000003 SEAT33Seat (desk, cubicle, workstation)WS 181 RD34Primary road or streetBroadway RDSEC35Road section14 RDBR36Road branchLane 7 RDSUBBR37Road sub-branchAlley 8 PRM38Road pre-modifierOld POM39Road post-modifierExtended A complete description of these types is included in .

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 , 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. || | ||

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.

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.

The country element differs from that defined in in that it now restricts the value space of the element to two uppercase characters, which correspond to the alpha-2 codes in .

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 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>

The XML schema defined for civic addresses allows for the addition of the xml&wj;:&wj;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 ; the range of allowed values for PLC is described in the IANA registry defined by . The script field defined in is omitted in favor of using the xml&wj;:&wj;lang attribute with a script subtag . 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.

The DHCP format for civic addresses 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.

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.

The XML schema defined in uses a base type of token instead of string as used in .

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 &#x20;.

<?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>

<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>

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 . Considerations relating to the inclusion of this representation in other XML documents are outside the scope of this document.

This document defines a new XML namespace (as per the guidelines in ) that has been registered with IANA. urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

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

This section registers an XML schema as per the procedures in . urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 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 of this document.

This document updates the civic address type registry established by . The PIDF column of the CAtypes table has been updated to include the types shown in the first column of .

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS TRACK] This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS TRACK] This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS TRACK] International Organization for Standardization International Organization for Standardization This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. Universal Postal Union (UPU)

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.