Specifying Local Civic Address Fields in PIDF-LO
draft-winterbottom-geopriv-local-civic-01

Abstract

This document describes how to specify local civic elements in the Geopriv civic schema maintaining backward compatibility with existing specifications and implementations. Support for providing local civic elements over DHCP is also described.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on April 16, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Specifying Local Civic Elements
    3.1.  Localized Elements Using DHCP
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Geopriv civic location specification [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) defines an XML schema that are intended to allow the expression of civic location in most countries. It was recognized that some countries may require a profile or guidance on how to specify local addresses using the elements defined in [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) and so [RFC5774] (Wolf, K. and A. Mayrhofer, “Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition,” March 2010.) was produced to provide this function. Subsequent to these specifications being produced, a number of individual contributions have been made trying to add additional civic elements to address local jurisdictional requirements. These contributions were specified in such a away that broke backward compatibility for protocols, equipment, and other standards already using the [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) specification.

This document defines a method that allows the specification of local civic address elements inside a [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) object. It further allows these local civic elements to be carried over DHCP using [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.), HELD [RFC5985] (Barnes, M., “HTTP-Enabled Location Delivery (HELD),” September 2010.), and LoST [RFC5222] (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.) without modification and so maintain backward compatibility with existing specifications and implementations.

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

3.  Specifying Local Civic Elements

The civic schema in [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) defines an ordered structure of elements that can be combined to describe a street address. The XML extension point at the bottom of the schema is used to include address elements of local significance into the main civic body.

For example, suppose the Central Devon Canals authority wishes to introduce a new civic element called "bridge". The authority must define an XML namespace and define the "bridge" element within that namespace. The namespace needs to be a URI and needs to be unique, for example "http://www.central.devon.canals.org/ns1.0". Finally, the authority can create a civic address that includes the new "bridge" element at the bottom.

   <civicAddress xml:lang="en-AU"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:cdc="http://www.central.devon.canals.org/ns1.0">
     <country>UK</country>
     <A1>Devon</A1>
     <A3>Monkokehampton/A3>
     <RD>Deckport</RD>
     <STS>Cross</STS>

     <cdc:bridge>21451338</cdc:bridge>

   </civicAddress>

Nodes that receive the location information but don't understand the locally specified address elements can safely ignore them, yet still interpret the main civic elements from [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) and so maintain backward compatibility. Where the information is passed to local applications, such as a LoST server for emergency call routing, the significance of the localized elements can be safely applied. This allows localized address elements to be included in a location response from a LIS using HELD without modification being required to the HELD protocol or the HELD client on the device.

3.1.  Localized Elements Using DHCP

In networks that elect to use DHCP to provide civic address information to clients, two new CATypes are defined to address this basic functionality, and no further CATypes will be allocated by IANA.

The "Namespace" CAType provides the definition of an XML namespace and a corresponding namespace prefix. This CAType is sent multiple times if elements from multiple namespaces are required.

The "Element" CAType conveys a single namespace element and its value. The element name is qualified with a namespace prefix that is provided using a Namespace CAType. If no corresponding Namespace CAType is received that defines the namespace prefix in an Element CAType, then the Element CAType MUST be ignored.

To aid in client parsing and reduce the likelihood of server configuration errors, it is RECOMMENDED that all Namespace CATypes proceed any Element CATypes in the response from the server to the client.

   ...
   CAType=XX Value="xmlns:cdc=http://www.central.devon.canals.org/ns1.0"
   CAType=XX value="xmlns:ap="http://www.example.com/airport/5.0"
   CAType=YY Value="<cdc:bridge>21451338</cdc:bridge>"
   CAType=YY Value="<cdc:pylonCount>2</cdcpyloncount>"
   CAType=YY value="<ap:airport>LAX</ap:airport>"
   CAType=YY value="<ap:terminal>Tom Bradley</ap:terminal>"
   CAType=YY value="<ap:concourse>G</ap:concourse>"
   CAType=YY value="<ap:gate>36B</ap:gate>"

4.  Security Considerations

This document defines a formal way to extend the existing Geopriv civic schema. No security threats are introduced by this document. Security threats applicable to configuring a device with a civic address using DHCP are specified in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.). Security threats applicable to providing a device with its civic location using HELD are specific in [RFC5985] (Barnes, M., “HTTP-Enabled Location Delivery (HELD),” September 2010.)

5.  IANA Considerations

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.). Three additional value are added:

XX "Namespace":

Namespace in which the local address elements are defined

YY "Element":

qualified local address element and value value

Further this document terminates the addition of CATypes that proposed future specification may attempt to define. Required civic elements not defined in the [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) MUST only be provided using the mechanism described in this document.

[[IANA/RFC-EDITOR: Please replace XX and YY with the allocated civic address type number assigned from the pool]]

6.  Acknowledgements

Thanks to Brian Rosen, Delaine Arnold, Robins George, and anyone else who has tried to extend the civic schema and found it a little unintuative

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses