[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-geopriv-local-civic

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/