idnits 2.17.1
draft-ietf-geopriv-local-civic-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 11, 2011) is 4767 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '0' on line 323
-- Looks like a reference, but probably isn't: '1' on line 324
== Missing Reference: 'XX' is mentioned on line 330, but not defined
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS'
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew Corporation
5 Expires: September 12, 2011 R. Barnes
6 BBN Technologies
7 B. Rosen
8 NeuStar, Inc.
9 R. George
10 Huawei Technologies
11 March 11, 2011
13 Specifying Civic Address Extensions in PIDF-LO
14 draft-ietf-geopriv-local-civic-01
16 Abstract
18 New fields are occasionally added to civic addresses. A backwardly-
19 compatible mechanism for adding civic address elements to the Geopriv
20 civic address format is described. A formal mechanism for handling
21 unsupported extensions when translating between XML and DHCP civic
22 address forms is defined for entities that need to perform this
23 translation. Intial extensions for some new elements are also
24 defined.
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on September 12, 2011.
43 Copyright Notice
45 Copyright (c) 2011 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 3
62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4
64 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 5
65 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
66 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
67 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7
68 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7
69 4. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 8
70 4.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 8
71 4.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 9
72 4.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 9
73 4.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 9
74 4.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 10
75 4.6. Extension examples . . . . . . . . . . . . . . . . . . . . 10
76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
78 6.1. CAtype Registration for Extensions . . . . . . . . . . . . 11
79 6.2. End of Numeric CAtype Registration . . . . . . . . . . . . 11
80 6.3. URN sub-namespace registration for
81 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 11
82 6.4. XML Schema Registration . . . . . . . . . . . . . . . . . 12
83 6.5. Registration Template . . . . . . . . . . . . . . . . . . 12
84 6.6. Registration Policy and Expert Guidance . . . . . . . . . 14
85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
88 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
91 1. Introduction
93 The Geopriv civic location specifications ([RFC4776], [RFC5139])
94 define an XML and binary representtations for civic addresses that
95 allow for the expression of civic addresses. Guidance for the use of
96 these formats for the civic addresses in different countries is
97 included in [RFC5774].
99 Subsequent to these specifications being produced, use cases for
100 extending the civic address format with new elements have emerged.
101 Extension elements do not readily fit existing elements, as
102 recommended in [RFC5774].
104 The XML format for civic addresses [RFC5139] provides a mechanism
105 that allows for the addition of standardized or privately understood
106 elements. A similar facility for private extension is not provided
107 for the DHCP format [RFC4776], though new specifications are able to
108 define new CAtypes (civic address types).
110 A recipient of a civic address in either format currently has no
111 option other than to ignore elements that it does not understand.
112 This results in any elements that are unknown to that recipient being
113 discarded if a recipient performs a translation between the two
114 formats. In order for a new extension to be preserved through
115 translation by any recipient, the recipient has to understand the
116 extension and know how to correlate an XML element with a CAtype.
118 This document describes how new civic address elements are added.
119 Extension always starts with the definition of XML elements. A
120 mechanism for carrying the extension in the DHCP format is described.
121 A new XML namespace containing a small number of additional civic
122 elements is also defined and can be used as a template to illustrate
123 how other extensions can be defined as required.
125 These mechanisms ensure that any translation between formats can be
126 performed consistently and without loss of information. Translation
127 between formats can occur without knowledge of every extension that
128 is present.
130 These additions described in this document are backwardly compatible.
131 Existing implementations may cause extension information to be lost,
132 but the presence of extensions does not affect an implementation that
133 conforms to either [RFC4776] or [RFC5139].
135 1.1. Motivating Example
137 One instance where translation might be necessary is where a device
138 receives location configuration using DHCP [RFC4776]. Conversion of
139 DHCP information to an XML form is necessary if the device wishes to
140 use the DHCP-provided information in a range of applications,
141 including location-based presence services [RFC4079], and emergency
142 calling [RFC5012].
144 +--------+ +--------+ +-----------+
145 | DHCP | DHCP | Device | XML | Recipient | e.g., Presence
146 | Server |--------->| |-------->| | Agent
147 +--------+ +--------+ +-----------+
149 Conversion Scenario
151 The Device that performs the translation between the DHCP and XML
152 formats might not be aware of some of the extensions that are in use.
153 Without knowledge of these extensions and how they are represented in
154 XML, the Device is forced to discard them.
156 These extensions could be useful - or critical - to the ultimate
157 consumers of this information. For instance, an extension element
158 might provide a presence watcher with important information in
159 locating the Device or an extension might be significant in choosing
160 a particular call route.
162 1.2. Terminology
164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
166 document are to be interpreted as described in [RFC2119].
168 2. Specifying Civic Address Extensions
170 The civic schema in [RFC5139] defines an ordered structure of
171 elements that can be combined to describe a civic address. The XML
172 extension point at the end of this sequence is used to extend the
173 address.
175 New elements are defined in a new XML namespace [XMLNS]. This is
176 true of address elements with significance within private or
177 localized domains, as well as those that are intended for global
178 applicability.
180 New elements SHOULD use the basic "caType" schema type defined in
181 [RFC5139]. This type provides an optional "xml:lang" attribute.
183 For example, suppose the (fictitious) Central Devon Canals Authority
184 wishes to introduce a new civic element called "bridge". The
185 authority defines an XML namespace that includes a "bridge" element.
187 The namespace needs to be a unique URI, for example
188 "http://devon.canals.org.uk/civic".
190 A civic address that includes the new "bridge" element is shown in
191 Figure 1.
193
See RFCXXXX.
505 506 507 END 509 6.4. XML Schema Registration 511 This section registers an XML schema as per the procedures in 512 [RFC3688]. 514 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 516 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 517 James Winterbottom (james.Winterbottom@andrew.com). 519 The XML for this schema can be found as the entirety of 520 Section 4.5 of this document. 522 6.5. Registration Template 524 New registrations in the "CAtypes" registry require the following 525 information: 527 CAtype: The assigned numeric CAtype. All new registrations use the 528 value XX. [[IANA/RFC-Editor: update XX] Existing registrations 529 use their assigned value. 531 Namespace URI: A unique identifier for the XML namespace used for 532 the extension element. 534 Local Name: The local name of an XML element that carries the civic 535 address element. 537 Description: A brief description of the semantics of the civic 538 address element. 540 (Optional) Example: One or more simple examples of the element. 542 Contact: Contact details for the person providing the extension. 544 (Optional) Specification: A reference to a specification for the 545 civic address element. 547 (Optional) Schema: A reference to a formal schema (XML schema, 548 RelaxNG, or other form) that defines the extension. 550 Registrations from [RFC4776] and [RFC5139] are registered with the 551 following form: 553 CAtype: (The existing CAtype.) 555 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 557 Local Name: (The contents of the PIDF column.) 559 Description: (The existing description for the element, including a 560 note about the equivalent NENA field, if present.) 562 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 563 (geopriv@ietf.org). 565 Specification: RFC4776 and RFC5139 567 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 569 Registration of the schema defined in this document in Section 4.5. 571 CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor: 572 update XX] 574 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 575 Local Name: PN, MP, STP, HNP 577 Description: PN: Post number that is attributed to a lamp post or 578 utility pole. 580 Description: MP: Mile Post a marker indicating distance to or from a 581 place (often a town). 583 Description: STP: Street Type Prefix. 585 Description: HNP: House Number Prefix. 587 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 588 (geopriv@ietf.org). 590 Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC 591 URL and replace XXXX with the RFC number for this specification.]] 593 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 595 6.6. Registration Policy and Expert Guidance 597 The "CAtypes" registry is altered to operate on a registration policy 598 of "Expert Review", and optionally "Specification Required" 599 [RFC5226]. 601 The registration rules for "Specification Required" are followed only 602 if a registration includes a reference to a specification. 603 Registrations can be made without a specification reference. 605 All registrations are reviewed to identify potential duplication 606 between registered elements. Duplicated semantics are not prohibited 607 in the registry, though it is preferred if existing elements are 608 used. The expert review is advised to recommend the use of existing 609 elements following the guidance in [RFC5774]. Any registration that 610 is a duplicate or could be considered a close match for the semantics 611 of an existing element SHOULD include a discussion of the reasons 612 that the existing element was not reused. 614 7. Acknowledgements 616 Thanks to anyone who has tried to extend the civic schema and found 617 it a little unintuitive. 619 8. References 620 8.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 626 January 2004. 628 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 629 (DHCPv4 and DHCPv6) Option for Civic Addresses 630 Configuration Information", RFC 4776, November 2006. 632 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 633 Format for Presence Information Data Format Location 634 Object (PIDF-LO)", RFC 5139, February 2008. 636 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 637 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 638 May 2008. 640 [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, 641 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 642 Consortium Recommendation REC-xml-names11-20060816, 643 August 2006, 644