draft-ietf-geopriv-local-civic-07.txt   draft-ietf-geopriv-local-civic-08.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: April 4, 2013 R. Barnes Expires: April 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 Oct 2012
Specifying Civic Address Extensions in PIDF-LO Specifying Civic Address Extensions in PIDF-LO
draft-ietf-geopriv-local-civic-07 draft-ietf-geopriv-local-civic-08
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 2, line 19 skipping to change at page 2, line 19
(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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4
3. Translating Unsupported Elements . . . . . . . . . . . . . . . 7 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6
3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 7 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 7 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 8 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8
4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 9 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8
5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 11 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10
5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 11 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10
5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 12 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11
5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 12 5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11
6. Using Local Civic Extension with the LoST Protocol . . . . . . 13 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CAtype Registration for Extensions . . . . . . . . . . . . 15 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14
8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 15 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14
8.3. URN sub-namespace registration for 8.3. Registration Template . . . . . . . . . . . . . . . . . . 14
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 15 8.4. Registration of the CAtypes defined in this document . . . 15
8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 16 8.5. Registration Policy and Expert Guidance . . . . . . . . . 16
8.5. Registration Template . . . . . . . . . . . . . . . . . . 16 8.6. URN sub-namespace registration . . . . . . . . . . . . . . 17
8.5.1. Registration of the schema defined in this document . 17 8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 17
8.6. Registration Policy and Expert Guidance . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 7, line 8 skipping to change at page 6, line 8
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. 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
only as long as the format of the address does not change. When as long as the format of the address does not change. However,
converting between the XML and DHCP formats, these unsupported conversion between formats has been shown to be necessary.
elements are necessarily discarded: the entity performing the
translation has no way to know the correct element to use in the
target format.
All extensions MUST be defined using the mechanism described in this Format conversion required knowledge of the format of the address
document. Extensions that use numeric CAtypes or other mechanisms elements. An entity performing a conversion between XML and DHCP
cannot be safely translated between XML and DHCP representations. address formats was forced to discard unrecognized elements. The
entity performing the conversion had no way to know the correct
element to use in the target format.
An entity that does not support these extension mechanisms is This document defines a single extension element for the DHCP format
expected to remove elements it doesn't understand when performing that makes knowledge of extensions unnecessary during conversion.
conversions. This extension element relies on the extension mechanisms defined for
the XML format. New extensions to the civic address format MUST be
defined only for the XML format; these extensions are then conveyed
in DHCP using the extension element.
Further extensions to the DHCP format are prohibited: these
extensions cannot be safely conveyed in environments where conversion
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].
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)
skipping to change at page 15, line 8 skipping to change at page 14, line 8
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
IANA has allocated a CAtype code of XX for the extension CAtype. IANA has allocated a CAtype code of XX for the extension CAtype.
Registrations using this code will be made below, in Section 8.4.
[[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]
8.2. Changes to the CAtype Registry 8.2. Changes to the CAtype Registry
No further registration of numeric CAtypes in the Civic Address Types IANA ia asked to make the following changes to the CAtype registry:
Registry is permitted.
The column called "NENA" is removed.
The column called "PIDF" is renamed to "Local Name".
New columns are added named "Namespace URI", "Contact", "Schema" and
"Type".
New registrations use the registration template in Section 8.5. o No registrations of new CAtype numbers in the Civic Address Types
Registry are permitted, except by IESG Approval [RFC5226] under
unusual circumstances.
8.3. URN sub-namespace registration for o The following note will be placed in the header of the CAtypes
'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' registry, above the table:
This document calls for IANA to register a new XML namespace, as per Note: As specified in [[this RFC]], new registrations are only
the guidelines in [RFC3688]. accepted for CAtype XX, using the template specified in
Section 8.3.
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext o The registration procedures are changed: IETF Review (if Type=A),
Expert Review (if Type=B). The designated expert is unchanged.
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), o The reference for the table is changed: [RFC4776], [[this RFC]]
James Winterbottom (james.winterbottom@commscope.com).
XML: o The column called "NENA" is removed.
BEGIN o The column called "PIDF" is renamed to "Local Name".
<?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>GEOPRIV Civic Address Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</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
8.4. XML Schema Registration o New columns are added named "Namespace URI", "Contact", "Schema"
and "Type". All existing entries will have the following values
for those new columns:
This section registers an XML schema as per the procedures in Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
[RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
James Winterbottom (james.Winterbottom@commscope.com).
The XML for this schema can be found as the entirety of Type: A
Section 5.5 of this document.
8.5. 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 use the CAtype: The assigned numeric CAtype. All new registrations will use
value XX. [[IANA/RFC-Editor: update XX] Existing registrations the value XX.
use their assigned value.
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.
(Optional) Example: One or more simple examples of the element. Example (optional): One or more simple examples of the element.
Contact: Contact details for the person providing the extension. Contact: Contact details for the person providing the extension.
(Optional) Specification: A reference to a specification for the Specification (optional): A reference to a specification for the
civic address element. civic address element.
(Optional) Schema: 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: If Type is "A", all clients SHOULD implement this element. If Type: "A" or "B".
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.
Registrations from [RFC4776] and [RFC5139] are registered with the 8.4. Registration of the CAtypes defined in this document
following form:
CAtype: (The existing CAtype.)
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
Local Name: (The contents of the PIDF column.)
Description: (The existing description for the element.)
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org).
Specification: RFC4776 and RFC5139
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
Type: A
8.5.1. Registration of the schema 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 per the scheme in Section 5.5 whose parameters Address Types Registry.
are identical except for their Local Names and Descriptions:
CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor:
update XX]
Post Number (see Section 5.1):
CAtype: XX
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: PN: Post number that is attributed to a lamp post or
utility pole. utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Local Name: MP Mile Post (see Section 5.2):
Description: MP: Mile Post a marker indicating distance to or from a CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP
Description: Mile Post 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
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Street Type Prefix (see Section 5.3):
CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP Local Name: STP
Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A
Description: STP: Street Type Prefix. House Number Prefix (see Section 5.4):
CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP Local Name: HNP
Description: House Number Prefix.
Description: HNP: 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: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC
URL and replace XXXX with the RFC number for this specification.]]
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.6. 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". 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.
8.6. URN sub-namespace registration
This document calls for IANA to register a new XML namespace, 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@commscope.com)
XML:
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>GEOPRIV Civic Address Extensions</title>
</head>
<body>
<h1>Additional Fields for GEOPRIV Civic Address</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext</h2>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
8.7. XML Schema Registration
This section registers an XML schema as per the procedures in
[RFC3688]
URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org),
James Winterbottom (james.Winterbottom@commscope.com)
XML: The XML for this schema can be found as the entirety of
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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 44 change blocks. 
142 lines changed or deleted 158 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/