GEOPRIV J. Winterbottom Internet-Draft M. Thomson Intended status: Standards Track Andrew Corporation Expires: March 10, 2011 R. Barnes BBN Technologies September 6, 2010 Specifying Local Civic Address Fields in PIDF-LO draft-winterbottom-geopriv-local-civic-00 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 March 10, 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 March 10, 2011 [Page 1] Internet-Draft Local Civic September 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 . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Winterbottom, et al. Expires March 10, 2011 [Page 2] Internet-Draft Local Civic September 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 [I-D.ietf-geopriv-http-location-delivery], 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 March 10, 2011 [Page 3] Internet-Draft Local Civic September 2010 UK Devon Monkokehampton/A3> Deckport Cross 21451338 Figure 1: Local Civic Object Alternatively, the local namespace can be included at the top of the document, and just the namespace prefix and element is used later in the structure to define the actual local elements, as shown in Figure 2. UK Devon Monkokehampton/A3> Deckport Cross 21451338 Figure 2: Local Civic Object Early Namespace Declaration 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. Winterbottom, et al. Expires March 10, 2011 [Page 4] Internet-Draft Local Civic September 2010 3.1. Localized Elements Using DHCP In networks that elect to use DHCP to provide civic address information to clients, three new CATypes are defined to address this basic functionality. These CATypes are treated as a triplet of information. The first CAType contains the namespace in which the localized address elements are defined. The second CAType is a label containing the local name of the element in the previously provided namespace. The third CAType contains the value attributed to the specified element. If additional elements are required from the same localized namespace then namespace CAType does not need to be sent a second time, all localized element value pairs will be attributed to the previously provided namespace. For example, the "http://www.central.devon.canals.org/ns1.0" namespace used in the previous example may define a pylonCount for the bridge also, this may be conveyed as shown in Figure 3. ... CAType=XX Value="http://www.central.devon.canals.org/ns1.0" CAType=YY Value="bridge" CAType=ZZ Value="21451338" CAType=YY Value="pylonCount" CAType=ZZ Value="2"... Figure 3: DHCP Example 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 [I-D.ietf-geopriv-http-location-delivery] 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": Local address element containing the value Winterbottom, et al. Expires March 10, 2011 [Page 5] Internet-Draft Local Civic September 2010 ZZ "Value": Value of the local address element [[IANA/RFC-EDITOR: Please replace XX, YY, ZZ 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 [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 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009. [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. Winterbottom, et al. Expires March 10, 2011 [Page 6] Internet-Draft Local Civic 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 March 10, 2011 [Page 7]