doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc6848.txt b/doc/rfc/rfc6848.txt
new file mode 100644
index 0000000..bad7a91
--- /dev/null
+++ b/doc/rfc/rfc6848.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Winterbottom
+Request for Comments: 6848                                     CommScope
+Updates: 4776, 5222                                           M. Thomson
+Category: Standards Track                                          Skype
+ISSN: 2070-1721                                                R. Barnes
+                                                        BBN Technologies
+                                                                B. Rosen
+                                                           NeuStar, Inc.
+                                                               R. George
+                                                     Huawei Technologies
+                                                            January 2013
+
+
+                 Specifying Civic Address Extensions in
+     the Presence Information Data Format Location Object (PIDF-LO)
+
+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 RFC 5222) 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 Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6848.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 1]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   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  . . . . . . . . . . . . .  5
+   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 . . . . . . . . . . . . . . . . . . . .  8
+   4.  CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . .  9
+   5.  Civic Extensions . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.1.  Pole Number  . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 13
+     8.2.  Changes to the CAtype Registry . . . . . . . . . . . . . . 14
+     8.3.  Registration Template  . . . . . . . . . . . . . . . . . . 14
+     8.4.  Registration of the CAtypes Defined in this Document . . . 15
+     8.5.  Registration Policy and Expert Guidance  . . . . . . . . . 16
+     8.6.  URN Sub-Namespace Registration . . . . . . . . . . . . . . 17
+     8.7.  XML Schema Registration  . . . . . . . . . . . . . . . . . 17
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 19
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 2]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+1.  Introduction
+
+   The Geopriv civic location specifications ([RFC4776], [RFC5139])
+   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 [RFC5774].
+
+   Subsequent to these specifications being produced, use cases for
+   extending the civic address format with new elements have emerged.
+   [RFC5774] describes a mechanism for mapping long-standing address
+   formats into the civic address elements defined in [RFC4776] and
+   [RFC5139].  However, some of these existing address elements do not
+   readily fit into the civic address elements defined in [RFC4776] and
+   [RFC5139].  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 [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.
+   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.
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 3]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   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 [RFC4776] or [RFC5139].
+
+   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 <locationValidation>
+   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.
+
+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
+    +--------+          +--------+         +-----------+
+
+                       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.
+
+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].
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 4]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+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.
+
+   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.example.com/civic".
+
+   A civic address that includes the new "bridge" element is shown in
+   Figure 2.
+
+      <civicAddress xml:lang="en-GB"
+           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+           xmlns:cdc="http://devon.canals.example.com/civic">
+        <country>UK</country>
+        <A1>Devon</A1>
+        <A3>Monkokehampton</A3>
+        <RD>Deckport</RD>
+        <STS>Cross</STS>
+
+        <cdc:bridge>21451338</cdc:bridge>
+
+      </civicAddress>
+
+                 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 [RFC5222], without modification.  If the application
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 5]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   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) [RFC5985], it can be included
+   in a LoST request directly.
+
+3.  Translating Unsupported Elements
+
+   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.
+
+3.1.  XML to DHCP Format Translation
+
+   Extensions to the XML format [RFC5139] are defined in a new XML
+   namespace [XMLNS].  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.
+
+3.2.  Extension Civic Address Type (CAtype)
+
+   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.
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 6]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+    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 [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.
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 7]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   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.
+
+3.4.  Conversion Example
+
+   The following example civic address contains two extensions:
+
+      <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">
+        <country>US</country>
+        <A1>CA</A1>
+
+        <post:lamp>2471</post:lamp>
+        <post:pylon>AQ-374-4(c)</post:pylon>
+
+        <ap:airport>LAX</ap:airport>
+        <ap:terminal>Tom Bradley</ap:terminal>
+        <ap:concourse>G</ap:concourse>
+        <ap:gate>36B</ap:gate>
+      </civicAddress>
+
+              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
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 8]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+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 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.
+
+5.  Civic Extensions
+
+   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.
+
+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.         Standards Track                    [Page 9]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+                             _.-----,===.
+                            | |    (''''')
+                            | |     `---'
+                            | |
+                            | |               ,---------,
+                            | |    ,---,      |Emergency|
+                            | |   /|,-.|----->| Number  |
+                            | |  / |110|      '---------'
+                            | | /  |`-'|
+                            |_|/   | 2 |      ,---------,
+                            | |    | 1 |      |Lamp Post|
+                            | |    | 2 |----->| Number  |
+                            |-|    | 1 |      '---------'
+                            | |\   | 0 |
+                            | | \  | 1 |
+                            | |  \ | 4 |
+                            | |   \|,,,|
+                      _     | |
+                       ``-..|.|
+                              ``--.._
+                                     `'--.._
+
+                 Figure 6: Lamp Post with Emergency Number
+
+5.2.  Milepost
+
+   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.
+
+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 a street named in this manner to be more easily represented.
+
+5.4.  House Number Prefix
+
+   The civic schema defined in [RFC5139] 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".
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 10]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+5.5.  XML Extension Schema
+
+ <?xml version="1.0"?>
+ <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">
+
+   <xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
+
+   <!-- Post Number -->
+   <xs:element name="PN" type="ca:caType"/>
+
+   <!-- Milepost -->
+   <xs:element name="MP" type="ca:caType"/>
+
+   <!-- Street Type Prefix -->
+   <xs:element name="STP" type="ca:caType"/>
+
+   <!-- House Number Prefix -->
+   <xs:element name="HNP" type="ca:caType"/>
+
+ </xs:schema>
+
+5.6.  Extension Examples
+
+   <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">
+     <country>US</country>
+     <A1>CA</A1>
+     <A2>Sacramento</A2>
+     <RD>I5</RD>
+     <cae:MP>248</cae:MP>
+     <cae:PN>22-109-689</cae:PN>
+   </civicAddress>
+
+            Figure 7: XML Example with Post Number and Milepost
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 11]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   <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">
+     <country>US</country>
+     <A1>CA</A1>
+     <A2>Sacramento</A2>
+     <RD>Colorado</RD>
+     <HNO>223</HNO>
+     <cae:STP>Boulevard</cae:STP>
+     <cae:HNP>A</cae:HNP>
+   </civicAddress>
+
+   Figure 8: XML Example with Street Type 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 LoST protocol [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
+   mechanisms described in this document do not impact LoST.  When LoST
+   is used for validation, a <locationValidation> 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 [RFC5222].
+
+   <locationValidation>
+       <valid>country A1 A3 A6</valid>
+       <invalid>PC</invalid>
+       <unchecked>HNO</unchecked>
+   </locationValidation>
+
+         Figure 9: 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 of [RFC5222] 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
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 12]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   elements listed in a <valid>, <invalid>, or <unchecked> element MUST
+   be qualified with a namespace.  To illustrate this, the extract above
+   from Figure 6 in [RFC5222] becomes Figure 10.
+
+   <locationValidation
+          xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+       <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
+       <invalid>ca:PC</invalid>
+       <unchecked>ca:HNO</unchecked>
+   </locationValidation>
+
+             Figure 10: Corrected Location Validation Example
+
+   If a validation request has also included the extensions defined in
+   Section 5, then the validation response would look like Figure 11.
+
+ <locationValidation
+        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
+        xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
+     <valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>
+     <invalid>ca:PC</invalid>
+     <unchecked>ca:HNO cae:MP cae:HNP</unchecked>
+ </locationValidation>
+
+             Figure 11: Corrected Location Validation Example
+
+7.  Security Considerations
+
+   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 4.3.1 and 5.1 of [RFC3694] 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 [RFC4776] DHCP and [RFC5139] XML.
+
+8.  IANA Considerations
+
+   This document alters the "CAtypes" registry in the Civic Address
+   Types Registry established by [RFC4776].
+
+8.1.  CAtype Registration for Extensions
+
+   IANA has allocated a CAtype code of 40 for the extension CAtype.
+   Registrations using this code will be made below, in Section 8.4.
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 13]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+8.2.  Changes to the CAtype Registry
+
+   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 [RFC5226] under
+      unusual circumstances.
+
+   o  The following note has been placed in the header of the CAtypes
+      registry, above the table:
+
+         Note: As specified in RFC 6848, new registrations are only
+         accepted for CAtype 40, using the template specified in
+         Section 8.3.
+
+   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: [RFC4776], RFC 6848
+
+   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
+
+8.3.  Registration Template
+
+   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.
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 14]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   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.
+
+8.4.  Registration of the CAtypes Defined in this Document
+
+   This section registers the following four new CAtypes in the Civic
+   Address Types Registry.
+
+   Post Number (see Section 5.1):
+   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:  RFC 6848, Section 5
+   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
+   Type:  A
+
+   Milepost (see Section 5.2):
+   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:  RFC 6848, Section 5
+   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
+   Type:  A
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 15]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   Street Type Prefix (see Section 5.3):
+   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:  RFC 6848, Section 5
+   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
+   Type:  A
+
+   House Number Prefix (see Section 5.4):
+   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:  RFC 6848, Section 5
+   Schema:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
+   Type:  A
+
+8.5.  Registration Policy and Expert Guidance
+
+   The "CAtypes" registry is altered to 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" [RFC5226].
+
+   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.
+
+   [RFC6280] 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.
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 16]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+8.6.  URN Sub-Namespace Registration
+
+   IANA has registered 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
+       <?xml version="1.0"?>
+       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+       <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+         <head>
+           <title>GEOPRIV Civic Address Extensions</title>
+         </head>
+         <body>
+           <h1>Additional Fields for GEOPRIV Civic Address</h1>
+           <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
+           <p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt">
+              RFC 6848</a>.</p>
+         </body>
+       </html>
+     END
+
+8.7.  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)
+
+   XML:  The XML for this schema can be found as the entirety of
+      Section 5.5 of this document.
+
+9.  Acknowledgements
+
+   Thanks to anyone who has tried to extend the civic schema and found
+   it a little less than intuitive.
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 17]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+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.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
+              "Threat Analysis of the Geopriv Protocol", RFC 3694,
+              February 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.
+
+   [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.
+
+   [RFC6280]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+              Tschofenig, H., and H. Schulzrinne, "An Architecture for
+              Location and Location Privacy in Internet Applications",
+              BCP 160, RFC 6280, July 2011.
+
+   [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,
+              <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 18]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+10.2.  Informative References
+
+   [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.         Standards Track                   [Page 19]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 20]
+
+RFC 6848                    Civic Extensions                January 2013
+
+
+   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]
+