Specifying Civic Address Extensions in PIDF-LO
draft-winterbottom-geopriv-local-civic-04

Abstract

New fields are occasionally added to civic addresses. A backwardly-compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation.

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 June 20, 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
    1.1.  Motivating Example
    1.2.  Terminology
2.  Specifying Civic Address Extensions
3.  Translating Unsupported Elements
    3.1.  XML to DHCP Format Translation
    3.2.  Extension Civic Address Type (CAtype)
    3.3.  DHCP to XML Format Translation
    3.4.  Conversion Example
4.  Security Considerations
5.  IANA Considerations
    5.1.  CAtype Registration for Extensions
    5.2.  End of Numeric CAtype Registration
    5.3.  Registration Template
    5.4.  Registration Policy and Expert Guidance
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Geopriv civic location specifications ([RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.), [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.)) define an XML and binary representtations for civic addresses that allow for the expression of civic addresses. Guidance for the use of these formats for the civic addresses in different countries is included in [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.).

Subsequent to these specifications being produced, use cases for extending the civic address format with new elements have emerged. Extension elements do not readily fit existing elements, as recommended in [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.).

The XML format for civic addresses (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139] provides a mechanism that allows for the addition of standardized or privately understood elements. A similar facility for private extension is not provided for the DHCP format (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) [RFC4776], though new specifications are able to define new CAtypes (civic address types).

A recipient of a civic address in either format currently has no option other than to ignore elements that it does not understand. This results in any elements that are unknown to that recipient being discarded if a recipient performs a translation between the two formats. In order for a new extension to be preserved through translation by any recipient, the recipient has to understand the extension and know how to correlate an XML element with a CAtype.

This document describes how new civic address elements are added. Extension always starts with the definition of XML elements. A mechanism for carrying the extension in the DHCP format is described.

These mechanisms ensure that any translation between formats can be performed consistently and without loss of information. Translation between formats can occur without knowledge of every extension that is present.

These additions described in this document are backwardly compatible. Existing implementations may cause extension information to be lost, but the presence of extensions does not affect an implementation that conforms to either [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) or [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.).

1.1.  Motivating Example

One instance where translation might be necessary is where a device receives location configuration using DHCP (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) [RFC4776]. Conversion of DHCP information to an XML form is necessary if the device wishes to use the DHCP-provided information in a range of applications, including location-based presence services (Peterson, J., “A Presence Architecture for the Distribution of GEOPRIV Location Objects,” July 2005.) [RFC4079], and emergency calling (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” January 2008.) [RFC5012].

 +--------+          +--------+         +-----------+
 | DHCP   |   DHCP   | Device |   XML   | Recipient | e.g., Presence
 | Server |--------->|        |-------->|           |       Agent
 +--------+          +--------+         +-----------+

The Device that performs the translation between the DHCP and XML formats might not be aware of some of the extensions that are in use. Without knowledge of these extensions and how they are represented in XML, the Device is forced to discard them.

These extensions could be useful - or critical - to the ultimate consumers of this information. For instance, an extension element might provide a presence watcher with important information in locating the Device or an extension might be significant in choosing a particular call route.

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

2.  Specifying Civic Address Extensions

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 civic address. The XML extension point at the end of this sequence is used to extend the address.

New elements are defined in a new XML namespace (Hollander, D., Layman, A., Tobin, R., and T. Bray, “Namespaces in XML 1.1 (Second Edition),” August 2006.) [XMLNS]. This is true of address elements with significance within private or localized domains, as well as those that are intended for global applicability.

New elements SHOULD use the basic caType schema type defined in [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.). This type provides an optional xml:lang attribute.

For example, suppose the (fictitious) Central Devon Canals Authority wishes to introduce a new civic element called "bridge". The authority defines an XML namespace that includes a "bridge" element. The namespace needs to be a unique URI, for example http://devon.canals.org.uk/civic.

A civic address that includes the new "bridge" element is shown in Figure 1 (Extended Civic Address Example).

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

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

   </civicAddress>

An entity that receives this location information might not understand the extension address element. As long as the added element is able to be safely ignored, the remainder of the civic address can be used. The result is that the information is not as useful as it could be, but the added element does not prevent the use of the remainder of the address.

The address can be passed to other applications, such as a LoST server (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.) [RFC5222], without modification. If the application understands the added elements, it is able to make use of that information. For example, if this civic address is acquired using HELD (Barnes, M., “HTTP-Enabled Location Delivery (HELD),” September 2010.) [RFC5985], it can be included in a LoST request directly.

3.  Translating Unsupported Elements

Unsupported civic address elements can be carried without consequence only as long as the format of the address does not change. When converting between the XML and DHCP formats, these unsupported elements are necessarily discarded: the entity performing the translation has no way to know the correct element to use in the target format.

All extensions MUST be defined using the mechanism described in this document. Extensions that use numeric CAtypes or other mechanisms cannot be safely translated between XML and DHCP representations.

An entity that does not support these extension mechanisms is expected to remove elements it doesn't understand when performing conversions.

3.1.  XML to DHCP Format Translation

Extensions to the XML format (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139] are defined in a new XML namespace (Hollander, D., Layman, A., Tobin, R., and T. Bray, “Namespaces in XML 1.1 (Second Edition),” August 2006.) [XMLNS].

Extensions in the XML format can be added to a DHCP format civic address using an extension CAtype.

3.2.  Extension Civic Address Type (CAtype)

The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: please replace XX here and in the figure below with the assigned code] includes three values that uniquely identify the XML extension and its value: a namespace URI, the local name of the XML element, and the text content of that element. These three values are all included in the value of the CAtype, each separated by a single whitespace character.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  CAtype (XX)  |   Length      |  Namespace URI ...            .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                  Namespace URI (continued) ...                .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Space (U+20) |           XML element local name ...          .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Space (U+20) |           Extension type value  ...           .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). A maximum of 255 octets is allowed. Octets consumed by the namespace URI and local name reduce the space available for values.

This conversion only works for elements that have textual content and an optional xml:lang attribute. Elements with complex content or other attributes - aside from namespace bindings - MUST be ignored if they are not understood.

3.3.  DHCP to XML Format Translation

The registration of a new CAtype following the process in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) means that a recipient that does not know the equivalent XML is unable to produce a complete XML representation of the DHCP civic address. For this reason, this document ends the registration of new numeric CAtypes. No new registrations of numeric CAtypes can be made.

Extension for the DHCP civic address format is performed by first describing an XML extension. This extension is then carried in the DHCP form in an extension CAtype.

When converting to XML, the namespace prefix used for the extension element is selected by the entity that performs the conversion.

3.4.  Conversion Example

The following example civic address contains two extensions:

   <civicAddress xml:lang="en-US"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:post="http://postsoftheworld.net/ns"
        xmlns:ap="http://example.com/airport/5.0">
     <country>US</country>
     <A1>CA</A1>

     <post:lamp>2471</post:lamp>
     <post:pylon>AQ-374-4(c)</post:pylon>

     <ap:airport>LAX</ap:airport>
     <ap:terminal>Tom Bradley</ap:terminal>
     <ap:concourse>G</ap:concourse>
     <ap:gate>36B</ap:gate>
   </civicAddress>

This is converted to a DHCP form as follows:

   country     = US
   CAtype[0]   = en-US
   CAtype[1]   = CA
   CAtype[XX]  = http://postsoftheworld.net/ns lamp 2471
   CAtype[XX]  = http://postsoftheworld.net/ns lamp AQ-374-4(c)
   CAtype[XX]  = http://example.com/airport/5.0 airport LAX
   CAtype[XX]  = http://example.com/airport/5.0 terminal Tom Bradley
   CAtype[XX]  = http://example.com/airport/5.0 concourse G
   CAtype[XX]  = http://example.com/airport/5.0 gate 36B

4.  Security Considerations

This document defines a formal way to extend the existing Geopriv civic address schema. No security threats are introduced by this document.

Security threats applicable to the civic address formats are described in [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) (DHCP) and [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) (XML).

5.  IANA Considerations

This document alters the "CAtypes" registry established by [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.).

5.1.  CAtype Registration for Extensions

IANA has allocated a CAtype code of XX for the extension CAtype.

[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]

5.2.  End of Numeric CAtype Registration

No further registration of numeric CAtypes is permitted. New registrations in this registry use the registration template in Section 5.3 (Registration Template).

5.3.  Registration Template

New registrations in the "CAtypes" registry require the following information:

CAtype:

The assigned numeric CAtype. All new registrations use the value XX. [[IANA/RFC-Editor: update XX] Existing registrations use their assigned value.

Namespace URI:

A unique identifier for the XML namespace used for the extension element.

Local Name:

The local name of an XML element that carries the civic address element.

Description:

A brief description of the semantics of the civic address element.

(Optional) Example:

One or more simple examples of the element.

Contact:

Contact details for the person providing the extension.

(Optional) Specification:

A reference to a specification for the civic address element.

(Optional) Schema:

A reference to a formal schema (XML schema, RelaxNG, or other form) that defines the extension.

Registrations from [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) and [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) are registered with the following form:

CAtype:

(The existing CAtype.)

Namespace URI:

urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr

Local Name:

(The contents of the PIDF column.)

Description:

(The existing description for the element, including a note about the equivalent NENA field, if present.)

Contact:

The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org).

Specification:

RFC4776 and RFC5139

Schema:

urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr

5.4.  Registration Policy and Expert Guidance

The "CAtypes" registry is altered to operate on a registration policy of "Expert Review", and optionally "Specification Required" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).

The registration rules for "Specification Required" are followed only if a registration includes a reference to a specification. Registrations can be made without a specification reference.

All registrations are reviewed to identify potential duplication between registered elements. Duplicated semantics are not prohibited in the registry, though it is preferred if existing elements are used. The expert review is advised to recommend the use of existing elements following the guidance in [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.). Any registration that is a duplicate or could be considered a close match for the semantics of an existing element SHOULD include a discussion of the reasons that the existing element was not reused.

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

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses