One document matched: draft-winterbottom-geopriv-local-civic-01.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902">
  <front>
    <title abbrev="Local Civic">Specifying Local Civic Address Fields in PIDF-LO</title>

    <author initials="J." surname="Winterbottom" fullname="James Winterbottom">
      <organization>Andrew Corporation</organization>
      <address>
        <postal>
          <street>Andrew Building (39)</street>
          <street>Wollongong University Campus</street>
          <street>Northfields Avenue</street>
          <city>Wollongong</city>
          <region>NSW</region>
          <code>2522</code>
          <country>AU</country>
        </postal>
        <phone>+61 242 212938</phone>
        <email>james.winterbottom@andrew.com</email>
      </address>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Andrew Corporation</organization>
      <address>
        <postal>
          <street>Andrew Building (39)</street>
          <street>Wollongong University Campus</street>
          <street>Northfields Avenue</street>
          <city>Wollongong</city>
          <region>NSW</region>
          <code>2522</code>
          <country>AU</country>
        </postal>
        <phone>+61 2 4221 2915</phone>
        <email>martin.thomson@andrew.com</email>
      </address>
    </author>
    <author initials="R." surname="Barnes" fullname="Richard Barnes">
      <organization>BBN Technologies</organization>
      <address>
        <postal>
          <street>9861 Broken Land Parkway</street>
          <city>Columbia</city>
          <region>MD</region>
          <code>21046</code>
          <country>US</country>
        </postal>
        <phone>+1 410 290 6169</phone>
        <email>rbarnes@bbn.com</email>
      </address>
    </author>

    <date month="October" year="2010"/>
    <area>RAI</area>
    <workgroup>GEOPRIV</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Local</keyword>
    <keyword>Civic</keyword>
    <keyword>Location</keyword>
    <keyword>GEOPRIV</keyword>

    <abstract>
      <t>This document describes how to specify local civic elements in the Geopriv civic schema maintaining backward compatibility with existing specifications and implementations.
         Support for providing local civic elements over DHCP is also described.
      </t>

    </abstract>
  </front>
  <middle>

    <section anchor="intro" title="Introduction">
      <t>The Geopriv civic location specification <xref target="RFC5139"/> defines an XML schema that are intended to allow the expression of
         civic location in most countries. It was recognized that some countries may require a
         profile or guidance on how to specify local addresses using the elements defined in <xref target="RFC5139"/> and so <xref target="RFC5774"/> was produced
         to provide this function. Subsequent to these specifications being produced, a number of individual contributions have been made trying to add additional
         civic elements to address local jurisdictional requirements. These contributions were specified in such a away that broke backward compatibility for protocols, 
         equipment, and other standards already using the <xref target="RFC5139"/> specification.
      </t>
       <t>This document defines a method that allows
         the specification of local civic address elements inside a <xref target="RFC5139"/> object. It further allows these local civic elements
         to be carried over DHCP using <xref target="RFC4776"/>, HELD <xref target="RFC5985"/>, and LoST <xref target="RFC5222"/> without modification and so maintain
         backward compatibility with existing specifications and implementations.      
      </t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>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 <xref target="RFC2119"/>.
      </t>
    </section>

    <section anchor="local" title="Specifying Local Civic Elements">

      <t>The civic schema in <xref target="RFC5139"/> defines an ordered structure of elements that can be combined to describe a street address.
         The XML extension point at the bottom of the schema is used to include address elements of local significance into the main civic body.  
      </t>
      <t>For example, suppose the Central Devon Canals authority wishes to introduce a new civic element called "bridge". The authority must define an
         XML namespace and define the "bridge" element within that namespace. The namespace needs to be a URI and needs to be unique, for example 
         "http://www.central.devon.canals.org/ns1.0".
         Finally, the authority can create a civic address that includes the 
         new "bridge" element at the bottom.
      </t>
      
            <figure anchor="localcivic2" title="Local Civic Object Example">
        <artwork><![CDATA[
   <civicAddress xml:lang="en-AU"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:cdc="http://www.central.devon.canals.org/ns1.0">
     <country>UK</country>
     <A1>Devon</A1>
     <A3>Monkokehampton/A3>
     <RD>Deckport</RD>
     <STS>Cross</STS>
     
     <cdc:bridge>21451338</cdc:bridge>

   </civicAddress>
     
          ]]></artwork>
      </figure>

      <t>Nodes that receive the location information but don't understand the locally specified address elements can safely ignore them, yet still interpret
         the main civic elements from <xref target="RFC5139"/> and so maintain backward compatibility. Where the information is passed to local applications, such as a LoST server
         for emergency call routing, the significance of the localized elements can be safely applied. This allows localized address elements to be included in a location
         response from a LIS using HELD without modification being required to the HELD protocol or the HELD client on the device.
      </t>
      
      <section title="Localized Elements Using DHCP">
      
      <t>In networks that elect to use DHCP to provide civic address information to clients, two new CATypes are defined to address this basic functionality, 
         and no further CATypes will be allocated by IANA.
      </t>
      <t>The "Namespace" CAType provides the definition of an XML namespace and a corresponding namespace prefix. This CAType
         is sent multiple times if elements from multiple namespaces are required.
       </t>
       <t>The "Element" CAType conveys a single namespace element and its value. The element name is qualified with a namespace prefix that is provided 
          using a Namespace CAType. If no corresponding Namespace CAType is received that defines the namespace prefix in an Element CAType, then the Element CAType
          MUST be ignored.
       </t>
       <t>To aid in client parsing and reduce the likelihood of server configuration errors, it is RECOMMENDED that all Namespace CATypes proceed any Element CATypes
        in the response from the server to the client.
       </t>
      
      <figure anchor="localcivicdhcp" title="DHCP Example Conveying Muiptle Namespace Elements">
        <artwork><![CDATA[
   ...
   CAType=XX Value="xmlns:cdc=http://www.central.devon.canals.org/ns1.0"
   CAType=XX value="xmlns:ap="http://www.example.com/airport/5.0"
   CAType=YY Value="<cdc:bridge>21451338</cdc:bridge>"
   CAType=YY Value="<cdc:pylonCount>2</cdcpyloncount>"
   CAType=YY value="<ap:airport>LAX</ap:airport>"
   CAType=YY value="<ap:terminal>Tom Bradley</ap:terminal>"
   CAType=YY value="<ap:concourse>G</ap:concourse>"
   CAType=YY value="<ap:gate>36B</ap:gate>"
          ]]></artwork>
      </figure>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document defines a formal way to extend the existing Geopriv civic schema. No security threats are introduced by this document.
         Security threats applicable to configuring a device with a civic address using DHCP are specified in <xref target="RFC4776"/>.
         Security threats applicable to providing a device with its civic location using HELD are specific in <xref target="RFC5985"/>         
      </t>


    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>This document updates the civic address type registry established by <xref target="RFC4776"/>.  Three additional value are added:
      
      <list style="hanging">
        <t hangText="XX "Namespace":">Namespace in which the local address elements are defined</t>
        <t hangText="YY  "Element":">qualified local address element and value value</t>
      </list>
      Further this document terminates the addition of CATypes that proposed future specification may attempt to define.
      Required civic elements not defined in the <xref target="RFC5139"/> MUST only be provided using the mechanism described in this document.
       </t> 
      <t>[[IANA/RFC-EDITOR: Please replace XX and YY with the allocated civic address type number assigned from the pool]]
      </t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Brian Rosen, Delaine Arnold, Robins George, and anyone else who has tried to extend the civic schema and found it a little unintuative</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml"?>
    </references>
    <references title="Informative References">
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml"?>
        <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5774.xml"?>
     </references>
  </back>
</rfc>