draft-ietf-geopriv-local-civic-10.txt   rfc6848.txt 
GEOPRIV J. Winterbottom Internet Engineering Task Force (IETF) J. Winterbottom
Internet-Draft CommScope Request for Comments: 6848 CommScope
Updates: 5222,4776 (if approved) M. Thomson Updates: 4776, 5222 M. Thomson
Intended status: Standards Track Skype Category: Standards Track Skype
Expires: June 4, 2013 R. Barnes ISSN: 2070-1721 R. Barnes
BBN Technologies BBN Technologies
B. Rosen B. Rosen
NeuStar, Inc. NeuStar, Inc.
R. George R. George
Huawei Technologies Huawei Technologies
Dec 2012 January 2013
Specifying Civic Address Extensions in PIDF-LO Specifying Civic Address Extensions in
draft-ietf-geopriv-local-civic-10 the Presence Information Data Format Location Object (PIDF-LO)
Abstract Abstract
New fields are occasionally added to civic addresses. A backwardly- New fields are occasionally added to civic addresses. A backward-
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. Initial extensions for some new elements are also
defined. The LoST (RFC5222) protocol mechanism that returns civic defined. The Location-to-Service Translation (LoST) protocol
address element names used for validation of location information is mechanism (defined in RFC 5222) that returns civic address element
clarified and is normatively updated to require a qualifying names used for validation of location information is clarified and is
namespace identifier on each civic address element returned as part normatively updated to require a qualifying namespace identifier on
of the validation process. each civic address element returned as part of the validation
process.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 4, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6848.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2013 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9
5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Milepost . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 13
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. Registration Template . . . . . . . . . . . . . . . . . . 15 8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . 18 8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
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
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
allow for the expression of civic addresses. Guidance for the use of allow for the expression of civic addresses. Guidance for the use of
these formats for the civic addresses in different countries is these formats for the civic addresses in different countries is
included in [RFC5774]. included in [RFC5774].
Subsequent to these specifications being produced, use cases for Subsequent to these specifications being produced, use cases for
extending the civic address format with new elements have emerged. extending the civic address format with new elements have emerged.
[RFC5774] describes a mechanism for mapping long-standing address [RFC5774] describes a mechanism for mapping long-standing address
formats into the civic address elements defined in [RFC4776] and formats into the civic address elements defined in [RFC4776] and
[RFC5139]. However, some of these existing address elements do not [RFC5139]. However, some of these existing address elements do not
readily fit into the civic address elements defined in [RFC4776] and readily fit into the civic address elements defined in [RFC4776] and
[RFC5139]. In these cases creating new civic address elements [RFC5139]. In these cases, creating new civic address elements
provides a better solution than overloading existing civic address provides a better solution than overloading existing civic address
fields which may cause confusion. fields, which may cause confusion.
The XML format for civic addresses [RFC5139] provides a mechanism The XML format for civic addresses [RFC5139] provides a mechanism
that allows for the addition of standardized or privately understood that allows for the addition of standardized or privately understood
elements. A similar facility for private extension is not provided elements. A similar facility for private extension is not provided
for the DHCP format [RFC4776], though new specifications are able to for the DHCP format [RFC4776], though new specifications are able to
define new CAtypes (civic address types). define new CAtypes (civic address types).
A recipient of a civic address in either format currently has no A recipient of a civic address in either format currently has no
option other than to ignore elements that it does not understand. option other than to ignore elements that it does not understand.
This results in any elements that are unknown to that recipient being This results in any elements that are unknown to that recipient being
discarded if a recipient performs a translation between the two discarded if a recipient performs a translation between the two
formats. In order for a new extension to be preserved through formats. In order for a new extension to be preserved through
translation by any recipient, the recipient has to understand the translation by any recipient, the recipient has to understand the
extension and know how to correlate an XML element with a CAtype. extension and know how to correlate an XML element with a CAtype.
This document describes how new civic address elements are added. This document describes how new civic address elements are added.
Extensions always starts with the definition of XML elements. A Extensions always start with the definition of XML elements. A
mechanism for carrying the extension in the DHCP format is described. mechanism for carrying the extension in the DHCP format is described.
A new XML namespace containing a small number of additional civic A new XML namespace containing a small number of additional civic
elements is also defined and can be used as a template to illustrate elements is also defined and can be used as a template to illustrate
how other extensions can be defined as required. how other extensions can be defined as required.
These mechanisms ensure that any translation between formats can be These mechanisms ensure that any translation between formats can be
performed consistently and without loss of information. Translation performed consistently and without loss of information. Translation
between formats can occur without knowledge of every extension that between formats can occur without knowledge of every extension that
is present. is present.
The registry of numeric CAtypes is modified so that creators of The registry of numeric CAtypes is modified so that the creators of
extensions can advertise new namespaces and the civic elements to extensions can advertise new namespaces and civic elements to
encourage maximum reuse. encourage maximum reuse.
The additions described in this document are backwardly compatible. The additions described in this document are backwardly compatible.
Existing implementations may cause extension information to be lost, Existing implementations may cause extension information to be lost,
but the presence of extensions does not affect an implementation that but the presence of extensions does not affect an implementation that
conforms to either [RFC4776] or [RFC5139]. conforms to either [RFC4776] or [RFC5139].
This document also normatively updates [RFC5222] to clarify that the This document also normatively updates [RFC5222] to clarify that the
namespace must be included with the element name in the lists of namespace must be included with the element name in the lists of
valid, invalid and not checked elements in the <locationValidation> valid, invalid, and not checked elements in the <locationValidation>
part of a LoST response. While the LoST schema does not need to be part of a Location-to-Service Translation (LoST) response. While the
changed, the example in the document is updated to show the LoST schema does not need to be changed, the example in the document
namespaces in the lists. is updated to show the namespaces in the lists.
1.1. Motivating Example 1.1. Motivating Example
One instance where translation might be necessary is where a device One instance where translation might be necessary is where a device
receives location configuration using DHCP [RFC4776]. Conversion of receives location configuration using DHCP [RFC4776]. Conversion of
DHCP information to an XML form is necessary if the device wishes to DHCP information to an XML form is necessary if the device wishes to
use the DHCP-provided information in a range of applications, use the DHCP-provided information in a range of applications,
including location-based presence services [RFC4079], and emergency including location-based presence services [RFC4079] and emergency
calling [RFC5012]. calling [RFC5012].
+--------+ +--------+ +-----------+ +--------+ +--------+ +-----------+
| DHCP | DHCP | Device | XML | Recipient | e.g., Presence | DHCP | DHCP | Device | XML | Recipient | e.g., Presence
| Server |--------->| |-------->| | Agent | Server |--------->| |-------->| | Agent
+--------+ +--------+ +-----------+ +--------+ +--------+ +-----------+
Figure 1: Conversion Scenario Figure 1: Conversion Scenario
The Device that performs the translation between the DHCP and XML 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. 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 Without knowledge of these extensions and how they are represented in
XML, the Device is forced to discard them. XML, the device is forced to discard them.
These extensions could be useful, or may be critical, to the ultimate These extensions could be useful, or may be critical, to the ultimate
consumers of this information. For instance, an extension element consumers of this information. For instance, an extension element
might provide a presence watcher with important information in might provide a presence watcher with important information in
locating the Device, or an extension might be significant in choosing locating the device, or an extension might be significant in choosing
a particular call route. a particular call route.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Specifying Civic Address Extensions 2. Specifying Civic Address Extensions
The civic schema in [RFC5139] defines an ordered structure of The civic schema in [RFC5139] defines an ordered structure of
elements that can be combined to describe a civic address. The XML 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 extension point at the end of this sequence is used to extend the
address. address.
New elements are defined in a new XML namespace [XMLNS]. This is New elements are defined in a new XML namespace [XMLNS]. This is
true of address elements with significance within private or true of address elements with significance within private or
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.example.com/civic". "http://devon.canals.example.com/civic".
skipping to change at page 6, line 6 skipping to change at page 6, line 6
understand the extension address element. As long as the added understand the extension address element. As long as the added
element is able to be safely ignored, the remainder of the civic 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 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 useful as it could be, but the added element does not prevent the use
of the remainder of the address. of the remainder of the address.
The address can be passed to other applications, such as a LoST The address can be passed to other applications, such as a LoST
server [RFC5222], without modification. If the application server [RFC5222], without modification. If the application
understands the added element(s), it is able to make use of that understands the added element(s), it is able to make use of that
information. For example, if this civic address is acquired using information. For example, if this civic address is acquired using
HELD [RFC5985], it can be included in a LoST request directly. HTTP-Enabled Location Delivery (HELD) [RFC5985], it can be included
in a LoST request directly.
3. Translating Unsupported Elements 3. Translating Unsupported Elements
Unsupported civic address elements can be carried without consequence Unsupported civic address elements can be carried without consequence
as long as the format of the address does not change. However, as long as the format of the address does not change. However,
conversion between formats has been shown to be necessary. conversion between formats has been shown to be necessary.
Format conversion required knowledge of the format of the address Format conversion requires knowledge of the format of the address
elements. An entity performing a conversion between XML and DHCP elements. An entity performing a conversion between XML and DHCP
address formats was forced to discard unrecognized elements. The address formats is forced to discard unrecognized elements. The
entity performing the conversion had no way to know the correct entity performing the conversion has no way to know the correct
element to use in the target format. element to use in the target format.
This document defines a single extension element for the DHCP format This document defines a single extension element for the DHCP format
that makes knowledge of extensions unnecessary during conversion. that makes knowledge of extensions unnecessary during conversion.
This extension element relies on the extension mechanisms defined for This extension element relies on the extension mechanisms defined for
the XML format. New extensions to the civic address format MUST be the XML format. New extensions to the civic address format MUST be
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]. The XML namespace received in DHCP is expressed namespace [XMLNS]. The XML namespace received in DHCP is expressed
as a URL, however, it should not be dereferenced or treated as a 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 source location for the actual schema and doing so will serve no
useful prupose. useful purpose.
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 40) includes three values that
please replace XX here and in Figure 3 and in Figure 5 with the uniquely identify the XML extension and its value: a namespace URI,
assigned code] includes three values that uniquely identify the XML the local name of the XML element, and the text content of that
extension and its value: a namespace URI, the local name of the XML element. These three values are all included in the value of the
element, and the text content of that element. These three values CAtype, each separated by a single whitespace character.
are all included in the value of the CAtype, each separated by a
single whitespace character.
0 1 2 3 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 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 ... . | CAtype (40) | Length | Namespace URI ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Namespace URI (continued) . . Namespace URI (continued) .
. ... . . ... .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | XML element local name . | Space (U+20) | XML element local name .
+---------------+ . +---------------+ .
. ... . . ... .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space (U+20) | Extension type value . | Space (U+20) | Extension type value .
+---------------+ . +---------------+ .
. ... . . ... .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: XML Civic Address Extension CAtype Figure 3: XML Civic Address Extension CAtype
CAtype (XX) identifies the extension CAtype. CAtype (40) identifies the extension CAtype.
Length is the number of octets used to represent the namespace URI, Length is the number of octets used to represent the namespace URI,
local name and value. local name, and value. The length includes the space between the
namespace URI and local name and the space between the local name and
value fields.
The content of a CAtype (after the CAtype code and length) is UTF-8 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. encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed.
Octets consumed by the namespace URI and local name reduce the space Octets consumed by the namespace URI and local name reduce the space
available for values. available for values.
This conversion only works for elements that have textual content and This conversion only works for elements that have textual content and
an optional "xml:lang" attribute. Elements with complex content or an optional "xml:lang" attribute. Elements with complex content or
other attributes - aside from namespace bindings - MUST be ignored if other attributes -- aside from namespace bindings -- MUST be ignored
they are not understood. if they are not understood.
3.3. DHCP to XML Format Translation 3.3. DHCP to XML Format Translation
The registration of a new CAtype following the process in [RFC4776] The registration of a new CAtype following the process in [RFC4776]
means that a recipient that does not know the equivalent XML is means that a recipient that does not know the equivalent XML is
unable to produce a complete XML representation of the DHCP civic unable to produce a complete XML representation of the DHCP civic
address. For this reason, this document ends the registration of new address. For this reason, this document ends the registration of new
numeric CAtypes. No new registrations of numeric CAtypes can be numeric CAtypes. No new registrations of numeric CAtypes can be
made. made.
In lieu of making new numerical CAtype assignments, this document In lieu of making new numerical CAtype assignments, this document
creates a new extensionCA type which is defined in a manner that lets creates a new extensionCA type that is defined in a manner that lets
new civic elements be described in DHCP form by carrying the name new civic elements be described in DHCP form by carrying the
space and type name of the extension in parameters of the extensionCA namespace and type name of the extension in parameters of the
type. extensionCA type.
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"
skipping to change at page 8, line 38 skipping to change at page 8, line 41
<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.example.com/ns lamp 2471 CAtype[40] = http://postsoftheworld.example.com/ns lamp 2471
CAtype[XX] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c) CAtype[40] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c)
CAtype[XX] = http://example.com/airport/5.0 airport LAX CAtype[40] = http://example.com/airport/5.0 airport LAX
CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley CAtype[40] = http://example.com/airport/5.0 terminal Tom Bradley
CAtype[XX] = http://example.com/airport/5.0 concourse G CAtype[40] = http://example.com/airport/5.0 concourse G
CAtype[XX] = http://example.com/airport/5.0 gate 36B CAtype[40] = 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
commonly used civic elements and provides guidance to clients of what commonly used civic elements and provides guidance to clients of what
elements they should suppport. elements they should support.
This document alters the CAtype registry in several ways. It closes This document alters the CAtype registry in several ways. It closes
the registry to new numeric CAtypes. It deletes the "NENA" column, the registry to new numeric CAtypes. It deletes the "NENA" column,
which is not needed. It adds columns for a namespace and contact, which is not needed. It adds columns for a namespace and contact,
and changes the name of the column currently called "PIDF" to "Local and changes the name of the column currently called "PIDF" to "Local
Name". It also adds a column to the registry called "Type". "Type" Name". It also adds a column to the registry called "Type". "Type"
can have one of two values "A" and "B". Type A elements are intended can have one of two values "A" and "B". Type A elements are intended
for wide use with many applications and SHOULD be implemented by all for wide use with many applications and SHOULD be implemented by all
clients unless the client is certain the element will not be clients unless the client is certain the element will not be
encountered. Type "B" civic elements MAY be implemented by any encountered. Type B civic elements MAY be implemented by any client.
client.
Type A civic elements require IETF review, while Type B elements only Type A civic elements require IETF review, while Type B elements only
require an expert review. require an expert review.
5. Civic Extensions 5. Civic Extensions
We use this new extension method to define some additional civic We use this new extension method to define some additional civic
address elements which are needed to correctly encode civic locations address elements that are needed to correctly encode civic locations
in several countries. The definition of these new civic address in several countries. The definition of these new civic address
elements also serves as an example of how to define additional elements also serves as an example of how to define additional
elements using the mechanisms described in this document. elements using the mechanisms described in this document.
5.1. Pole Number 5.1. Pole Number
In some areas, utility and lamp posts carry a unique identifier, In some areas, utility and lamp posts carry a unique identifier,
which we call a pole number in this document. In some countries, the which we call a pole number in this document. In some countries, the
label on the lamp post also carries the local emergency service label on the lamp post also carries the local emergency service
number, such as "110", encouraging callers to use the pole number to number, such as "110", encouraging callers to use the pole number to
skipping to change at page 10, line 27 skipping to change at page 10, line 27
|-| | 1 | '---------' |-| | 1 | '---------'
| |\ | 0 | | |\ | 0 |
| | \ | 1 | | | \ | 1 |
| | \ | 4 | | | \ | 4 |
| | \|,,,| | | \|,,,|
_ | | _ | |
``-..|.| ``-..|.|
``--.._ ``--.._
`'--.._ `'--.._
Figure 6: Lamp post with emergency number Figure 6: Lamp Post with Emergency Number
5.2. Mile Post 5.2. Milepost
On some roads, trails, railroad rights of way and other linear On some roads, trails, railroad rights of way, and other linear
features, a post with a mile or kilometer distance from one end of 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 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 poles or markers with numeric indications that are not the same as a
"house number" or street address number. "house number" or street address number.
5.3. Street Type Prefix 5.3. Street Type Prefix
The civic schema defined in [RFC5139] allows the definition of The civic schema defined in [RFC5139] allows the definition of
address "123 Colorado Boulevard", but it does not allow for the easy address "123 Colorado Boulevard", but it does not allow for the easy
expression of "123 Boulevard Colorado". Adding a street-type prefix, expression of "123 Boulevard Colorado". Adding a street type prefix,
allows street named in this manner to be more easily represented. allows a street named in this manner to be more easily represented.
5.4. House Number Prefix 5.4. House Number Prefix
The civic schema defined in [RFC5139] provides house number suffix The civic schema defined in [RFC5139] provides a house number suffix
element, allowing one to express an address like "123A Main Street", element, allowing one to express an address like "123A Main Street",
but it does not contain a corresponding house number prefix. The but it does not contain a corresponding house number prefix. The
house number prefix element allows the expression of address such as house number prefix element allows the expression of address such as
"Z123 Main Street". "Z123 Main Street".
5.5. XML Extension Schema 5.5. XML Extension Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"
skipping to change at page 11, line 24 skipping to change at page 11, line 24
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/> <xs:import namespace="urn:ietf:params:xml:pidf:geopriv10:civicAddr"/>
<!-- Post Number --> <!-- Post Number -->
<xs:element name="PN" type="ca:caType"/> <xs:element name="PN" type="ca:caType"/>
<!-- Milepost --> <!-- Milepost -->
<xs:element name="MP" type="ca:caType"/> <xs:element name="MP" type="ca:caType"/>
<!-- Street-Type prefix --> <!-- Street Type Prefix -->
<xs:element name="STP" type="ca:caType"/> <xs:element name="STP" type="ca:caType"/>
<!-- House Number Prefix --> <!-- House Number Prefix -->
<xs:element name="HNP" type="ca:caType"/> <xs:element name="HNP" type="ca:caType"/>
</xs:schema> </xs:schema>
5.6. Extension examples 5.6. Extension Examples
<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:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country> <country>US</country>
<A1>CA</A1> <A1>CA</A1>
<A2>Sacramento</A2> <A2>Sacramento</A2>
<RD>I5</RD> <RD>I5</RD>
<cae:MP>248</cae:MP> <cae:MP>248</cae:MP>
<cae:PN>22-109-689</cae:PN> <cae:PN>22-109-689</cae:PN>
</civicAddress> </civicAddress>
XML Example with Post Number and Mile Post Figure 7: XML Example with Post Number and Milepost
<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:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<country>US</country> <country>US</country>
<A1>CA</A1> <A1>CA</A1>
<A2>Sacramento</A2> <A2>Sacramento</A2>
<RD>Colorado</RD> <RD>Colorado</RD>
<HNO>223</HNO> <HNO>223</HNO>
<cae:STP>Boulevard</cae:STP> <cae:STP>Boulevard</cae:STP>
<cae:HNP>A</cae:HNP> <cae:HNP>A</cae:HNP>
</civicAddress> </civicAddress>
XML Example with Street prefix and House Number Prefix Figure 8: XML Example with Street Type Prefix and House Number Prefix
6. Using Local Civic Extension with the LoST Protocol 6. Using Local Civic Extension with the LoST Protocol
One critical use of civic location information is in next generation One critical use of civic location information is in next generation
emergency services applications, in particular call routing emergency services applications, in particular, call routing
applications. In such cases location information is provided to a applications. In such cases, location information is provided to a
location-based routing service using the location to service location-based routing service using the LoST protocol [RFC5222].
transtion (LoST) protcol [RFC5222]. LoST is used to provide call LoST is used to provide call routing information, but it is also used
routing information, but it is also used to validate location to validate location information to ensure that it can route to an
information to ensure that it can route to an emergency center when emergency center when required.
required.
LoST is an XML-based protocol and so the namespace extension LoST is an XML-based protocol, and so the namespace extension
mechansims described in this document do not impact LoST. When LoST mechanisms described in this document do not impact LoST. When LoST
is used for validation a <locationValidation> element is returned is used for validation, a <locationValidation> element is returned
containing a list of valid, a list of invalid, and a list of containing a list of valid, a list of invalid, and a list of
unchecked civic elements. Figure 7 is an extract of the validation unchecked civic elements. Figure 9 is an extract of the validation
response in Figure 6 from [RFC5222]. response in Figure 6 from [RFC5222].
<locationValidation> <locationValidation>
<valid>country A1 A3 A6</valid> <valid>country A1 A3 A6</valid>
<invalid>PC</invalid> <invalid>PC</invalid>
<unchecked>HNO</unchecked> <unchecked>HNO</unchecked>
</locationValidation> </locationValidation>
Figure 7: Location Validation Example from LoST (RFC5222) Figure 9: Location Validation Example from LoST (RFC5222)
The RelaxNG schema in [RFC5222] requires the elements in each of The RelaxNG schema in [RFC5222] requires the elements in each of
these lists to be namespace qualified, which makes the example in these lists to be namespace qualified, which makes the example in
Figure 6 from [RFC5222] in error. This issue is especially Figure 6 of [RFC5222] erroneous. This issue is especially
significant when local-civic extensions are used as the domain to significant when local-civic extensions are used as the domain to
which the extensions are attributed may impact their interpretation which the extensions are attributed may impact their interpretation
by the server or client. To ensure that local-civic extensions do by the server or client. To ensure that local-civic extensions do
not cause issues with LoST server and client implementations, all not cause issues with the LoST server and client implementations, all
elements listed in a <valid>, <invalid>, or <unchecked> element MUST elements listed in a <valid>, <invalid>, or <unchecked> element MUST
be qualified with a namespace. To illustrate this the extract above be qualified with a namespace. To illustrate this, the extract above
from figure 6 in [RFC5222] becomes Figure 8. from Figure 6 in [RFC5222] becomes Figure 10.
<locationValidation <locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<valid>ca:country ca:A1 ca:A3 ca:A6</valid> <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
<invalid>ca:PC</invalid> <invalid>ca:PC</invalid>
<unchecked>ca:HNO</unchecked> <unchecked>ca:HNO</unchecked>
</locationValidation> </locationValidation>
Figure 8: Corrected Location Validation Example Figure 10: Corrected Location Validation Example
If a validation request has also included the extensions defined in If a validation request has also included the extensions defined in
section Section 5 then the validation response would look like Section 5, then the validation response would look like Figure 11.
Figure 9.
<locationValidation <locationValidation
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext"> xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">
<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 11: 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. While no security threats are directly civic address schema. While no security threats are directly
introduced by this document, creators of new civic address extensions 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 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 environments in which these new elements will be used. New elements
should only be registered if the person or organization performing should only be registered if the person or organization performing
the registration understands any associated risks. 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 in the Civic Address
Types Registry" page established by [RFC4776]. Types Registry established by [RFC4776].
8.1. CAtype Registration for Extensions 8.1. CAtype Registration for Extensions
IANA has allocated a CAtype code of XX for the extension CAtype. IANA has allocated a CAtype code of 40 for the extension CAtype.
Registrations using this code will be made below, in Section 8.4. Registrations using this code will be made below, in Section 8.4.
8.2. Changes to the CAtype Registry 8.2. Changes to the CAtype Registry
IANA is asked to make the following changes to the CAtype registry: IANA has made the following changes to the CAtype registry:
o No registrations of new CAtype numbers in the Civic Address Types o No registrations of new CAtype numbers in the Civic Address Types
Registry are permitted, except by IESG Approval [RFC5226] under Registry are permitted, except by IESG Approval [RFC5226] under
unusual circumstances. unusual circumstances.
o The following note will be placed in the header of the CAtypes o The following note has been placed in the header of the CAtypes
registry, above the table: registry, above the table:
Note: As specified in [[this RFC]], new registrations are only Note: As specified in RFC 6848, new registrations are only
accepted for CAtype XX, using the template specified in accepted for CAtype 40, using the template specified in
Section 8.3. Section 8.3.
o The registration procedures are changed: IETF Review (if Type=A), o The registration procedures are changed: IETF Review (if Type=A),
Expert Review (if Type=B). The designated expert is unchanged. Expert Review (if Type=B). The designated expert is unchanged.
o The reference for the table is changed: [RFC4776], [[this RFC]] o The reference for the table is changed: [RFC4776], RFC 6848
o The column called "NENA" is removed. o The column called "NENA" is removed.
o The column called "PIDF" is renamed to "Local Name". o The column called "PIDF" is renamed to "Local Name".
o New columns are added named "Namespace URI", "Contact", "Schema" o New columns are added named "Namespace URI", "Contact", "Schema"
and "Type". All existing entries will have the following values and "Type". All existing entries will have the following values
for those new columns: for those new columns:
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
skipping to change at page 15, line 11 skipping to change at page 14, line 48
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Type: A Type: A
8.3. Registration Template 8.3. Registration Template
New registrations in the Civic Address Types Registry require the New registrations in the Civic Address Types Registry require the
following information: following information:
CAtype: The assigned numeric CAtype. All new registrations will use CAtype: The assigned numeric CAtype. All new registrations will use
the value XX. the value 40.
Namespace URI: A unique identifier for the XML namespace used for Namespace URI: A unique identifier for the XML namespace used for
the extension element. the extension element.
Local Name: The local name of an XML element that carries the civic Local Name: The local name of an XML element that carries the civic
address element. address element.
Description: A brief description of the semantics of the civic Description: A brief description of the semantics of the civic
address element. address element.
skipping to change at page 15, line 36 skipping to change at page 15, line 25
Specification (optional): A reference to a specification for the Specification (optional): A reference to a specification for the
civic address element. civic address element.
Schema (optional): A reference to a formal schema (XML schema, Schema (optional): A reference to a formal schema (XML schema,
RelaxNG, or other form) that defines the extension. RelaxNG, or other form) that defines the extension.
Type: "A" or "B". Type: "A" or "B".
If Type is "A", all clients SHOULD implement this element. If If Type is "A", all clients SHOULD implement this element. If
Type is "B", clients MAY implement this element. Type is "B", clients MAY implement this element.
8.4. Registration of the CAtypes defined in this document 8.4. Registration of the CAtypes Defined in this Document
This section registers the following four new CATypes in the Civic This section registers the following four new CAtypes in the Civic
Address Types Registry. Address Types Registry.
Post Number (see Section 5.1): Post Number (see Section 5.1):
CAtype: XX CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: PN Local Name: PN
Description: Post number that is attributed to a lamp post or Description: Post number that is attributed to a lamp post or
utility pole. utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org) (geopriv@ietf.org)
Specification: RFC 6848, Section 5
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A Type: A
Mile Post (see Section 5.2): Milepost (see Section 5.2):
CAtype: XX CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP Local Name: MP
Description: Mile Post a marker indicating distance to or from a Description: Milepost: a marker indicating distance to or from a
place (often a town). place (often a town).
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org) (geopriv@ietf.org)
Specification: [[this RFC]], Section 5 Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A Type: A
Street Type Prefix (see Section 5.3): Street Type Prefix (see Section 5.3):
CAtype: XX CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP Local Name: STP
Description: Street Type Prefix. Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org) (geopriv@ietf.org)
Specification: [[this RFC]], Section 5 Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A Type: A
House Number Prefix (see Section 5.4): House Number Prefix (see Section 5.4):
CAtype: XX CAtype: 40
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP Local Name: HNP
Description: House Number Prefix. Description: House Number Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org) (geopriv@ietf.org)
Specification: [[this RFC]], Section 5 Specification: RFC 6848, Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A Type: A
8.5. Registration Policy and Expert Guidance 8.5. Registration Policy and Expert Guidance
The "CAtypes" registry is altered to operate on a registration policy The "CAtypes" registry is altered to operate on a registration policy
of "Expert Review", and optionally "Specification Required" [RFC5226] of "Expert Review", and optionally "Specification Required" [RFC5226]
if the element being registered has a Type value of "B". if the element being registered has a Type value of "B".
The registration rules for "Specification Required" are followed only The registration rules for "Specification Required" are followed only
if a registration includes a reference to a specification. if a registration includes a reference to a specification.
Registrations can be made without a specification reference. Registrations can be made without a specification reference.
If the element being registered has a Type value of "A" then the If the element being registered has a Type value of "A", then the
registration policy is "IETF Review" [RFC5226]. registration policy is "IETF Review" [RFC5226].
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 [RFC6280] provides a comprehensive framework concerning the privacy
of location information as pertaining to its use in Internet of location information as pertaining to its use in Internet
applications. The expert reviewer is asked to keep the spirit of applications. The expert reviewer is asked to keep the spirit of
this document in mind when reviewing new CAtype registrations. 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 IANA has registered a new XML namespace, as per the guidelines in
the guidelines in [RFC3688]. [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)
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>GEOPRIV Civic Address Extensions</title> <title>GEOPRIV Civic Address Extensions</title>
</head> </head>
<body> <body>
<h1>Additional Fields for GEOPRIV Civic Address</h1> <h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6848.txt">
RFC 6848</a>.</p>
</body> </body>
</html> </html>
END END
8.7. XML Schema Registration 8.7. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688] [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext URI: urn:ietf:params:xml:schema: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)
XML: The XML for this schema can be found as the entirety of XML: The XML for this schema can be found as the entirety of
Section 5.5 of this document. Section 5.5 of this document.
9. Acknowledgements 9. Acknowledgements
Thanks to anyone who has tried to extend the civic schema and found Thanks to anyone who has tried to extend the civic schema and found
it a little less than intuitive. it a little less than intuitive.
skipping to change at page 19, line 49 skipping to change at page 20, line 16
James Winterbottom James Winterbottom
CommScope CommScope
Suit 1, Level 2 Suit 1, Level 2
iC Enterprise 1, Innovation Campus iC Enterprise 1, Innovation Campus
Squires Way Squires Way
North Wollongong, NSW 2500 North Wollongong, NSW 2500
AU AU
Phone: +61 242 212938 Phone: +61 242 212938
Email: james.winterbottom@commscope.com EMail: james.winterbottom@commscope.com
Martin Thomson Martin Thomson
Skype Skype
3210 Porter Drive 3210 Porter Drive
Palo Alto, California 94304 Palo Alto, CA 94304
US US
Email: martin.thomson@gmail.com EMail: martin.thomson@gmail.com
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Parkway 9861 Broken Land Parkway
Columbia, MD 21046 Columbia, MD 21046
US US
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com EMail: rbarnes@bbn.com
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US US
Email: br@brianrosen.net EMail: br@brianrosen.net
Robins George Robins George
Huawei Technologies Huawei Technologies
Huawei Base, Bantian, Longgan District Huawei Base, Bantian, Longgan District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P. R. China P. R. China
Phone: +86 755 2878 8314 Phone: +86 755 2878 8314
Email: robinsgv@gmail.com EMail: robinsgv@gmail.com
 End of changes. 95 change blocks. 
154 lines changed or deleted 149 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/