One document matched: draft-winterbottom-geopriv-local-civic-03.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>A backwardly-compatible mechanism for adding locally significant 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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Geopriv civic location specifications (<xref target="RFC4776"/>, <xref target="RFC5139"/>) define an XML and binary representtations for civic addresses that allow for the expression of civic addresses in most countries. Guidance for the use of these formats for the civic addresses in different countries is included in <xref target="RFC5774"/>.
</t>
<t>Subsequent to these specifications being produced, use cases for locally significant civic address elements have emerged. These elements do not all readily fit existing elements, as recommended in <xref target="RFC5774"/>. These elements are also sufficiently domain-specific that they do not merit additions to the limited space available for globally recognized elements.
</t>
<t>The <xref target="RFC5139">XML format for civic addresses</xref> provides a mechanism that allows for the addition of standardized or privately understood elements. A similar facility for private extension is not provided for <xref target="RFC4776">the DHCP format</xref>, though new specifications are able to define new CAtypes (civic address types).
</t>
<t>A recipient of a civic address in either format currently has no option than to ignore elements that it does not understand. Where a recipient performs a translation between the two formats, this results in the unsupported elements being discarded. In order for a new extension to be useful to a recipient that performs translation, the recipient has to understand the extension and know how to correlate an XML element with a CAtype.
</t>
<t>This document defines a method that allows the specification of civic address elements with private or local significance. How these are defined and used in both XML and DHCP formats is described. This document also describes how a recipient can translate unsupported civic addresses between the two formats.
</t>
<t>The additions described in this document are backwardly compatible. Furthermore, they allow for a civic address to be translated without loss of information.
</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 civic 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>New elements are defined in a new <xref target="XMLNS">XML namespace</xref>. This is true of address elements with significance within private or localized domains, as well as those that are intended for global applicability.
</t>
<t>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 <spanx style="verb">http://devon.canals.org.uk/civic</spanx>.
</t>
<t>A civic address that includes the new "bridge" element is shown in <xref target="localcivic2"/>.
</t>
<figure anchor="localcivic2" title="Local Civic Object Example">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>An entity that receives this location information might not understand the locally specified 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.
</t>
<t>The address can be passed to other applications, such as a <xref target="RFC5222">LoST server</xref>, 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 <xref target="RFC5985">HELD</xref>, it can be included in a LoST request directly.
</t>
</section>
<section title="Translating Unsupported Elements">
<t>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.
</t>
<section title="DHCP to XML Format Translation">
<t>The registration of a new CAtype following the process in <xref target="RFC4776"/> means that a recipient is potentially unable to produce a complete XML representation of the DHCP civic address.
</t>
<t>To address this, a new <spanx style="verb">EXT</spanx> XML element is defined that allows the XML format to carry an unsupported CAtype without modification. This type extends the base civic address element type by adding a <spanx style="verb">CAtype</spanx> attribute that identifies the CAtype.
</t>
<t>For example, if CAtype 199 is defined, but not understood, this is carried in the XML format as shown in <xref target="exext"/>.
</t>
<figure anchor="exext" title="XML Civic Address with Unsupported Extension">
<artwork><![CDATA[
<civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:ext="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>UK</country>
<A1>Devon</A1>
<A3>Monkokehampton</A3>
<RD>Deckport</RD>
<STS>Cross</STS>
<ext:EXT CAtype="199">21451338</ext:EXT>
</civicAddress>
]]></artwork>
</figure>
<t>No facility is provided for the conversion of private or local use CAtypes when translating from DHCP to XML. Extensions for private or local use do not use new CAtypes. Private or local use extensions MUST be defined using the XML extension mechanism.
</t>
</section>
<section title="XML to DHCP Format Translation">
<t>Extensions to the XML format are defined in a new XML namespace. Extensions that have global applicability might have a specific CAtype allocated. Extensions that are only for private or local use have no corresponding CAtype and always use this translation mechanism.
</t>
<t>Unsupported extensions in the XML format can be added to a DHCP format civic address using two new elements: the Namespace CAtype and the Element CAtype.
</t>
<section title="Namespace CAtype">
<t>The "Namespace" CAtype (CAtype XX [IANA/RFC-Editor: please use assigned value]) provides the definition of an XML namespace and a corresponding namespace prefix. This is analogous to attributes beginning with <spanx style="verb">xmlns</spanx> in <xref target="XMLNS"/>.
</t>
<t>The <xref target="RFC5234">Abstract Backus-Naur Form (ABNF)</xref> for this CAtype uses a Unicode character as the basic element and borrows BNF definitions from <xref target="XMLNS"/>:
</t>
<figure><artwork type="abnf"><![CDATA[
ns-CAtype = Prefix "=" *UCHAR
UCHAR = <any Unicode character>
]]></artwork></figure>
<t>The Namespace CAtype is sent multiple times if elements from multiple namespaces are required.
</t>
</section>
<section title="Element CAtype">
<t>The "Element" CAtype (CAtype YY [IANA/RFC-Editor: please use assigned value]) conveys a single element and its value. The element name includes a namespace prefix, as bound by the "Namespace" CAtype, plus the local name from the corresponding XML element. This is followed by the value of the element. Prefix and local name are separated by a colon (<spanx style="verb">:</spanx>) as in <xref target="XMLNS"/>; element name and value are separated by an equals sign (<spanx style="verb">=</spanx>).
</t>
<t>The <xref target="RFC5234">Abstract Backus-Naur Form (ABNF)</xref> for this CAtype uses a Unicode character as the basic element and borrows BNF definitions for <spanx style="verb">Prefix</spanx> and <spanx style="verb">LocalPart</spanx> from <xref target="XMLNS"/>:
</t>
<figure><artwork type="abnf"><![CDATA[
element-CAtype = Prefix ":" LocalPart "=" *UCHAR
]]></artwork></figure>
<t>An Element CAtype that includes a prefix that has not been bound in a Namespace CAtype is ignored.
</t>
</section>
<section title="Conversion Constraints">
<t>This conversion only works for elements that have textual content and an optional <spanx style="verb">xml:lang</spanx> attribute. Elements with complex content or other attributes - aside from namespace bindings - MUST be ignored if they are not understood.
</t>
<t>A Namespace CAtype MUST precede the Element CAtype that uses the binding it defines. A Namespace CAtype MUST NOT reuse a prefix. To aid in client parsing and reduce the likelihood of server configuration errors, all Namespace CAtypes SHOULD proceed any Element CAtypes.
</t>
</section>
<section title="Conversion Example">
<figure anchor="extended" title="XML Example with Multiple Extensions">
<preamble>The following example civic address contains two private use extensions:</preamble>
<artwork><![CDATA[
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.net/ns/posts"
xmlns:ap="http://www.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>
]]></artwork>
</figure>
<figure anchor="localcivicdhcp" title="Converted DHCP Example with Multiple Extensions">
<preamble>Might be converted to the DHCP form as follows:</preamble>
<artwork><![CDATA[
country = US
CAtype[0] = en-US
CAtype[1] = CA
CAtype[XX] = post=http://postsoftheworld.net/ns/posts
CAtype[XX] = ap=http://www.example.com/airport/5.0
CAtype[YY] = post:lamp=2471
CAtype[YY] = post:pylon=AQ-374-4(c)
CAtype[YY] = ap:airport=LAX
CAtype[YY] = ap:terminal=Tom Bradley
CAtype[YY] = ap:concourse=G
CAtype[YY] = ap:gate=36B
]]></artwork>
</figure>
</section>
<section title="Migration to Registered Elements">
<t>An element that is initially added as a local extension might be recognized as being more widely applicable. In this case, a CAtype might be allocated for this extension. Depending on whether a client is aware of the CAtype allocation, they could convert the XML form differently. A recipient that understands a CAtype MUST treat the extended form as being semantically equivalent.
</t>
<t>For example, if the bridge element from the examples in <xref target="localcivic2"/> and <xref target="exext"/> is allocated a CAtype of 199, a recipient treats all of the four following forms as equivalent:
</t>
<figure><artwork><![CDATA[
<cdc:bridge
xmlns:cdc="http://devon.canals.org.uk/civic">
21451338
</cdc:bridge>
<ext:EXT CAtype="199"
xmlns:ext="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
21451338
</ext:EXT>
CAtype[XX] = canal=http://devon.canals.org.uk/civic
CAtype[YY] = canal:bridge=21451338
CAtype[199] = 21451338
]]></artwork></figure>
</section>
</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.</t>
<t>Security threats applicable to the civic address formats are described in <xref target="RFC4776"/> (DHCP) and <xref target="RFC5139"/> (XML).
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Two civic address types are registered for the DHCP format. An XML namespace and schema are registered for the XML format in accordance with guidelines in <xref target="RFC3688"/>.
</t>
<section title="CAtype Registration">
<t>This document registers two civic address types in the "CAtypes" registry established by <xref target="RFC4776"/>. The following CAtypes are added:
</t>
<texttable>
<ttcol>CAtype</ttcol><ttcol>NENA</ttcol><ttcol>PIDF</ttcol><ttcol>Description</ttcol><ttcol>Example</ttcol>
<c>XX</c><c>-</c><c>-</c><c>Namespace binding</c><c>ex=http://example.com/</c>
<c>YY</c><c>-</c><c>EXT</c><c>Qualified address element name and value</c><c>ex:ext=value</c>
</texttable>
<t>[[IANA/RFC-EDITOR: Please replace XX and YY with the allocated CAtype]]
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t hangText="URI:">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
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>Unsupported Civic Address Extension</title>
</head>
<body>
<h1>Namespace for Unsupported Civic Address Extension</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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found as the entirety of <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
</section>
<section anchor="schema" title="Unsupported Extension XML Schema">
<figure><artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:ext="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:ns:pidf:geopriv10:civicAddr"/>
<xs:element name="EXT" type="ext:caExtType"/>
<xs:complexType name="caExtType">
<xs:simpleContent>
<xs:extension base="ca:caType">
<xs:attribute name="CAtype" use="required">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork></figure>
</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 unintuitive.</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.4776.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.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.5234.xml"?>
<reference anchor="XML"
target="http://www.w3.org/TR/2008/REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="E." surname="Maler" fullname="Eve Maler">
<organization />
</author>
<author initials="F." surname="Yergeau" fullname="François Yergeau">
<organization />
</author>
<author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization />
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization />
</author>
<author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
<organization />
</author>
<date month="November" day="26" year="2008" />
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126" />
<format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-20081126" />
</reference>
<reference anchor="XMLNS"
target="http://www.w3.org/TR/2006/REC-xml-names11-20060816">
<front>
<title>Namespaces in XML 1.1 (Second Edition)</title>
<author initials="D." surname="Hollander" fullname="Dave Hollander">
<organization />
</author>
<author initials="A." surname="Layman" fullname="Andrew Layman">
<organization />
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization />
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization />
</author>
<date month="August" day="16" year="2006" />
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-names11-20060816" />
<format type="HTML" target="http://www.w3.org/TR/2006/REC-xml-names11-20060816" />
</reference>
</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>
<section title="Identifying EXT Elements in LoST Validation">
<t><xref target="RFC5222">LoST</xref> uses the name of civic address elements to identify them when validating the content of an address. An <spanx style="verb">EXT</spanx> element can appear multiple times, each one with a different <spanx style="verb">CAtype</spanx> attribute to distinguish it. In this case, a LoST response is unable to distinguish between one <spanx style="verb">EXT</spanx> element and another. In order to identify a specific <spanx style="verb">EXT</spanx> element, the CAtype is also needed.
</t>
<t>To deal with this problem, a set of pseudo-elements are defined. These pseudo-elements exist in the <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</spanx> namespace, like the <spanx style="verb">EXT</spanx> element, but are not defined in the corresponding schema. The local name of each of these elements is formed from the string <spanx style="verb">CAtype</spanx> plus the decimal value of the <spanx style="verb">CAtype</spanx> attribute. This pseudo-element name is included in addition to the <spanx style="verb">EXT</spanx> element name.
</t>
<t>For instance, a civic address might contain the following <spanx style="verb">EXT</spanx> elements:
</t>
<figure><artwork><![CDATA[
<ext:EXT CAtype="199">21451338</ext:EXT>
<ext:EXT CAtype="231">Rubbish</ext:EXT>
]]></artwork></figure>
<t>These can be identified in a LoST response as follows:</t>
<figure><artwork><![CDATA[
<locationValidation xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<valid>ext:EXT ext:CAtype199</valid>
<invalid>ext:EXT ext:CAtype231</invalid>
</locationValidation>
]]></artwork></figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:02:25 |