GEOPRIV J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: April 16, 2011 R. Barnes
BBN Technologies
October 13, 2010
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
Winterbottom, et al. Expires April 16, 2011 [Page 1]
Internet-Draft Local Civic October 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specifying Local Civic Elements . . . . . . . . . . . . . . . . 3
3.1. Localized Elements Using DHCP . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Winterbottom, et al. Expires April 16, 2011 [Page 2]
Internet-Draft Local Civic October 2010
1. Introduction
The Geopriv civic location specification [RFC5139] 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] and so [RFC5774] 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] specification.
This document defines a method that allows the specification of local
civic address elements inside a [RFC5139] object. It further allows
these local civic elements to be carried over DHCP using [RFC4776],
HELD [RFC5985], and LoST [RFC5222] 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].
3. Specifying Local Civic Elements
The civic schema in [RFC5139] 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.
Winterbottom, et al. Expires April 16, 2011 [Page 3]
Internet-Draft Local Civic October 2010
<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>
Figure 1: Local Civic Object Example
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] 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.
Winterbottom, et al. Expires April 16, 2011 [Page 4]
Internet-Draft Local Civic October 2010
...
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>"
Figure 2: DHCP Example Conveying Muiptle Namespace Elements
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]. Security threats
applicable to providing a device with its civic location using HELD
are specific in [RFC5985]
5. IANA Considerations
This document updates the civic address type registry established by
[RFC4776]. 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] 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
Winterbottom, et al. Expires April 16, 2011 [Page 5]
Internet-Draft Local Civic October 2010
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.
7.2. Informative References
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[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
Winterbottom, et al. Expires April 16, 2011 [Page 6]
Internet-Draft Local Civic October 2010
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 April 16, 2011 [Page 7]