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

Versions: (draft-ietf-geopriv-prefix) 00 01 02 03 04 05 06 07 08 09 10 RFC 6848

GEOPRIV                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: September 12, 2011                                    R. Barnes
                                                        BBN Technologies
                                                                B. Rosen
                                                           NeuStar, Inc.
                                                               R. George
                                                     Huawei Technologies
                                                          March 11, 2011


             Specifying Civic Address Extensions in PIDF-LO
                   draft-ietf-geopriv-local-civic-01

Abstract

   New fields are occasionally added to civic addresses.  A backwardly-
   compatible mechanism for adding civic address elements to the Geopriv
   civic address format is described.  A formal mechanism for handling
   unsupported extensions when translating between XML and DHCP civic
   address forms is defined for entities that need to perform this
   translation.  Intial extensions for some new elements are also
   defined.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2011.

Copyright Notice

   Copyright (c) 2011 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



Winterbottom, et al.   Expires September 12, 2011               [Page 1]

Internet-Draft              Civic Extensions                  March 2011


   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 . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Specifying Civic Address Extensions  . . . . . . . . . . . . .  4
   3.  Translating Unsupported Elements . . . . . . . . . . . . . . .  5
     3.1.  XML to DHCP Format Translation . . . . . . . . . . . . . .  6
     3.2.  Extension Civic Address Type (CAtype)  . . . . . . . . . .  6
     3.3.  DHCP to XML Format Translation . . . . . . . . . . . . . .  7
     3.4.  Conversion Example . . . . . . . . . . . . . . . . . . . .  7
   4.  Civic Extensions . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Pole Number  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Mile Post  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Street Type Prefix . . . . . . . . . . . . . . . . . . . .  9
     4.4.  House Number Prefix  . . . . . . . . . . . . . . . . . . .  9
     4.5.  XML Extension Schema . . . . . . . . . . . . . . . . . . . 10
     4.6.  Extension examples . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  CAtype Registration for Extensions . . . . . . . . . . . . 11
     6.2.  End of Numeric CAtype Registration . . . . . . . . . . . . 11
     6.3.  URN sub-namespace registration for
           'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'  . . 11
     6.4.  XML Schema Registration  . . . . . . . . . . . . . . . . . 12
     6.5.  Registration Template  . . . . . . . . . . . . . . . . . . 12
     6.6.  Registration Policy and Expert Guidance  . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16









Winterbottom, et al.   Expires September 12, 2011               [Page 2]

Internet-Draft              Civic Extensions                  March 2011


1.  Introduction

   The Geopriv civic location specifications ([RFC4776], [RFC5139])
   define an XML and binary representtations for civic addresses that
   allow for the expression of civic addresses.  Guidance for the use of
   these formats for the civic addresses in different countries is
   included in [RFC5774].

   Subsequent to these specifications being produced, use cases for
   extending the civic address format with new elements have emerged.
   Extension elements do not readily fit existing elements, as
   recommended in [RFC5774].

   The XML format for civic addresses [RFC5139] provides a mechanism
   that allows for the addition of standardized or privately understood
   elements.  A similar facility for private extension is not provided
   for the DHCP format [RFC4776], though new specifications are able to
   define new CAtypes (civic address types).

   A recipient of a civic address in either format currently has no
   option other than to ignore elements that it does not understand.
   This results in any elements that are unknown to that recipient being
   discarded if a recipient performs a translation between the two
   formats.  In order for a new extension to be preserved through
   translation by any recipient, the recipient has to understand the
   extension and know how to correlate an XML element with a CAtype.

   This document describes how new civic address elements are added.
   Extension always starts with the definition of XML elements.  A
   mechanism for carrying the extension in the DHCP format is described.
   A new XML namespace containing a small number of additional civic
   elements is also defined and can be used as a template to illustrate
   how other extensions can be defined as required.

   These mechanisms ensure that any translation between formats can be
   performed consistently and without loss of information.  Translation
   between formats can occur without knowledge of every extension that
   is present.

   These additions described in this document are backwardly compatible.
   Existing implementations may cause extension information to be lost,
   but the presence of extensions does not affect an implementation that
   conforms to either [RFC4776] or [RFC5139].

1.1.  Motivating Example

   One instance where translation might be necessary is where a device
   receives location configuration using DHCP [RFC4776].  Conversion of



Winterbottom, et al.   Expires September 12, 2011               [Page 3]

Internet-Draft              Civic Extensions                  March 2011


   DHCP information to an XML form is necessary if the device wishes to
   use the DHCP-provided information in a range of applications,
   including location-based presence services [RFC4079], and emergency
   calling [RFC5012].

    +--------+          +--------+         +-----------+
    | DHCP   |   DHCP   | Device |   XML   | Recipient | e.g., Presence
    | Server |--------->|        |-------->|           |       Agent
    +--------+          +--------+         +-----------+

                            Conversion Scenario

   The Device that performs the translation between the DHCP and XML
   formats might not be aware of some of the extensions that are in use.
   Without knowledge of these extensions and how they are represented in
   XML, the Device is forced to discard them.

   These extensions could be useful - or critical - to the ultimate
   consumers of this information.  For instance, an extension element
   might provide a presence watcher with important information in
   locating the Device or an extension might be significant in choosing
   a particular call route.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Specifying Civic Address Extensions

   The civic schema in [RFC5139] defines an ordered structure of
   elements that can be combined to describe a civic address.  The XML
   extension point at the end of this sequence is used to extend the
   address.

   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.



Winterbottom, et al.   Expires September 12, 2011               [Page 4]

Internet-Draft              Civic Extensions                  March 2011


   The namespace needs to be a unique URI, for example
   "http://devon.canals.org.uk/civic".

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

      <civicAddress xml:lang="en-GB"
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
           xmlns:cdc="http://devon.canals.org.uk/civic">
        <country>UK</country>
        <A1>Devon</A1>
        <A3>Monkokehampton</A3>
        <RD>Deckport</RD>
        <STS>Cross</STS>

        <cdc:bridge>21451338</cdc:bridge>

      </civicAddress>

                 Figure 1: Extended Civic Address Example

   An entity that receives this location information might not
   understand the extension address element.  As long as the added
   element is able to be safely ignored, the remainder of the civic
   address can be used.  The result is that the information is not as
   useful as it could be, but the added element does not prevent the use
   of the remainder of the address.

   The address can be passed to other applications, such as a LoST
   server [RFC5222], without modification.  If the application
   understands the added elements, it is able to make use of that
   information.  For example, if this civic address is acquired using
   HELD [RFC5985], it can be included in a LoST request directly.


3.  Translating Unsupported Elements

   Unsupported civic address elements can be carried without consequence
   only as long as the format of the address does not change.  When
   converting between the XML and DHCP formats, these unsupported
   elements are necessarily discarded: the entity performing the
   translation has no way to know the correct element to use in the
   target format.

   All extensions MUST be defined using the mechanism described in this
   document.  Extensions that use numeric CAtypes or other mechanisms
   cannot be safely translated between XML and DHCP representations.




Winterbottom, et al.   Expires September 12, 2011               [Page 5]

Internet-Draft              Civic Extensions                  March 2011


   An entity that does not support these extension mechanisms is
   expected to remove elements it doesn't understand when performing
   conversions.

3.1.  XML to DHCP Format Translation

   Extensions to the XML format [RFC5139] are defined in a new XML
   namespace [XMLNS].

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

3.2.  Extension Civic Address Type (CAtype)

   The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor:
   please replace XX here and in the figure below with the assigned
   code] includes three values that uniquely identify the XML extension
   and its value: a namespace URI, the local name of the XML element,
   and the text content of that element.  These three values are all
   included in the value of the CAtype, each separated by a single
   whitespace character.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  CAtype (XX)  |   Length      |  Namespace URI ...            .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                  Namespace URI (continued) ...                .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Space (U+20) |           XML element local name ...          .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Space (U+20) |           Extension type value  ...           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: XML Civic Address Extension CAtype

   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.






Winterbottom, et al.   Expires September 12, 2011               [Page 6]

Internet-Draft              Civic Extensions                  March 2011


3.3.  DHCP to XML Format Translation

   The registration of a new CAtype following the process in [RFC4776]
   means that a recipient that does not know the equivalent XML is
   unable to produce a complete XML representation of the DHCP civic
   address.  For this reason, this document ends the registration of new
   numeric CAtypes.  No new registrations of numeric CAtypes can be
   made.

   In lieu of making new numerical CAtype assignments, this document
   creates a new extensionCA type which is defined in a manner that lets
   new civic elements be described in DHCP form by carrying the name
   space and type name of the extension in parameters of the extensionCA
   type.

   When converting to XML, the namespace prefix used for the extension
   element is selected by the entity that performs the conversion.

3.4.  Conversion Example

   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.net/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 3: XML Example with Multiple Extensions












Winterbottom, et al.   Expires September 12, 2011               [Page 7]

Internet-Draft              Civic Extensions                  March 2011


   This is converted to a DHCP form as follows:

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

         Figure 4: Converted DHCP Example with Multiple Extensions


4.  Civic Extensions

   We use this new extension method to define some additional civic
   address elements which are needed to correctly encode civic locations
   in several countries.  The definition of these new civic address
   elements also serves as an example of how to define additional
   elements using the mechanisms described in this document.

4.1.  Pole Number

   In some areas, utility and lamp posts carry a unique identifier,
   which we call a pole number in this document.  In some countries, the
   label on the lamp post also carries the local emergency service
   number, such as "110", encouraging callers to use the pole number to
   identify their location.





















Winterbottom, et al.   Expires September 12, 2011               [Page 8]

Internet-Draft              Civic Extensions                  March 2011


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

                 Figure 5: Lamp post with emergency number

4.2.  Mile Post

   On some roads, and many trails, railroad rights of way and other
   linear features, a post with a mile or kilometer distance from one
   end of the feature may be found (a "milepost").  There are other
   cases of poles or markers with numeric indications that are not the
   same as a "house number" or street address number.

4.3.  Street Type Prefix

   The civic schema defined in [RFC5139] allows the definition of
   address "123 Colorado Boulevard", but it does not allow for the easy
   expression of "123 Boulevard Colorado".  Adding a street-type prefix,
   allows street named in this manner to be more easily represented.

4.4.  House Number Prefix

   The civic schema defined in [RFC5139] provides house number suffix
   element, allowing one to express an address like "123A Main Street",
   but it does not contain a corresponding house number prefix.  The
   house number prefix element allows the expression of address such as
   "Z123 Main Street".





Winterbottom, et al.   Expires September 12, 2011               [Page 9]

Internet-Draft              Civic Extensions                  March 2011


4.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>

4.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>

                XML Example with Post Number and Mile Post








Winterbottom, et al.   Expires September 12, 2011              [Page 10]

Internet-Draft              Civic Extensions                  March 2011


    <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>

          XML Example with Street prefix and House Number Prefix


5.  Security Considerations

   This document defines a formal way to extend the existing Geopriv
   civic address schema.  No security threats are introduced by this
   document.

   Security threats applicable to the civic address formats are
   described in [RFC4776] (DHCP) and [RFC5139] (XML).


6.  IANA Considerations

   This document alters the "CAtypes" registry established by [RFC4776].

6.1.  CAtype Registration for Extensions

   IANA has allocated a CAtype code of XX for the extension CAtype.

   [[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]

6.2.  End of Numeric CAtype Registration

   No further registration of numeric CAtypes is permitted, and the
   register created as part of [RFC4776] is cloased.  New registrations
   in this registry use the registration template in Section 6.5.

6.3.  URN sub-namespace registration for
      'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext'

   This document calls for IANA to register a new XML namespace, as per
   the guidelines in [RFC3688].





Winterbottom, et al.   Expires September 12, 2011              [Page 11]

Internet-Draft              Civic Extensions                  March 2011


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

   Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      James Winterbottom (james.winterbottom@andrew.com).

   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>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

6.4.  XML Schema Registration

   This section registers an XML schema as per the procedures in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      James Winterbottom (james.Winterbottom@andrew.com).

      The XML for this schema can be found as the entirety of
      Section 4.5 of this document.

6.5.  Registration Template

   New registrations in the "CAtypes" registry require the following
   information:

   CAtype:  The assigned numeric CAtype.  All new registrations use the
      value XX.  [[IANA/RFC-Editor: update XX] Existing registrations
      use their assigned value.





Winterbottom, et al.   Expires September 12, 2011              [Page 12]

Internet-Draft              Civic Extensions                  March 2011


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

   Local Name:  The local name of an XML element that carries the civic
      address element.

   Description:  A brief description of the semantics of the civic
      address element.

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

   Contact:  Contact details for the person providing the extension.

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

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

   Registrations from [RFC4776] and [RFC5139] are registered with the
   following form:

   CAtype:  (The existing CAtype.)

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

   Local Name:  (The contents of the PIDF column.)

   Description:  (The existing description for the element, including a
      note about the equivalent NENA field, if present.)

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

   Specification:  RFC4776 and RFC5139

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

   Registration of the schema defined in this document in Section 4.5.

   CAtype:  The assigned numeric CAtype value is XX.  [[IANA/RFC-Editor:
      update XX]

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







Winterbottom, et al.   Expires September 12, 2011              [Page 13]

Internet-Draft              Civic Extensions                  March 2011


   Local Name:  PN, MP, STP, HNP

   Description:  PN: Post number that is attributed to a lamp post or
      utility pole.

   Description:  MP: Mile Post a marker indicating distance to or from a
      place (often a town).

   Description:  STP: Street Type Prefix.

   Description:  HNP: House Number Prefix.

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

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

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

6.6.  Registration Policy and Expert Guidance

   The "CAtypes" registry is altered to operate on a registration policy
   of "Expert Review", and optionally "Specification Required"
   [RFC5226].

   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.

   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.


7.  Acknowledgements

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


8.  References




Winterbottom, et al.   Expires September 12, 2011              [Page 14]

Internet-Draft              Civic Extensions                  March 2011


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [XMLNS]    Hollander, D., Layman, A., Tobin, R., and T. Bray,
              "Namespaces in XML 1.1 (Second Edition)", World Wide Web
              Consortium Recommendation REC-xml-names11-20060816,
              August 2006,
              <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.

8.2.  Informative References

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4079]  Peterson, J., "A Presence Architecture for the
              Distribution of GEOPRIV Location Objects", RFC 4079,
              July 2005.

   [RFC5012]  Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              RFC 5012, January 2008.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC5774]  Wolf, K. and A. Mayrhofer, "Considerations for Civic
              Addresses in the Presence Information Data Format Location
              Object (PIDF-LO): Guidelines and IANA Registry
              Definition", BCP 154, RFC 5774, March 2010.




Winterbottom, et al.   Expires September 12, 2011              [Page 15]

Internet-Draft              Civic Extensions                  March 2011


   [RFC5985]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
              RFC 5985, September 2010.


Authors' Addresses

   James Winterbottom
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   Phone: +61 242 212938
   Email: james.winterbottom@andrew.com


   Martin Thomson
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com


   Richard Barnes
   BBN Technologies
   9861 Broken Land Parkway
   Columbia, MD  21046
   US

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com


   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr
   Mars, PA  16046
   US

   Email: br@brianrosen.net




Winterbottom, et al.   Expires September 12, 2011              [Page 16]

Internet-Draft              Civic Extensions                  March 2011


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

   Phone: +86 755 2878 8314
   Email: robinsg@huawei.com











































Winterbottom, et al.   Expires September 12, 2011              [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/