GEOPRIV J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: April 25, 2011 R. Barnes
BBN Technologies
October 22, 2010
Specifying Local Civic Address Fields in PIDF-LO
draft-winterbottom-geopriv-local-civic-03
Abstract
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.
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 April 25, 2011.
Copyright Notice
Copyright (c) 2010 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
Winterbottom, et al. Expires April 25, 2011 [Page 1]
Internet-Draft Local Civic October 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specifying Local Civic Elements . . . . . . . . . . . . . . . 4
4. Translating Unsupported Elements . . . . . . . . . . . . . . . 5
4.1. DHCP to XML Format Translation . . . . . . . . . . . . . . 5
4.2. XML to DHCP Format Translation . . . . . . . . . . . . . . 5
4.2.1. Namespace CAtype . . . . . . . . . . . . . . . . . . . 6
4.2.2. Element CAtype . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Conversion Constraints . . . . . . . . . . . . . . . . 6
4.2.4. Conversion Example . . . . . . . . . . . . . . . . . . 7
4.2.5. Migration to Registered Elements . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. CAtype Registration . . . . . . . . . . . . . . . . . . . 8
6.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 9
6.3. XML Schema Registration . . . . . . . . . . . . . . . . . 10
7. Unsupported Extension XML Schema . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Identifying EXT Elements in LoST Validation . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Winterbottom, et al. Expires April 25, 2011 [Page 2]
Internet-Draft Local Civic October 2010
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 in most countries.
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
locally significant civic address elements have emerged. These
elements do not all readily fit existing elements, as recommended in
[RFC5774]. These elements are also sufficiently domain-specific that
they do not merit additions to the limited space available for
globally recognized elements.
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 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.
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.
The additions described in this document are backwardly compatible.
Furthermore, they allow for a civic address to be translated without
loss of information.
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. Expires April 25, 2011 [Page 3]
Internet-Draft Local Civic October 2010
3. Specifying Local Civic Elements
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 bottom of the schema is used to include
address elements of local significance into the main civic body.
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.
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.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: Local Civic Object Example
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.
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.
Winterbottom, et al. Expires April 25, 2011 [Page 4]
Internet-Draft Local Civic October 2010
4. 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.
4.1. DHCP to XML Format Translation
The registration of a new CAtype following the process in [RFC4776]
means that a recipient is potentially unable to produce a complete
XML representation of the DHCP civic address.
To address this, a new "EXT" 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 "CAtype"
attribute that identifies the CAtype.
For example, if CAtype 199 is defined, but not understood, this is
carried in the XML format as shown in Figure 2.
<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>
Figure 2: XML Civic Address with Unsupported Extension
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.
4.2. XML to DHCP Format Translation
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
Winterbottom, et al. Expires April 25, 2011 [Page 5]
Internet-Draft Local Civic October 2010
have no corresponding CAtype and always use this translation
mechanism.
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.
4.2.1. Namespace CAtype
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 "xmlns" in [XMLNS].
The Abstract Backus-Naur Form (ABNF) [RFC5234] for this CAtype uses a
Unicode character as the basic element and borrows BNF definitions
from [XMLNS]:
ns-CAtype = Prefix "=" *UCHAR
UCHAR = <any Unicode character>
The Namespace CAtype is sent multiple times if elements from multiple
namespaces are required.
4.2.2. Element CAtype
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 (":") as in [XMLNS]; element name and value are separated by
an equals sign ("=").
The Abstract Backus-Naur Form (ABNF) [RFC5234] for this CAtype uses a
Unicode character as the basic element and borrows BNF definitions
for "Prefix" and "LocalPart" from [XMLNS]:
element-CAtype = Prefix ":" LocalPart "=" *UCHAR
An Element CAtype that includes a prefix that has not been bound in a
Namespace CAtype is ignored.
4.2.3. Conversion Constraints
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
Winterbottom, et al. Expires April 25, 2011 [Page 6]
Internet-Draft Local Civic October 2010
they are not understood.
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.
4.2.4. Conversion Example
The following example civic address contains two private use
extensions:
<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>
Figure 3: XML Example with Multiple Extensions
Might be converted to the DHCP form as follows:
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
Figure 4: Converted DHCP Example with Multiple Extensions
Winterbottom, et al. Expires April 25, 2011 [Page 7]
Internet-Draft Local Civic October 2010
4.2.5. Migration to Registered Elements
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.
For example, if the bridge element from the examples in Figure 1 and
Figure 2 is allocated a CAtype of 199, a recipient treats all of the
four following forms as equivalent:
<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
5. Security Considerations
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 the civic address formats are
described in [RFC4776] (DHCP) and [RFC5139] (XML).
6. IANA Considerations
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 [RFC3688].
6.1. CAtype Registration
This document registers two civic address types in the "CAtypes"
registry established by [RFC4776]. The following CAtypes are added:
Winterbottom, et al. Expires April 25, 2011 [Page 8]
Internet-Draft Local Civic October 2010
+--------+------+------+-------------------+------------------------+
| CAtype | NENA | PIDF | Description | Example |
+--------+------+------+-------------------+------------------------+
| XX | - | - | Namespace binding | ex=http://example.com/ |
| YY | - | EXT | Qualified address | ex:ext=value |
| | | | element name and | |
| | | | value | |
+--------+------+------+-------------------+------------------------+
[[IANA/RFC-EDITOR: Please replace XX and YY with the allocated
CAtype]]
6.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext", as per the
guidelines in [RFC3688].
urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com).
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
Winterbottom, et al. Expires April 25, 2011 [Page 9]
Internet-Draft Local Civic October 2010
6.3. XML Schema Registration
This section registers an XML schema 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@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Section 7 of this document.
7. Unsupported Extension XML Schema
<?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>
Winterbottom, et al. Expires April 25, 2011 [Page 10]
Internet-Draft Local Civic October 2010
8. Acknowledgements
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.
9. References
9.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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[XML] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web Consortium
Recommendation REC-xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[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>.
9.2. Informative References
[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
Winterbottom, et al. Expires April 25, 2011 [Page 11]
Internet-Draft Local Civic October 2010
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.
Appendix A. Identifying EXT Elements in LoST Validation
LoST [RFC5222] uses the name of civic address elements to identify
them when validating the content of an address. An "EXT" element can
appear multiple times, each one with a different "CAtype" attribute
to distinguish it. In this case, a LoST response is unable to
distinguish between one "EXT" element and another. In order to
identify a specific "EXT" element, the CAtype is also needed.
To deal with this problem, a set of pseudo-elements are defined.
These pseudo-elements exist in the
"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" namespace, like
the "EXT" element, but are not defined in the corresponding schema.
The local name of each of these elements is formed from the string
"CAtype" plus the decimal value of the "CAtype" attribute. This
pseudo-element name is included in addition to the "EXT" element
name.
For instance, a civic address might contain the following "EXT"
elements:
<ext:EXT CAtype="199">21451338</ext:EXT>
<ext:EXT CAtype="231">Rubbish</ext:EXT>
These can be identified in a LoST response as follows:
<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>
Winterbottom, et al. Expires April 25, 2011 [Page 12]
Internet-Draft Local Civic October 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
Winterbottom, et al. Expires April 25, 2011 [Page 13]