GEOPRIV J. Winterbottom Internet-Draft M. Thomson Intended status: Standards Track Andrew Corporation Expires: April 25, 2011 R. Barnes BBN Technologies October 22, 2010 Specifying Local Civic Address Fields in PIDF-LO draft-winterbottom-geopriv-local-civic-03 Abstract A backwardly-compatible mechanism for adding locally significant 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 April 25, 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 Winterbottom, et al. Expires April 25, 2011 [Page 1] Internet-Draft Local Civic October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specifying Local Civic Elements . . . . . . . . . . . . . . . 4 4. Translating Unsupported Elements . . . . . . . . . . . . . . . 5 4.1. DHCP to XML Format Translation . . . . . . . . . . . . . . 5 4.2. XML to DHCP Format Translation . . . . . . . . . . . . . . 5 4.2.1. Namespace CAtype . . . . . . . . . . . . . . . . . . . 6 4.2.2. Element CAtype . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Conversion Constraints . . . . . . . . . . . . . . . . 6 4.2.4. Conversion Example . . . . . . . . . . . . . . . . . . 7 4.2.5. Migration to Registered Elements . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. CAtype Registration . . . . . . . . . . . . . . . . . . . 8 6.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 9 6.3. XML Schema Registration . . . . . . . . . . . . . . . . . 10 7. Unsupported Extension XML Schema . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Identifying EXT Elements in LoST Validation . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Winterbottom, et al. Expires April 25, 2011 [Page 2] Internet-Draft Local Civic October 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 in most countries. 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 locally significant civic address elements have emerged. These elements do not all readily fit existing elements, as recommended in [RFC5774]. These elements are also sufficiently domain-specific that they do not merit additions to the limited space available for globally recognized elements. 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 than to ignore elements that it does not understand. Where a recipient performs a translation between the two formats, this results in the unsupported elements being discarded. In order for a new extension to be useful to a recipient that performs translation, the recipient has to understand the extension and know how to correlate an XML element with a CAtype. This document defines a method that allows the specification of civic address elements with private or local significance. How these are defined and used in both XML and DHCP formats is described. This document also describes how a recipient can translate unsupported civic addresses between the two formats. The additions described in this document are backwardly compatible. Furthermore, they allow for a civic address to be translated without loss of information. 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]. Winterbottom, et al. Expires April 25, 2011 [Page 3] Internet-Draft Local Civic October 2010 3. Specifying Local Civic Elements 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 bottom of the schema is used to include address elements of local significance into the main civic body. 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. 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. UK Devon Monkokehampton Deckport Cross 21451338 Figure 1: Local Civic Object Example An entity that receives this location information might not understand the locally specified 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. Winterbottom, et al. Expires April 25, 2011 [Page 4] Internet-Draft Local Civic October 2010 4. 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. 4.1. DHCP to XML Format Translation The registration of a new CAtype following the process in [RFC4776] means that a recipient is potentially unable to produce a complete XML representation of the DHCP civic address. To address this, a new "EXT" XML element is defined that allows the XML format to carry an unsupported CAtype without modification. This type extends the base civic address element type by adding a "CAtype" attribute that identifies the CAtype. For example, if CAtype 199 is defined, but not understood, this is carried in the XML format as shown in Figure 2. UK Devon Monkokehampton Deckport Cross 21451338 Figure 2: XML Civic Address with Unsupported Extension No facility is provided for the conversion of private or local use CAtypes when translating from DHCP to XML. Extensions for private or local use do not use new CAtypes. Private or local use extensions MUST be defined using the XML extension mechanism. 4.2. XML to DHCP Format Translation Extensions to the XML format are defined in a new XML namespace. Extensions that have global applicability might have a specific CAtype allocated. Extensions that are only for private or local use Winterbottom, et al. Expires April 25, 2011 [Page 5] Internet-Draft Local Civic October 2010 have no corresponding CAtype and always use this translation mechanism. Unsupported extensions in the XML format can be added to a DHCP format civic address using two new elements: the Namespace CAtype and the Element CAtype. 4.2.1. Namespace CAtype The "Namespace" CAtype (CAtype XX [IANA/RFC-Editor: please use assigned value]) provides the definition of an XML namespace and a corresponding namespace prefix. This is analogous to attributes beginning with "xmlns" in [XMLNS]. The Abstract Backus-Naur Form (ABNF) [RFC5234] for this CAtype uses a Unicode character as the basic element and borrows BNF definitions from [XMLNS]: ns-CAtype = Prefix "=" *UCHAR UCHAR = The Namespace CAtype is sent multiple times if elements from multiple namespaces are required. 4.2.2. Element CAtype The "Element" CAtype (CAtype YY [IANA/RFC-Editor: please use assigned value]) conveys a single element and its value. The element name includes a namespace prefix, as bound by the "Namespace" CAtype, plus the local name from the corresponding XML element. This is followed by the value of the element. Prefix and local name are separated by a colon (":") as in [XMLNS]; element name and value are separated by an equals sign ("="). The Abstract Backus-Naur Form (ABNF) [RFC5234] for this CAtype uses a Unicode character as the basic element and borrows BNF definitions for "Prefix" and "LocalPart" from [XMLNS]: element-CAtype = Prefix ":" LocalPart "=" *UCHAR An Element CAtype that includes a prefix that has not been bound in a Namespace CAtype is ignored. 4.2.3. Conversion Constraints 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 Winterbottom, et al. Expires April 25, 2011 [Page 6] Internet-Draft Local Civic October 2010 they are not understood. A Namespace CAtype MUST precede the Element CAtype that uses the binding it defines. A Namespace CAtype MUST NOT reuse a prefix. To aid in client parsing and reduce the likelihood of server configuration errors, all Namespace CAtypes SHOULD proceed any Element CAtypes. 4.2.4. Conversion Example The following example civic address contains two private use extensions: US CA 2471 AQ-374-4(c) LAX Tom Bradley G 36B Figure 3: XML Example with Multiple Extensions Might be converted to the DHCP form as follows: country = US CAtype[0] = en-US CAtype[1] = CA CAtype[XX] = post=http://postsoftheworld.net/ns/posts CAtype[XX] = ap=http://www.example.com/airport/5.0 CAtype[YY] = post:lamp=2471 CAtype[YY] = post:pylon=AQ-374-4(c) CAtype[YY] = ap:airport=LAX CAtype[YY] = ap:terminal=Tom Bradley CAtype[YY] = ap:concourse=G CAtype[YY] = ap:gate=36B Figure 4: Converted DHCP Example with Multiple Extensions Winterbottom, et al. Expires April 25, 2011 [Page 7] Internet-Draft Local Civic October 2010 4.2.5. Migration to Registered Elements An element that is initially added as a local extension might be recognized as being more widely applicable. In this case, a CAtype might be allocated for this extension. Depending on whether a client is aware of the CAtype allocation, they could convert the XML form differently. A recipient that understands a CAtype MUST treat the extended form as being semantically equivalent. For example, if the bridge element from the examples in Figure 1 and Figure 2 is allocated a CAtype of 199, a recipient treats all of the four following forms as equivalent: 21451338 21451338 CAtype[XX] = canal=http://devon.canals.org.uk/civic CAtype[YY] = canal:bridge=21451338 CAtype[199] = 21451338 5. 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 the civic address formats are described in [RFC4776] (DHCP) and [RFC5139] (XML). 6. IANA Considerations Two civic address types are registered for the DHCP format. An XML namespace and schema are registered for the XML format in accordance with guidelines in [RFC3688]. 6.1. CAtype Registration This document registers two civic address types in the "CAtypes" registry established by [RFC4776]. The following CAtypes are added: Winterbottom, et al. Expires April 25, 2011 [Page 8] Internet-Draft Local Civic October 2010 +--------+------+------+-------------------+------------------------+ | CAtype | NENA | PIDF | Description | Example | +--------+------+------+-------------------+------------------------+ | XX | - | - | Namespace binding | ex=http://example.com/ | | YY | - | EXT | Qualified address | ex:ext=value | | | | | element name and | | | | | | value | | +--------+------+------+-------------------+------------------------+ [[IANA/RFC-EDITOR: Please replace XX and YY with the allocated CAtype]] 6.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id This section registers a new XML namespace, "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext", as per the guidelines in [RFC3688]. urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com). BEGIN Unsupported Civic Address Extension

Namespace for Unsupported Civic Address Extension

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

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END Winterbottom, et al. Expires April 25, 2011 [Page 9] Internet-Draft Local Civic October 2010 6.3. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com). Schema: The XML for this schema can be found as the entirety of Section 7 of this document. 7. Unsupported Extension XML Schema Winterbottom, et al. Expires April 25, 2011 [Page 10] Internet-Draft Local Civic October 2010 8. 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [XML] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 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, . 9.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 Winterbottom, et al. Expires April 25, 2011 [Page 11] Internet-Draft Local Civic October 2010 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. Appendix A. Identifying EXT Elements in LoST Validation LoST [RFC5222] uses the name of civic address elements to identify them when validating the content of an address. An "EXT" element can appear multiple times, each one with a different "CAtype" attribute to distinguish it. In this case, a LoST response is unable to distinguish between one "EXT" element and another. In order to identify a specific "EXT" element, the CAtype is also needed. To deal with this problem, a set of pseudo-elements are defined. These pseudo-elements exist in the "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" namespace, like the "EXT" element, but are not defined in the corresponding schema. The local name of each of these elements is formed from the string "CAtype" plus the decimal value of the "CAtype" attribute. This pseudo-element name is included in addition to the "EXT" element name. For instance, a civic address might contain the following "EXT" elements: 21451338 Rubbish These can be identified in a LoST response as follows: ext:EXT ext:CAtype199 ext:EXT ext:CAtype231 Winterbottom, et al. Expires April 25, 2011 [Page 12] Internet-Draft Local Civic October 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 April 25, 2011 [Page 13]