draft-ietf-geopriv-local-civic-09.txt   draft-ietf-geopriv-local-civic-10.txt 
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft CommScope Internet-Draft CommScope
Updates: 5222,4776 (if approved) M. Thomson Updates: 5222,4776 (if approved) M. Thomson
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: April 4, 2013 R. Barnes Expires: June 4, 2013 R. Barnes
BBN Technologies BBN Technologies
B. Rosen B. Rosen
NeuStar, Inc. NeuStar, Inc.
R. George R. George
Huawei Technologies Huawei Technologies
Oct 2012 Dec 2012
Specifying Civic Address Extensions in PIDF-LO Specifying Civic Address Extensions in PIDF-LO
draft-ietf-geopriv-local-civic-09 draft-ietf-geopriv-local-civic-10
Abstract Abstract
New fields are occasionally added to civic addresses. A backwardly- New fields are occasionally added to civic addresses. A backwardly-
compatible mechanism for adding civic address elements to the Geopriv compatible mechanism for adding civic address elements to the Geopriv
civic address format is described. A formal mechanism for handling civic address format is described. A formal mechanism for handling
unsupported extensions when translating between XML and DHCP civic unsupported extensions when translating between XML and DHCP civic
address forms is defined for entities that need to perform this address forms is defined for entities that need to perform this
translation. Intial extensions for some new elements are also translation. Intial extensions for some new elements are also
defined. The LoST (RFC5222) protocol mechanism that returns civic defined. The LoST (RFC5222) protocol mechanism that returns civic
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2013. This Internet-Draft will expire on June 4, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11 5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11
6. Using Local Civic Extension with the LoST Protocol . . . . . . 12 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. Registration Template . . . . . . . . . . . . . . . . . . 14 8.3. Registration Template . . . . . . . . . . . . . . . . . . 15
8.4. Registration of the CAtypes defined in this document . . . 15 8.4. Registration of the CAtypes defined in this document . . . 15
8.5. Registration Policy and Expert Guidance . . . . . . . . . 16 8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
8.6. URN sub-namespace registration . . . . . . . . . . . . . . 17 8.6. URN sub-namespace registration . . . . . . . . . . . . . . 17
8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17 8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Geopriv civic location specifications ([RFC4776], [RFC5139]) The Geopriv civic location specifications ([RFC4776], [RFC5139])
define an XML and binary representations for civic addresses that define an XML and binary representations for civic addresses that
skipping to change at page 5, line 24 skipping to change at page 5, line 24
localized domains, as well as those that are intended for global localized domains, as well as those that are intended for global
applicability. applicability.
New elements SHOULD use the basic "caType" schema type defined in New elements SHOULD use the basic "caType" schema type defined in
[RFC5139]. This type provides an optional "xml:lang" attribute. [RFC5139]. This type provides an optional "xml:lang" attribute.
For example, suppose the (fictitious) Central Devon Canals Authority For example, suppose the (fictitious) Central Devon Canals Authority
wishes to introduce a new civic element called "bridge". The wishes to introduce a new civic element called "bridge". The
authority defines an XML namespace that includes a "bridge" element. authority defines an XML namespace that includes a "bridge" element.
The namespace needs to be a unique URI, for example The namespace needs to be a unique URI, for example
"http://devon.canals.org.uk/civic". "http://devon.canals.example.com/civic".
A civic address that includes the new "bridge" element is shown in A civic address that includes the new "bridge" element is shown in
Figure 2. Figure 2.
<civicAddress xml:lang="en-GB" <civicAddress xml:lang="en-GB"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cdc="http://devon.canals.org.uk/civic"> xmlns:cdc="http://devon.canals.example.com/civic">
<country>UK</country> <country>UK</country>
<A1>Devon</A1> <A1>Devon</A1>
<A3>Monkokehampton</A3> <A3>Monkokehampton</A3>
<RD>Deckport</RD> <RD>Deckport</RD>
<STS>Cross</STS> <STS>Cross</STS>
<cdc:bridge>21451338</cdc:bridge> <cdc:bridge>21451338</cdc:bridge>
</civicAddress> </civicAddress>
skipping to change at page 6, line 34 skipping to change at page 6, line 34
defined only for the XML format; these extensions are then conveyed defined only for the XML format; these extensions are then conveyed
in DHCP using the extension element. in DHCP using the extension element.
Further extensions to the DHCP format are prohibited: these Further extensions to the DHCP format are prohibited: these
extensions cannot be safely conveyed in environments where conversion extensions cannot be safely conveyed in environments where conversion
is possible. is possible.
3.1. XML to DHCP Format Translation 3.1. XML to DHCP Format Translation
Extensions to the XML format [RFC5139] are defined in a new XML Extensions to the XML format [RFC5139] are defined in a new XML
namespace [XMLNS]. 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 prupose.
Extensions in the XML format can be added to a DHCP format civic Extensions in the XML format can be added to a DHCP format civic
address using an extension CAtype. address using an extension CAtype.
3.2. Extension Civic Address Type (CAtype) 3.2. Extension Civic Address Type (CAtype)
The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor:
please replace XX here and in Figure 3 and in Figure 5 with the please replace XX here and in Figure 3 and in Figure 5 with the
assigned code] includes three values that uniquely identify the XML assigned code] includes three values that uniquely identify the XML
extension and its value: a namespace URI, the local name of the XML extension and its value: a namespace URI, the local name of the XML
skipping to change at page 8, line 17 skipping to change at page 8, line 17
When converting to XML, the namespace prefix used for the extension When converting to XML, the namespace prefix used for the extension
element is selected by the entity that performs the conversion. element is selected by the entity that performs the conversion.
3.4. Conversion Example 3.4. Conversion Example
The following example civic address contains two extensions: The following example civic address contains two extensions:
<civicAddress xml:lang="en-US" <civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.net/ns" xmlns:post="http://postsoftheworld.example.com/ns"
xmlns:ap="http://example.com/airport/5.0"> xmlns:ap="http://example.com/airport/5.0">
<country>US</country> <country>US</country>
<A1>CA</A1> <A1>CA</A1>
<post:lamp>2471</post:lamp> <post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon> <post:pylon>AQ-374-4(c)</post:pylon>
<ap:airport>LAX</ap:airport> <ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal> <ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse> <ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate> <ap:gate>36B</ap:gate>
</civicAddress> </civicAddress>
Figure 4: XML Example with Multiple Extensions Figure 4: XML Example with Multiple Extensions
This is converted to a DHCP form as follows: This is converted to a DHCP form as follows:
country = US country = US
CAtype[0] = en-US CAtype[0] = en-US
CAtype[1] = CA CAtype[1] = CA
CAtype[XX] = http://postsoftheworld.net/ns lamp 2471 CAtype[XX] = http://postsoftheworld.example.com/ns lamp 2471
CAtype[XX] = http://postsoftheworld.net/ns pylon AQ-374-4(c) CAtype[XX] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
CAtype[XX] = http://example.com/airport/5.0 airport LAX 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 terminal Tom Bradley
CAtype[XX] = http://example.com/airport/5.0 concourse G CAtype[XX] = http://example.com/airport/5.0 concourse G
CAtype[XX] = http://example.com/airport/5.0 gate 36B CAtype[XX] = http://example.com/airport/5.0 gate 36B
Figure 5: Converted DHCP Example with Multiple Extensions Figure 5: Converted DHCP Example with Multiple Extensions
4. CAtypes Registry 4. CAtypes Registry
[RFC4776] created the CAtype registry. Among other things, this [RFC4776] created the CAtype registry. Among other things, this
registry advertised available civic elements. While it has always registry advertised available civic elements. While it has always
been possible to use an extension namespace to define civic elements been possible to use an extension namespace to define civic elements
that are not in the CAtype registry, and this document does not that are not in the CAtype registry, and this document does not
change that, the registry is valuable to alert implementors of change that, the registry is valuable to alert implementors of
skipping to change at page 13, line 35 skipping to change at page 13, line 35
<valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid> <valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>
<invalid>ca:PC</invalid> <invalid>ca:PC</invalid>
<unchecked>ca:HNO cae:MP cae:HNP</unchecked> <unchecked>ca:HNO cae:MP cae:HNP</unchecked>
</locationValidation> </locationValidation>
Figure 9: Corrected Location Validation Example Figure 9: Corrected Location Validation Example
7. Security Considerations 7. Security Considerations
This document defines a formal way to extend the existing Geopriv This document defines a formal way to extend the existing Geopriv
civic address schema. No security threats are introduced by this civic address schema. While no security threats are directly
document. 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 Security threats applicable to the civic address formats are
described in [RFC4776] (DHCP) and [RFC5139] (XML). described in [RFC4776] (DHCP) and [RFC5139] (XML).
8. IANA Considerations 8. IANA Considerations
This document alters the "CAtypes" registry on the "Civic Address This document alters the "CAtypes" registry on the "Civic Address
Types Registry" page established by [RFC4776]. Types Registry" page established by [RFC4776].
8.1. CAtype Registration for Extensions 8.1. CAtype Registration for Extensions
skipping to change at page 17, line 11 skipping to change at page 17, line 17
All registrations are reviewed to identify potential duplication All registrations are reviewed to identify potential duplication
between registered elements. Duplicated semantics are not prohibited between registered elements. Duplicated semantics are not prohibited
in the registry, though it is preferred if existing elements are in the registry, though it is preferred if existing elements are
used. The expert review is advised to recommend the use of existing used. The expert review is advised to recommend the use of existing
elements following the guidance in [RFC5774]. Any registration that elements following the guidance in [RFC5774]. Any registration that
is a duplicate or could be considered a close match for the semantics is a duplicate or could be considered a close match for the semantics
of an existing element SHOULD include a discussion of the reasons of an existing element SHOULD include a discussion of the reasons
that the existing element was not reused. 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.
8.6. URN sub-namespace registration 8.6. URN sub-namespace registration
This document calls for IANA to register a new XML namespace, as per This document calls for IANA to register a new XML namespace, as per
the guidelines in [RFC3688]. the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org),
James Winterbottom (james.Winterbottom@commscope.com) James Winterbottom (james.Winterbottom@commscope.com)
skipping to change at page 18, line 26 skipping to change at page 18, line 36
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. 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 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. 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, [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web "Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, Consortium Recommendation REC-xml-names11-20060816,
August 2006, August 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
10.2. Informative References 10.2. Informative References
[RFC4079] Peterson, J., "A Presence Architecture for the [RFC4079] Peterson, J., "A Presence Architecture for the
Distribution of GEOPRIV Location Objects", RFC 4079, Distribution of GEOPRIV Location Objects", RFC 4079,
 End of changes. 15 change blocks. 
21 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/