GEOPRIV J. Winterbottom Internet-Draft M. Thomson Updates: 5222 (if approved) CommScope Intended status: Standards Track R. Barnes Expires: April 20, 2012 BBN Technologies B. Rosen NeuStar, Inc. R. George Huawei Technologies October 18, 2011 Specifying Civic Address Extensions in PIDF-LO draft-ietf-geopriv-local-civic-02 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. Intial extensions for some new elements are also defined. The LoST protocol mechanism that returns civic address element names used for validation of location information is clarified to require a namespace on each element. 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 20, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Winterbottom, et al. Expires April 20, 2012 [Page 1] Internet-Draft Civic Extensions October 2011 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11 5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14 8.2. End of Numeric CAtype Registration . . . . . . . . . . . . 14 8.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 14 8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 15 8.5. Registration Template . . . . . . . . . . . . . . . . . . 15 8.6. Registration Policy and Expert Guidance . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Winterbottom, et al. Expires April 20, 2012 [Page 2] Internet-Draft Civic Extensions October 2011 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. A new XML namespace containing a small number of additional civic elements is also defined and can be used as a template to illustrate how other extensions can be defined as required. 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. The existing registry of numeric CAtypes is closed, and a new registry is created that advertises new namespaces and the associated civic elements to encourage maximum reuse. 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]. Winterbottom, et al. Expires April 20, 2012 [Page 3] Internet-Draft Civic Extensions October 2011 This document also normatively updates [RFC5222] to clarify that the namespace must be included with the element name in the lists of valid, invalid and not checked elements in the part of a LoST response. While the LoST schema does not need to be changed, the example in the document is updated to show the namespaces in the lists. 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 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. Winterbottom, et al. Expires April 20, 2012 [Page 4] Internet-Draft Civic Extensions October 2011 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". 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. Winterbottom, et al. Expires April 20, 2012 [Page 5] Internet-Draft Civic Extensions October 2011 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. 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 Winterbottom, et al. Expires April 20, 2012 [Page 6] Internet-Draft Civic Extensions October 2011 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 numeric CAtypes. No new registrations of numeric CAtypes can be made. In lieu of making new numerical CAtype assignments, this document creates a new extensionCA type which is defined in a manner that lets new civic elements be described in DHCP form by carrying the name space and type name of the extension in parameters of the extensionCA type. 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 Winterbottom, et al. Expires April 20, 2012 [Page 7] Internet-Draft Civic Extensions October 2011 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 4. CAtypes Registry [RFC4776] created the CAtype registry. Among other things, this registry advertised available civic elements. While it has always been possible to use an extension namespace to define civic elements that are not in the CAtype registry, and this document does not change that, the registry is valuable to alert implementors of commonly used civic elements and provides guidance to clients of what elements they should suppport. This document creates a new CAtype registry that differs from the original CAtype registry in two ways. The original registry is closed to new numeric CAtypes. The new registry adds a column to the Winterbottom, et al. Expires April 20, 2012 [Page 8] Internet-Draft Civic Extensions October 2011 registry called "Type". "Type" can have one of two values "A" or "B". Type A elements are intended for wide use with many applications and SHOULD be implemented by all clients unless the client is certain the element will not be encountered. Type "B" civic elements MAY be implemented by any client. Type A civic elements require IETF review, while Type B elements only require an expert review. 5. Civic Extensions We use this new extension method to define some additional civic address elements which are needed to correctly encode civic locations in several countries. The definition of these new civic address elements also serves as an example of how to define additional elements using the mechanisms described in this document. 5.1. Pole Number In some areas, utility and lamp posts carry a unique identifier, which we call a pole number in this document. In some countries, the label on the lamp post also carries the local emergency service number, such as "110", encouraging callers to use the pole number to identify their location. Winterbottom, et al. Expires April 20, 2012 [Page 9] Internet-Draft Civic Extensions October 2011 _.-----,===. | | (''''') | | `---' | | | | ,---------, | | ,---, |Emergency| | | /|,-.|----->| Number | | | / |110| '---------' | | / |`-'| |_|/ | 2 | ,---------, | | | 1 | |Lamp Post| | | | 2 |----->| Number | |-| | 1 | '---------' | |\ | 0 | | | \ | 1 | | | \ | 4 | | | \|,,,| _ | | ``-..|.| ``--.._ `'--.._ Figure 5: Lamp post with emergency number 5.2. Mile Post On some roads, and many trails, railroad rights of way and other linear features, a post with a mile or kilometer distance from one end of the feature may be found (a "milepost"). There are other cases of poles or markers with numeric indications that are not the same as a "house number" or street address number. 5.3. Street Type Prefix The civic schema defined in [RFC5139] allows the definition of address "123 Colorado Boulevard", but it does not allow for the easy expression of "123 Boulevard Colorado". Adding a street-type prefix, allows street named in this manner to be more easily represented. 5.4. House Number Prefix The civic schema defined in [RFC5139] provides house number suffix element, allowing one to express an address like "123A Main Street", but it does not contain a corresponding house number prefix. The house number prefix element allows the expression of address such as "Z123 Main Street". Winterbottom, et al. Expires April 20, 2012 [Page 10] Internet-Draft Civic Extensions October 2011 5.5. XML Extension Schema 5.6. Extension examples US CA Sacramento I5 248 22-109-689 XML Example with Post Number and Mile Post Winterbottom, et al. Expires April 20, 2012 [Page 11] Internet-Draft Civic Extensions October 2011 US CA Sacramento Colorado 223 Boulevard A XML Example with Street prefix and House Number Prefix 6. Using Local Civic Extension with the LoST Protocol One critical use of civic location information is in next generation emergency services applications, in particular call routing applications. In such cases location information is provided to a location-based routing service using the location to service transtion (LoST) protcol [RFC5222]. LoST is used to provide call routing information, but it is also used to validate location information to ensure that it can route to an emergency center when required. LoST is an XML-based protocol and so the namespace extension mechansims described in this document do not impact LoST. When LoST is used for validation a element is returned containing a list of valid, a list of invalid, and a list of unchecked civic elements. Figure 6 is an extract of the validation response in Figure 6 from [RFC5222]. country A1 A3 A6 PC HNO Figure 6: Location Validation Example from LoST (RFC5222) The RelaxNG schema in [RFC5222] requires the elements in each of these lists to be namespace qualified, which makes the example in Figure 6 from [RFC5222] in error. This issue is especially significant when local-civic extensions are used as the domain to which the extensions are attributed may impact their interpretation by the server or client. To ensure that local-civic extensions do Winterbottom, et al. Expires April 20, 2012 [Page 12] Internet-Draft Civic Extensions October 2011 not cause issues with LoST server and client implementations, all elements listed in a , , or element MUST be qualified with a namespace. To illustrate this the extract above from figure 6 in [RFC5222] becomes Figure 7. ca:country ca:A1 ca:A3 ca:A6 ca:PC ca:HNO Figure 7: Corrected Location Validation Example If validation request has also included the extensions defined in section Section 5 then the validation would response would look like Figure 8. ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP ca:PC ca:HNO cae:MP cae:HNP Figure 8: Corrected Location Validation Example 7. 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). 8. IANA Considerations This document replaces the "CAtypes" registry established by [RFC4776]. Winterbottom, et al. Expires April 20, 2012 [Page 13] Internet-Draft Civic Extensions October 2011 8.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]] 8.2. End of Numeric CAtype Registration No further registration of numeric CAtypes is permitted, and the registry created as part of [RFC4776] replaced with the registry defined in this document. New registrations use the registration template in Section 8.5. 8.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' This document calls for IANA to register a new XML namespace, 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@commscope.com). XML: BEGIN GEOPRIV Civic Address Extensions

Additional Fields for GEOPRIV Civic Address

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 20, 2012 [Page 14] Internet-Draft Civic Extensions October 2011 8.4. XML Schema Registration This section registers an XML schema as per the procedures in [RFC3688]. URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.Winterbottom@commscope.com). The XML for this schema can be found as the entirety of Section 5.5 of this document. 8.5. 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. 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. Type: If Type is "A", all clients SHOULD implement this element. If Type is "B", clients MAY implement this element. Registrations from [RFC4776] and [RFC5139] are registered with the following form: Winterbottom, et al. Expires April 20, 2012 [Page 15] Internet-Draft Civic Extensions October 2011 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 Type: A Registration of the schema defined in this document in Section 5.5. CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor: update XX] Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Local Name: PN, MP, STP, HNP Description: PN: Post number that is attributed to a lamp post or utility pole. Description: MP: Mile Post a marker indicating distance to or from a place (often a town). Description: STP: Street Type Prefix. Description: HNP: House Number Prefix. Contact: The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org). Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]] Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Winterbottom, et al. Expires April 20, 2012 [Page 16] Internet-Draft Civic Extensions October 2011 Type: A 8.6. Registration Policy and Expert Guidance The "CAtypes" registry will operate on a registration policy of "Expert Review", and optionally "Specification Required" [RFC5226] if the element being registered has a Type value of "B". 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. If the element being registered has a Type value of "A" then the registration policy is "IETF Review". 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. 9. Acknowledgements Thanks to anyone who has tried to extend the civic schema and found it a little unintuitive. 10. References 10.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. Winterbottom, et al. Expires April 20, 2012 [Page 17] Internet-Draft Civic Extensions October 2011 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 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, . 10.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. [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. Winterbottom, et al. Expires April 20, 2012 [Page 18] Internet-Draft Civic Extensions October 2011 Authors' Addresses James Winterbottom CommScope Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU Phone: +61 242 212938 Email: james.winterbottom@commscope.com Martin Thomson CommScope Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU Phone: +61 2 4221 2915 Email: martin.thomson@commscope.com Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169 Email: rbarnes@bbn.com Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US Email: br@brianrosen.net Winterbottom, et al. Expires April 20, 2012 [Page 19] Internet-Draft Civic Extensions October 2011 Robins George Huawei Technologies Huawei Base, Bantian, Longgan District Shenzhen, Guangdong 518129 P. R. China Phone: +86 755 2878 8314 Email: robinsg@huawei.com Winterbottom, et al. Expires April 20, 2012 [Page 20]