GEOPRIV J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: June 20, 2011 R. Barnes
BBN Technologies
December 17, 2010
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
Winterbottom, et al. Expires June 20, 2011 [Page 1]
Internet-Draft Civic Extensions December 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 5
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 6
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. CAtype Registration for Extensions . . . . . . . . . . . . 8
5.2. End of Numeric CAtype Registration . . . . . . . . . . . . 8
5.3. Registration Template . . . . . . . . . . . . . . . . . . 8
5.4. Registration Policy and Expert Guidance . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Winterbottom, et al. Expires June 20, 2011 [Page 2]
Internet-Draft Civic Extensions December 2010
1. Introduction
The Geopriv civic location specifications ([RFC4776], [RFC5139])
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].
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].
The XML format for civic addresses [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 [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] or [RFC5139].
1.1. Motivating Example
One instance where translation might be necessary is where a device
receives location configuration using DHCP [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 [RFC4079], and emergency
Winterbottom, et al. Expires June 20, 2011 [Page 3]
Internet-Draft Civic Extensions December 2010
calling [RFC5012].
+--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+
Conversion Scenario
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].
2. Specifying Civic Address Extensions
The civic schema in [RFC5139] 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 [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]. 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".
Winterbottom, et al. Expires June 20, 2011 [Page 4]
Internet-Draft Civic Extensions December 2010
A civic address that includes the new "bridge" element is shown in
Figure 1.
UK
Devon
Monkokehampton
Deckport
Cross
21451338
Figure 1: Extended Civic Address Example
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 [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 [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.
Winterbottom, et al. Expires June 20, 2011 [Page 5]
Internet-Draft Civic Extensions December 2010
3.1. XML to DHCP Format Translation
Extensions to the XML format [RFC5139] are defined in a new XML
namespace [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 ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: XML Civic Address Extension CAtype
The content of a CAtype (after the CAtype code and length) is UTF-8
encoded Unicode text [RFC3629]. 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]
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
Winterbottom, et al. Expires June 20, 2011 [Page 6]
Internet-Draft Civic Extensions December 2010
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:
US
CA
2471
AQ-374-4(c)
LAX
Tom Bradley
G
36B
Figure 3: XML Example with Multiple Extensions
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
Figure 4: Converted DHCP Example with Multiple Extensions
Winterbottom, et al. Expires June 20, 2011 [Page 7]
Internet-Draft Civic Extensions December 2010
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] (DHCP) and [RFC5139] (XML).
5. IANA Considerations
This document alters the "CAtypes" registry established by [RFC4776].
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.
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.
Winterbottom, et al. Expires June 20, 2011 [Page 8]
Internet-Draft Civic Extensions December 2010
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] and [RFC5139] 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].
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]. 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.
Winterbottom, et al. Expires June 20, 2011 [Page 9]
Internet-Draft Civic Extensions December 2010
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816,
August 2006,
.
7.2. Informative References
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4079] Peterson, J., "A Presence Architecture for the
Distribution of GEOPRIV Location Objects", RFC 4079,
July 2005.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
Winterbottom, et al. Expires June 20, 2011 [Page 10]
Internet-Draft Civic Extensions December 2010
[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", BCP 154, RFC 5774, March 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
Authors' Addresses
James Winterbottom
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 242 212938
Email: james.winterbottom@andrew.com
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
Richard Barnes
BBN Technologies
9861 Broken Land Parkway
Columbia, MD 21046
US
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Winterbottom, et al. Expires June 20, 2011 [Page 11]