<pre>Internet Engineering Task Force (IETF)                   J. Winterbottom
Request for Comments: 6848                                     CommScope
Updates: <a href="./rfc4776">4776</a>, <a href="./rfc5222">5222</a>                                           M. Thomson
Category: Standards Track                                          Skype
ISSN: 2070-1721                                                R. Barnes
                                                        BBN Technologies
                                                                B. Rosen
                                                           NeuStar, Inc.
                                                               R. George
                                                     Huawei Technologies
                                                            January 2013


                 <span class="h1">Specifying Civic Address Extensions in</span>
     <span class="h1">the Presence Information Data Format Location Object (PIDF-LO)</span>

Abstract

   New fields are occasionally added to civic addresses.  A backward-
   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.  Initial extensions for some new elements are also
   defined.  The Location-to-Service Translation (LoST) protocol
   mechanism (defined in <a href="./rfc5222">RFC 5222</a>) that returns civic address element
   names used for validation of location information is clarified and is
   normatively updated to require a qualifying namespace identifier on
   each civic address element returned as part of the validation
   process.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6848">http://www.rfc-editor.org/info/rfc6848</a>.







<span class="grey">Winterbottom, et al.         Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-3">3</a>
     <a href="#section-1.1">1.1</a>.  Motivating Example . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.2">1.2</a>.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-2">2</a>.  Specifying Civic Address Extensions  . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-3">3</a>.  Translating Unsupported Elements . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
     <a href="#section-3.1">3.1</a>.  XML to DHCP Format Translation . . . . . . . . . . . . . .  <a href="#page-6">6</a>
     <a href="#section-3.2">3.2</a>.  Extension Civic Address Type (CAtype)  . . . . . . . . . .  <a href="#page-6">6</a>
     <a href="#section-3.3">3.3</a>.  DHCP to XML Format Translation . . . . . . . . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-3.4">3.4</a>.  Conversion Example . . . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
   <a href="#section-4">4</a>.  CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
   <a href="#section-5">5</a>.  Civic Extensions . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-5.1">5.1</a>.  Pole Number  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-5.2">5.2</a>.  Milepost . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-5.3">5.3</a>.  Street Type Prefix . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-5.4">5.4</a>.  House Number Prefix  . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-5.5">5.5</a>.  XML Extension Schema . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
     <a href="#section-5.6">5.6</a>.  Extension Examples . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
   <a href="#section-6">6</a>.  Using Local Civic Extension with the LoST Protocol . . . . . . <a href="#page-12">12</a>
   <a href="#section-7">7</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
   <a href="#section-8">8</a>.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
     <a href="#section-8.1">8.1</a>.  CAtype Registration for Extensions . . . . . . . . . . . . <a href="#page-13">13</a>
     <a href="#section-8.2">8.2</a>.  Changes to the CAtype Registry . . . . . . . . . . . . . . <a href="#page-14">14</a>
     <a href="#section-8.3">8.3</a>.  Registration Template  . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
     <a href="#section-8.4">8.4</a>.  Registration of the CAtypes Defined in this Document . . . <a href="#page-15">15</a>
     <a href="#section-8.5">8.5</a>.  Registration Policy and Expert Guidance  . . . . . . . . . <a href="#page-16">16</a>
     <a href="#section-8.6">8.6</a>.  URN Sub-Namespace Registration . . . . . . . . . . . . . . <a href="#page-17">17</a>
     <a href="#section-8.7">8.7</a>.  XML Schema Registration  . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
   <a href="#section-9">9</a>.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
   <a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>



<span class="grey">Winterbottom, et al.         Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Geopriv civic location specifications ([<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>], [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>])
   define an XML and binary representations 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 [<a href="./rfc5774" title="&quot;Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition&quot;">RFC5774</a>].

   Subsequent to these specifications being produced, use cases for
   extending the civic address format with new elements have emerged.
   [<a href="./rfc5774" title="&quot;Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition&quot;">RFC5774</a>] describes a mechanism for mapping long-standing address
   formats into the civic address elements defined in [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>] and
   [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>].  However, some of these existing address elements do not
   readily fit into the civic address elements defined in [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>] and
   [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>].  In these cases, creating new civic address elements
   provides a better solution than overloading existing civic address
   fields, which may cause confusion.

   The XML format for civic addresses [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] 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 [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>], 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.
   Extensions always start 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 registry of numeric CAtypes is modified so that the creators of
   extensions can advertise new namespaces and civic elements to
   encourage maximum reuse.




<span class="grey">Winterbottom, et al.         Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   The 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 [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>] or [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>].

   This document also normatively updates [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>] to clarify that the
   namespace must be included with the element name in the lists of
   valid, invalid, and not checked elements in the &lt;locationValidation&gt;
   part of a Location-to-Service Translation (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.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Motivating Example</span>

   One instance where translation might be necessary is where a device
   receives location configuration using DHCP [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>].  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 [<a href="./rfc4079" title="&quot;A Presence Architecture for the Distribution of GEOPRIV Location Objects&quot;">RFC4079</a>] and emergency
   calling [<a href="./rfc5012" title="&quot;Requirements for Emergency Context Resolution with Internet Technologies&quot;">RFC5012</a>].

    +--------+          +--------+         +-----------+
    | DHCP   |   DHCP   | Device |   XML   | Recipient | e.g., Presence
    | Server |---------&gt;|        |--------&gt;|           |       Agent
    +--------+          +--------+         +-----------+

                       Figure 1: 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 may be 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.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].







<span class="grey">Winterbottom, et al.         Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Specifying Civic Address Extensions</span>

   The civic schema in [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] 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.

   New elements are defined in a new XML namespace [<a href="#ref-XMLNS" title="&quot;Namespaces in XML 1.1 (Second Edition)&quot;">XMLNS</a>].  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
   [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>].  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
   "<a href="http://devon.canals.example.com/civic">http://devon.canals.example.com/civic</a>".

   A civic address that includes the new "bridge" element is shown in
   Figure 2.

      &lt;civicAddress xml:lang="en-GB"
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
           xmlns:cdc="http://devon.canals.example.com/civic"&gt;
        &lt;country&gt;UK&lt;/country&gt;
        &lt;A1&gt;Devon&lt;/A1&gt;
        &lt;A3&gt;Monkokehampton&lt;/A3&gt;
        &lt;RD&gt;Deckport&lt;/RD&gt;
        &lt;STS&gt;Cross&lt;/STS&gt;

        &lt;cdc:bridge&gt;21451338&lt;/cdc:bridge&gt;

      &lt;/civicAddress&gt;

                 Figure 2: 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 [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>], without modification.  If the application



<span class="grey">Winterbottom, et al.         Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   understands the added element(s), it is able to make use of that
   information.  For example, if this civic address is acquired using
   HTTP-Enabled Location Delivery (HELD) [<a href="./rfc5985" title="&quot;HTTP-Enabled Location Delivery (HELD)&quot;">RFC5985</a>], it can be included
   in a LoST request directly.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Translating Unsupported Elements</span>

   Unsupported civic address elements can be carried without consequence
   as long as the format of the address does not change.  However,
   conversion between formats has been shown to be necessary.

   Format conversion requires knowledge of the format of the address
   elements.  An entity performing a conversion between XML and DHCP
   address formats is forced to discard unrecognized elements.  The
   entity performing the conversion has no way to know the correct
   element to use in the target format.

   This document defines a single extension element for the DHCP format
   that makes knowledge of extensions unnecessary during conversion.
   This extension element relies on the extension mechanisms defined for
   the XML format.  New extensions to the civic address format MUST be
   defined only for the XML format; these extensions are then conveyed
   in DHCP using the extension element.

   Further extensions to the DHCP format are prohibited; these
   extensions cannot be safely conveyed in environments where conversion
   is possible.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  XML to DHCP Format Translation</span>

   Extensions to the XML format [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] are defined in a new XML
   namespace [<a href="#ref-XMLNS" title="&quot;Namespaces in XML 1.1 (Second Edition)&quot;">XMLNS</a>].  The XML namespace received in DHCP is expressed
   as a URL, however, it should not be dereferenced or treated as a
   source location for the actual schema and doing so will serve no
   useful purpose.

   Extensions in the XML format can be added to a DHCP format civic
   address using an extension CAtype.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Extension Civic Address Type (CAtype)</span>

   The extension CAtype (CAtype code 40) 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.





<span class="grey">Winterbottom, et al.         Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


    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 (40)  |   Length      |  Namespace URI ...            .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                  Namespace URI (continued)                    .
   .                        ...                                    .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Space (U+20) |           XML element local name              .
   +---------------+                                               .
   .                           ...                                 .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Space (U+20) |           Extension type value                .
   +---------------+                                               .
   .                           ...                                 .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: XML Civic Address Extension CAtype

   CAtype (40) identifies the extension CAtype.

   Length is the number of octets used to represent the namespace URI,
   local name, and value.  The length includes the space between the
   namespace URI and local name and the space between the local name and
   value fields.

   The content of a CAtype (after the CAtype code and length) is UTF-8
   encoded Unicode text [<a href="./rfc3629" title="&quot;UTF-8, a transformation format of ISO 10646&quot;">RFC3629</a>].  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.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  DHCP to XML Format Translation</span>

   The registration of a new CAtype following the process in [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>]
   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.




<span class="grey">Winterbottom, et al.         Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   In lieu of making new numerical CAtype assignments, this document
   creates a new extensionCA type that is defined in a manner that lets
   new civic elements be described in DHCP form by carrying the
   namespace 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.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Conversion Example</span>

   The following example civic address contains two extensions:

      &lt;civicAddress xml:lang="en-US"
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
           xmlns:post="http://postsoftheworld.example.com/ns"
           xmlns:ap="http://example.com/airport/5.0"&gt;
        &lt;country&gt;US&lt;/country&gt;
        &lt;A1&gt;CA&lt;/A1&gt;

        &lt;post:lamp&gt;2471&lt;/post:lamp&gt;
        &lt;post:pylon&gt;AQ-374-4(c)&lt;/post:pylon&gt;

        &lt;ap:airport&gt;LAX&lt;/ap:airport&gt;
        &lt;ap:terminal&gt;Tom Bradley&lt;/ap:terminal&gt;
        &lt;ap:concourse&gt;G&lt;/ap:concourse&gt;
        &lt;ap:gate&gt;36B&lt;/ap:gate&gt;
      &lt;/civicAddress&gt;

              Figure 4: XML Example with Multiple Extensions

   This is converted to a DHCP form as follows:

   country     = US
   CAtype[0]   = en-US
   CAtype[1]   = CA
   CAtype[40]  = http://postsoftheworld.example.com/ns lamp 2471
   CAtype[40]  = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
   CAtype[40]  = http://example.com/airport/5.0 airport LAX
   CAtype[40]  = http://example.com/airport/5.0 terminal Tom Bradley
   CAtype[40]  = http://example.com/airport/5.0 concourse G
   CAtype[40]  = http://example.com/airport/5.0 gate 36B

         Figure 5: Converted DHCP Example with Multiple Extensions







<span class="grey">Winterbottom, et al.         Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  CAtypes Registry</span>

   [<a id="ref-RFC4776">RFC4776</a>] 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 support.

   This document alters the CAtype registry in several ways.  It closes
   the registry to new numeric CAtypes.  It deletes the "NENA" column,
   which is not needed.  It adds columns for a namespace and contact,
   and changes the name of the column currently called "PIDF" to "Local
   Name".  It also adds a column to the registry called "Type".  "Type"
   can have one of two values "A" and "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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Civic Extensions</span>

   We use this new extension method to define some additional civic
   address elements that 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.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Pole Number</span>

   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.













<span class="grey">Winterbottom, et al.         Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


                             _.-----,===.
                            | |    (''''')
                            | |     `---'
                            | |
                            | |               ,---------,
                            | |    ,---,      |Emergency|
                            | |   /|,-.|-----&gt;| Number  |
                            | |  / |110|      '---------'
                            | | /  |`-'|
                            |_|/   | 2 |      ,---------,
                            | |    | 1 |      |Lamp Post|
                            | |    | 2 |-----&gt;| Number  |
                            |-|    | 1 |      '---------'
                            | |\   | 0 |
                            | | \  | 1 |
                            | |  \ | 4 |
                            | |   \|,,,|
                      _     | |
                       ``-..|.|
                              ``--.._
                                     `'--.._

                 Figure 6: Lamp Post with Emergency Number

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Milepost</span>

   On some roads, 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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Street Type Prefix</span>

   The civic schema defined in [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] 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 a street named in this manner to be more easily represented.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  House Number Prefix</span>

   The civic schema defined in [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] provides a 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".





<span class="grey">Winterbottom, et al.         Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  XML Extension Schema</span>

 &lt;?xml version="1.0"?&gt;
 &lt;xs:schema
   targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
   xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
   xmlns:xml="http://www.w3.org/XML/1998/namespace"
   elementFormDefault="qualified" attributeFormDefault="unqualified"&gt;

   &lt;xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/&gt;

   &lt;!-- Post Number --&gt;
   &lt;xs:element name="PN" type="ca:caType"/&gt;

   &lt;!-- Milepost --&gt;
   &lt;xs:element name="MP" type="ca:caType"/&gt;

   &lt;!-- Street Type Prefix --&gt;
   &lt;xs:element name="STP" type="ca:caType"/&gt;

   &lt;!-- House Number Prefix --&gt;
   &lt;xs:element name="HNP" type="ca:caType"/&gt;

 &lt;/xs:schema&gt;

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Extension Examples</span>

   &lt;civicAddress xml:lang="en-US"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"&gt;
     &lt;country&gt;US&lt;/country&gt;
     &lt;A1&gt;CA&lt;/A1&gt;
     &lt;A2&gt;Sacramento&lt;/A2&gt;
     &lt;RD&gt;I5&lt;/RD&gt;
     &lt;cae:MP&gt;248&lt;/cae:MP&gt;
     &lt;cae:PN&gt;22-109-689&lt;/cae:PN&gt;
   &lt;/civicAddress&gt;

            Figure 7: XML Example with Post Number and Milepost










<span class="grey">Winterbottom, et al.         Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   &lt;civicAddress xml:lang="en-US"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"&gt;
     &lt;country&gt;US&lt;/country&gt;
     &lt;A1&gt;CA&lt;/A1&gt;
     &lt;A2&gt;Sacramento&lt;/A2&gt;
     &lt;RD&gt;Colorado&lt;/RD&gt;
     &lt;HNO&gt;223&lt;/HNO&gt;
     &lt;cae:STP&gt;Boulevard&lt;/cae:STP&gt;
     &lt;cae:HNP&gt;A&lt;/cae:HNP&gt;
   &lt;/civicAddress&gt;

   Figure 8: XML Example with Street Type Prefix and House Number Prefix

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Using Local Civic Extension with the LoST Protocol</span>

   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 LoST protocol [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>].
   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
   mechanisms described in this document do not impact LoST.  When LoST
   is used for validation, a &lt;locationValidation&gt; element is returned
   containing a list of valid, a list of invalid, and a list of
   unchecked civic elements.  Figure 9 is an extract of the validation
   response in Figure 6 from [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>].

   &lt;locationValidation&gt;
       &lt;valid&gt;country A1 A3 A6&lt;/valid&gt;
       &lt;invalid&gt;PC&lt;/invalid&gt;
       &lt;unchecked&gt;HNO&lt;/unchecked&gt;
   &lt;/locationValidation&gt;

         Figure 9: Location Validation Example from LoST (<a href="./rfc5222">RFC5222</a>)

   The RelaxNG schema in [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>] requires the elements in each of
   these lists to be namespace qualified, which makes the example in
   Figure 6 of [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>] erroneous.  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
   not cause issues with the LoST server and client implementations, all





<span class="grey">Winterbottom, et al.         Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   elements listed in a &lt;valid&gt;, &lt;invalid&gt;, or &lt;unchecked&gt; element MUST
   be qualified with a namespace.  To illustrate this, the extract above
   from Figure 6 in [<a href="./rfc5222" title="&quot;LoST: A Location-to-Service Translation Protocol&quot;">RFC5222</a>] becomes Figure 10.

   &lt;locationValidation
          xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"&gt;
       &lt;valid&gt;ca:country ca:A1 ca:A3 ca:A6&lt;/valid&gt;
       &lt;invalid&gt;ca:PC&lt;/invalid&gt;
       &lt;unchecked&gt;ca:HNO&lt;/unchecked&gt;
   &lt;/locationValidation&gt;

             Figure 10: Corrected Location Validation Example

   If a validation request has also included the extensions defined in
   <a href="#section-5">Section 5</a>, then the validation response would look like Figure 11.

 &lt;locationValidation
        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"&gt;
     &lt;valid&gt;ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP&lt;/valid&gt;
     &lt;invalid&gt;ca:PC&lt;/invalid&gt;
     &lt;unchecked&gt;ca:HNO cae:MP cae:HNP&lt;/unchecked&gt;
 &lt;/locationValidation&gt;

             Figure 11: Corrected Location Validation Example

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   This document defines a formal way to extend the existing Geopriv
   civic address schema.  While no security threats are directly
   introduced by this document, creators of new civic address extensions
   should refer to Sections <a href="#section-4.3.1">4.3.1</a> and <a href="#section-5.1">5.1</a> of [<a href="./rfc3694" title="&quot;Threat Analysis of the Geopriv Protocol&quot;">RFC3694</a>] to understand the
   environments in which these new elements will be used.  New elements
   should only be registered if the person or organization performing
   the registration understands any associated risks.

   Security threats applicable to the civic address formats are
   described in [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>] DHCP and [<a href="./rfc5139" title="&quot;Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)&quot;">RFC5139</a>] XML.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  IANA Considerations</span>

   This document alters the "CAtypes" registry in the Civic Address
   Types Registry established by [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>].

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  CAtype Registration for Extensions</span>

   IANA has allocated a CAtype code of 40 for the extension CAtype.
   Registrations using this code will be made below, in <a href="#section-8.4">Section 8.4</a>.



<span class="grey">Winterbottom, et al.         Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Changes to the CAtype Registry</span>

   IANA has made the following changes to the CAtype registry:

   o  No registrations of new CAtype numbers in the Civic Address Types
      Registry are permitted, except by IESG Approval [<a href="./rfc5226" title="">RFC5226</a>] under
      unusual circumstances.

   o  The following note has been placed in the header of the CAtypes
      registry, above the table:

         Note: As specified in <a href="./rfc6848">RFC 6848</a>, new registrations are only
         accepted for CAtype 40, using the template specified in
         <a href="#section-8.3">Section 8.3</a>.

   o  The registration procedures are changed: IETF Review (if Type=A),
      Expert Review (if Type=B).  The designated expert is unchanged.

   o  The reference for the table is changed: [<a href="./rfc4776" title="&quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;">RFC4776</a>], <a href="./rfc6848">RFC 6848</a>

   o  The column called "NENA" is removed.

   o  The column called "PIDF" is renamed to "Local Name".

   o  New columns are added named "Namespace URI", "Contact", "Schema"
      and "Type".  All existing entries will have the following values
      for those new columns:

      Namespace URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr

      Contact:  The IESG (iesg@ietf.org); the GEOPRIV working group
         (geopriv@ietf.org)

      Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr

      Type:  A

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Registration Template</span>

   New registrations in the Civic Address Types Registry require the
   following information:

   CAtype:  The assigned numeric CAtype.  All new registrations will use
      the value 40.

   Namespace URI:  A unique identifier for the XML namespace used for
      the extension element.




<span class="grey">Winterbottom, et al.         Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   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.

   Example (optional):  One or more simple examples of the element.

   Contact:  Contact details for the person providing the extension.

   Specification (optional):  A reference to a specification for the
      civic address element.

   Schema (optional):  A reference to a formal schema (XML schema,
      RelaxNG, or other form) that defines the extension.

   Type:  "A" or "B".
      If Type is "A", all clients SHOULD implement this element.  If
      Type is "B", clients MAY implement this element.

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Registration of the CAtypes Defined in this Document</span>

   This section registers the following four new CAtypes in the Civic
   Address Types Registry.

   Post Number (see <a href="#section-5.1">Section 5.1</a>):
   CAtype:  40
   Namespace URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
   Local Name:  PN
   Description:  Post number that is attributed to a lamp post or
      utility pole.
   Contact:  The IESG (iesg@ietf.org); the GEOPRIV working group
      (geopriv@ietf.org)
   Specification:  <a href="./rfc6848#section-5">RFC 6848, Section&nbsp;5</a>
   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
   Type:  A

   Milepost (see <a href="#section-5.2">Section 5.2</a>):
   CAtype:  40
   Namespace URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
   Local Name:  MP
   Description:  Milepost: a marker indicating distance to or from a
      place (often a town).
   Contact:  The IESG (iesg@ietf.org); the GEOPRIV working group
      (geopriv@ietf.org)
   Specification:  <a href="./rfc6848#section-5">RFC 6848, Section&nbsp;5</a>
   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
   Type:  A



<span class="grey">Winterbottom, et al.         Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   Street Type Prefix (see <a href="#section-5.3">Section 5.3</a>):
   CAtype:  40
   Namespace URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
   Local Name:  STP
   Description:  Street Type Prefix.
   Contact:  The IESG (iesg@ietf.org); the GEOPRIV working group
      (geopriv@ietf.org)
   Specification:  <a href="./rfc6848#section-5">RFC 6848, Section&nbsp;5</a>
   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
   Type:  A

   House Number Prefix (see <a href="#section-5.4">Section 5.4</a>):
   CAtype:  40
   Namespace URI:  urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
   Local Name:  HNP
   Description:  House Number Prefix.
   Contact:  The IESG (iesg@ietf.org); the GEOPRIV working group
      (geopriv@ietf.org)
   Specification:  <a href="./rfc6848#section-5">RFC 6848, Section&nbsp;5</a>
   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
   Type:  A

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Registration Policy and Expert Guidance</span>

   The "CAtypes" registry is altered to operate on a registration policy
   of "Expert Review", and optionally "Specification Required" [<a href="./rfc5226" title="">RFC5226</a>]
   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" [<a href="./rfc5226" title="">RFC5226</a>].

   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 [<a href="./rfc5774" title="&quot;Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition&quot;">RFC5774</a>].  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.

   [<a id="ref-RFC6280">RFC6280</a>] provides a comprehensive framework concerning the privacy
   of location information as pertaining to its use in Internet
   applications.  The expert reviewer is asked to keep the spirit of
   this document in mind when reviewing new CAtype registrations.



<span class="grey">Winterbottom, et al.         Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  URN Sub-Namespace Registration</span>

   IANA has registered a new XML namespace, as per the guidelines in
   [<a href="./rfc3688" title="&quot;The IETF XML Registry&quot;">RFC3688</a>].

   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
       &lt;?xml version="1.0"?&gt;
       &lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         "<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>"&gt;
       &lt;html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"&gt;
         &lt;head&gt;
           &lt;title&gt;GEOPRIV Civic Address Extensions&lt;/title&gt;
         &lt;/head&gt;
         &lt;body&gt;
           &lt;h1&gt;Additional Fields for GEOPRIV Civic Address&lt;/h1&gt;
           &lt;h2&gt;urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext&lt;/h2&gt;
           &lt;p&gt;See &lt;a href="http://www.rfc-editor.org/rfc/rfc6848.txt"&gt;
              <a href="./rfc6848">RFC 6848</a>&lt;/a&gt;.&lt;/p&gt;
         &lt;/body&gt;
       &lt;/html&gt;
     END

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>.  XML Schema Registration</span>

   This section registers an XML schema as per the procedures in
   [<a href="./rfc3688" title="&quot;The IETF XML Registry&quot;">RFC3688</a>].

   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)

   XML:  The XML for this schema can be found as the entirety of
      <a href="#section-5.5">Section 5.5</a> of this document.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Acknowledgements</span>

   Thanks to anyone who has tried to extend the civic schema and found
   it a little less than intuitive.





<span class="grey">Winterbottom, et al.         Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3629">RFC3629</a>]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, <a href="./rfc3629">RFC 3629</a>, November 2003.

   [<a id="ref-RFC3688">RFC3688</a>]  Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
              January 2004.

   [<a id="ref-RFC3694">RFC3694</a>]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", <a href="./rfc3694">RFC 3694</a>,
              February 2004.

   [<a id="ref-RFC4776">RFC4776</a>]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", <a href="./rfc4776">RFC 4776</a>, November 2006.

   [<a id="ref-RFC5139">RFC5139</a>]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", <a href="./rfc5139">RFC 5139</a>, February 2008.

   [<a id="ref-RFC5222">RFC5222</a>]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", <a href="./rfc5222">RFC 5222</a>, August 2008.

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              May 2008.

   [<a id="ref-RFC6280">RFC6280</a>]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              <a href="https://www.rfc-editor.org/bcp/bcp160">BCP 160</a>, <a href="./rfc6280">RFC 6280</a>, July 2011.

   [<a id="ref-XMLNS">XMLNS</a>]    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,
              &lt;<a href="http://www.w3.org/TR/2006/REC-xml-names11-20060816">http://www.w3.org/TR/2006/REC-xml-names11-20060816</a>&gt;.








<span class="grey">Winterbottom, et al.         Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-RFC4079">RFC4079</a>]  Peterson, J., "A Presence Architecture for the
              Distribution of GEOPRIV Location Objects", <a href="./rfc4079">RFC 4079</a>,
              July 2005.

   [<a id="ref-RFC5012">RFC5012</a>]  Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              <a href="./rfc5012">RFC 5012</a>, January 2008.

   [<a id="ref-RFC5774">RFC5774</a>]  Wolf, K. and A. Mayrhofer, "Considerations for Civic
              Addresses in the Presence Information Data Format Location
              Object (PIDF-LO): Guidelines and IANA Registry
              Definition", <a href="https://www.rfc-editor.org/bcp/bcp154">BCP 154</a>, <a href="./rfc5774">RFC 5774</a>, March 2010.

   [<a id="ref-RFC5985">RFC5985</a>]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
              <a href="./rfc5985">RFC 5985</a>, September 2010.


































<span class="grey">Winterbottom, et al.         Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


Authors' Addresses

   James Winterbottom
   CommScope
   Suit 1, Level 2
   iC Enterprise 1, Innovation Campus
   Squires Way
   North Wollongong, NSW  2500
   AU

   Phone: +61 242 212938
   EMail: james.winterbottom@commscope.com


   Martin Thomson
   Skype
   3210 Porter Drive
   Palo Alto, CA  94304
   US

   EMail: martin.thomson@gmail.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











<span class="grey">Winterbottom, et al.         Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6848">RFC 6848</a>                    Civic Extensions                January 2013</span>


   Robins George
   Huawei Technologies
   Huawei Base, Bantian, Longgan District
   Shenzhen, Guangdong  518129
   P. R. China

   Phone: +86 755 2878 8314
   EMail: robinsgv@gmail.com











































Winterbottom, et al.         Standards Track                   [Page 21]
</pre>