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.

Abstract

This document defines an XML format for the representation of civic location. This format is designed for use with PIDF 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 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
2.  Terminology
3.  Changes from PIDF-LO
    3.1.  Additional Civic Address Types
    3.2.  New Thoroughfare Elements
        3.2.1.  Street Numbering
        3.2.2.  Directionals and other Qualifiers
    3.3.  Country Element
    3.4.  A1 Element
    3.5.  Languages and Scripts
        3.5.1.  Converting from the DHCP Format
        3.5.2.  Combining Multiple Elements Based on Language Preferences
    3.6.  Whitespace
4.  Civic Address Schema
5.  Example
6.  Security Considerations
7.  IANA Considerations
    7.1.  URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
    7.2.  XML Schema Registration
    7.3.  CAtype Registry Update
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Since the publication of the original PIDF-LO civic specification, in [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.), 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] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.).

This document revises the GEOPRIV civic form to include the additional civic parameters captured in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.). 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Universal Postal Union (UPU), “International Postal Address Components and Templates,” July 2004.).

3.  Changes from PIDF-LO

3.1.  Additional Civic Address Types

[RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) provides a full set of parameters that may be used to describe a civic location. Specifically [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) lists several civic address types (CAtypes) that require support in the formal PIDF-LO definition that are not in [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.).

These changes include and 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 Thoroughfare Elements).

A complete description of these types is included in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.).

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" 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 interested 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] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.), it MUST NOT be used, the RD element MUST be used for thoroughfare data.

The following example 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 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] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) in that 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] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.).

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] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code,” 1998.) 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 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; 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&wj;:&wj;lang attribute to all elements except country and PLC, which both contain language-neutral values. The range of allowed values for country are defined in [ISO.3166‑1] (International Organization for Standardization, “Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” 1997.); the range of allowed values for PLC are defined in the IANA registry defined by [RFC4589] (Schulzrinne, H. and H. Tschofenig, “Location Types Registry,” July 2006.).

The script field defined in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) is omitted in favour of using the xml&wj;:&wj;lang attribute with a script subtag [RFC4646] (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2006.).

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 (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) [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 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 are conflicting values with the same language.

3.6.  Whitespace

The XML schema [W3C.REC‑xmlschema‑2‑20041028] (Malhotra, A. and P. Biron, “XML Schema Part 2: Datatypes Second Edition,” October 2004.) defined in Section 4 (Civic Address Schema) uses a base type of token instead of string as used in [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.).

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

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] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.). 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 calls for IANA to register a new XML namespace, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.2.  XML Schema Registration

This section registers an XML schema as per the procedures in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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 (Civic Address Schema) of this document.

7.3.  CAtype Registry Update

This document updates the civic address type registry established by [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.). The PIDF column of the CAtypes table has been updated to include the types shown in the first column of Table 1 (New Civic PIDF-LO Types).

8.  References

8.1. Normative References

8.2. Informative References

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

Full Copyright Statement

Copyright © The IETF Trust (2007).

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.