idnits 2.17.1
draft-winterbottom-geopriv-local-civic-04.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 (December 17, 2010) is 4877 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 302
-- Looks like a reference, but probably isn't: '1' on line 303
== Missing Reference: 'XX' is mentioned on line 309, 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: June 20, 2011 R. Barnes
6 BBN Technologies
7 December 17, 2010
9 Specifying Civic Address Extensions in PIDF-LO
10 draft-winterbottom-geopriv-local-civic-04
12 Abstract
14 New fields are occasionally added to civic addresses. A backwardly-
15 compatible mechanism for adding civic address elements to the Geopriv
16 civic address format is described. A formal mechanism for handling
17 unsupported extensions when translating between XML and DHCP civic
18 address forms is defined for entities that need to perform this
19 translation.
21 Status of this Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on June 20, 2011.
38 Copyright Notice
40 Copyright (c) 2010 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 3
57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
58 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4
59 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 5
60 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6
61 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6
62 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 6
63 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7
64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
66 5.1. CAtype Registration for Extensions . . . . . . . . . . . . 8
67 5.2. End of Numeric CAtype Registration . . . . . . . . . . . . 8
68 5.3. Registration Template . . . . . . . . . . . . . . . . . . 8
69 5.4. Registration Policy and Expert Guidance . . . . . . . . . 9
70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
73 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
76 1. Introduction
78 The Geopriv civic location specifications ([RFC4776], [RFC5139])
79 define an XML and binary representtations for civic addresses that
80 allow for the expression of civic addresses. Guidance for the use of
81 these formats for the civic addresses in different countries is
82 included in [RFC5774].
84 Subsequent to these specifications being produced, use cases for
85 extending the civic address format with new elements have emerged.
86 Extension elements do not readily fit existing elements, as
87 recommended in [RFC5774].
89 The XML format for civic addresses [RFC5139] provides a mechanism
90 that allows for the addition of standardized or privately understood
91 elements. A similar facility for private extension is not provided
92 for the DHCP format [RFC4776], though new specifications are able to
93 define new CAtypes (civic address types).
95 A recipient of a civic address in either format currently has no
96 option other than to ignore elements that it does not understand.
97 This results in any elements that are unknown to that recipient being
98 discarded if a recipient performs a translation between the two
99 formats. In order for a new extension to be preserved through
100 translation by any recipient, the recipient has to understand the
101 extension and know how to correlate an XML element with a CAtype.
103 This document describes how new civic address elements are added.
104 Extension always starts with the definition of XML elements. A
105 mechanism for carrying the extension in the DHCP format is described.
107 These mechanisms ensure that any translation between formats can be
108 performed consistently and without loss of information. Translation
109 between formats can occur without knowledge of every extension that
110 is present.
112 These additions described in this document are backwardly compatible.
113 Existing implementations may cause extension information to be lost,
114 but the presence of extensions does not affect an implementation that
115 conforms to either [RFC4776] or [RFC5139].
117 1.1. Motivating Example
119 One instance where translation might be necessary is where a device
120 receives location configuration using DHCP [RFC4776]. Conversion of
121 DHCP information to an XML form is necessary if the device wishes to
122 use the DHCP-provided information in a range of applications,
123 including location-based presence services [RFC4079], and emergency
124 calling [RFC5012].
126 +--------+ +--------+ +-----------+
127 | DHCP | DHCP | Device | XML | Recipient | e.g., Presence
128 | Server |--------->| |-------->| | Agent
129 +--------+ +--------+ +-----------+
131 Conversion Scenario
133 The Device that performs the translation between the DHCP and XML
134 formats might not be aware of some of the extensions that are in use.
135 Without knowledge of these extensions and how they are represented in
136 XML, the Device is forced to discard them.
138 These extensions could be useful - or critical - to the ultimate
139 consumers of this information. For instance, an extension element
140 might provide a presence watcher with important information in
141 locating the Device or an extension might be significant in choosing
142 a particular call route.
144 1.2. Terminology
146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
148 document are to be interpreted as described in [RFC2119].
150 2. Specifying Civic Address Extensions
152 The civic schema in [RFC5139] defines an ordered structure of
153 elements that can be combined to describe a civic address. The XML
154 extension point at the end of this sequence is used to extend the
155 address.
157 New elements are defined in a new XML namespace [XMLNS]. This is
158 true of address elements with significance within private or
159 localized domains, as well as those that are intended for global
160 applicability.
162 New elements SHOULD use the basic "caType" schema type defined in
163 [RFC5139]. This type provides an optional "xml:lang" attribute.
165 For example, suppose the (fictitious) Central Devon Canals Authority
166 wishes to introduce a new civic element called "bridge". The
167 authority defines an XML namespace that includes a "bridge" element.
168 The namespace needs to be a unique URI, for example
169 "http://devon.canals.org.uk/civic".
171 A civic address that includes the new "bridge" element is shown in
172 Figure 1.
174
177 UK
178 Devon
179 Monkokehampton
180 Deckport
181 Cross
183 21451338
185
187 Figure 1: Extended Civic Address Example
189 An entity that receives this location information might not
190 understand the extension address element. As long as the added
191 element is able to be safely ignored, the remainder of the civic
192 address can be used. The result is that the information is not as
193 useful as it could be, but the added element does not prevent the use
194 of the remainder of the address.
196 The address can be passed to other applications, such as a LoST
197 server [RFC5222], without modification. If the application
198 understands the added elements, it is able to make use of that
199 information. For example, if this civic address is acquired using
200 HELD [RFC5985], it can be included in a LoST request directly.
202 3. Translating Unsupported Elements
204 Unsupported civic address elements can be carried without consequence
205 only as long as the format of the address does not change. When
206 converting between the XML and DHCP formats, these unsupported
207 elements are necessarily discarded: the entity performing the
208 translation has no way to know the correct element to use in the
209 target format.
211 All extensions MUST be defined using the mechanism described in this
212 document. Extensions that use numeric CAtypes or other mechanisms
213 cannot be safely translated between XML and DHCP representations.
215 An entity that does not support these extension mechanisms is
216 expected to remove elements it doesn't understand when performing
217 conversions.
219 3.1. XML to DHCP Format Translation
221 Extensions to the XML format [RFC5139] are defined in a new XML
222 namespace [XMLNS].
224 Extensions in the XML format can be added to a DHCP format civic
225 address using an extension CAtype.
227 3.2. Extension Civic Address Type (CAtype)
229 The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor:
230 please replace XX here and in the figure below with the assigned
231 code] includes three values that uniquely identify the XML extension
232 and its value: a namespace URI, the local name of the XML element,
233 and the text content of that element. These three values are all
234 included in the value of the CAtype, each separated by a single
235 whitespace character.
237 0 1 2 3
238 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
239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
240 | CAtype (XX) | Length | Namespace URI ... .
241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242 . Namespace URI (continued) ... .
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244 | Space (U+20) | XML element local name ... .
245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
246 | Space (U+20) | Extension type value ... .
247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
249 Figure 2: XML Civic Address Extension CAtype
251 The content of a CAtype (after the CAtype code and length) is UTF-8
252 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed.
253 Octets consumed by the namespace URI and local name reduce the space
254 available for values.
256 This conversion only works for elements that have textual content and
257 an optional "xml:lang" attribute. Elements with complex content or
258 other attributes - aside from namespace bindings - MUST be ignored if
259 they are not understood.
261 3.3. DHCP to XML Format Translation
263 The registration of a new CAtype following the process in [RFC4776]
264 means that a recipient that does not know the equivalent XML is
265 unable to produce a complete XML representation of the DHCP civic
266 address. For this reason, this document ends the registration of new
267 numeric CAtypes. No new registrations of numeric CAtypes can be
268 made.
270 Extension for the DHCP civic address format is performed by first
271 describing an XML extension. This extension is then carried in the
272 DHCP form in an extension CAtype.
274 When converting to XML, the namespace prefix used for the extension
275 element is selected by the entity that performs the conversion.
277 3.4. Conversion Example
279 The following example civic address contains two extensions:
281
285 US
286 CA
288 2471
289 AQ-374-4(c)
291 LAX
292 Tom Bradley
293 G
294 36B
295
297 Figure 3: XML Example with Multiple Extensions
299 This is converted to a DHCP form as follows:
301 country = US
302 CAtype[0] = en-US
303 CAtype[1] = CA
304 CAtype[XX] = http://postsoftheworld.net/ns lamp 2471
305 CAtype[XX] = http://postsoftheworld.net/ns lamp AQ-374-4(c)
306 CAtype[XX] = http://example.com/airport/5.0 airport LAX
307 CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley
308 CAtype[XX] = http://example.com/airport/5.0 concourse G
309 CAtype[XX] = http://example.com/airport/5.0 gate 36B
311 Figure 4: Converted DHCP Example with Multiple Extensions
313 4. Security Considerations
315 This document defines a formal way to extend the existing Geopriv
316 civic address schema. No security threats are introduced by this
317 document.
319 Security threats applicable to the civic address formats are
320 described in [RFC4776] (DHCP) and [RFC5139] (XML).
322 5. IANA Considerations
324 This document alters the "CAtypes" registry established by [RFC4776].
326 5.1. CAtype Registration for Extensions
328 IANA has allocated a CAtype code of XX for the extension CAtype.
330 [[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]]
332 5.2. End of Numeric CAtype Registration
334 No further registration of numeric CAtypes is permitted. New
335 registrations in this registry use the registration template in
336 Section 5.3.
338 5.3. Registration Template
340 New registrations in the "CAtypes" registry require the following
341 information:
343 CAtype: The assigned numeric CAtype. All new registrations use the
344 value XX. [[IANA/RFC-Editor: update XX] Existing registrations
345 use their assigned value.
347 Namespace URI: A unique identifier for the XML namespace used for
348 the extension element.
350 Local Name: The local name of an XML element that carries the civic
351 address element.
353 Description: A brief description of the semantics of the civic
354 address element.
356 (Optional) Example: One or more simple examples of the element.
358 Contact: Contact details for the person providing the extension.
360 (Optional) Specification: A reference to a specification for the
361 civic address element.
363 (Optional) Schema: A reference to a formal schema (XML schema,
364 RelaxNG, or other form) that defines the extension.
366 Registrations from [RFC4776] and [RFC5139] are registered with the
367 following form:
369 CAtype: (The existing CAtype.)
371 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
373 Local Name: (The contents of the PIDF column.)
375 Description: (The existing description for the element, including a
376 note about the equivalent NENA field, if present.)
378 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
379 (geopriv@ietf.org).
381 Specification: RFC4776 and RFC5139
383 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
385 5.4. Registration Policy and Expert Guidance
387 The "CAtypes" registry is altered to operate on a registration policy
388 of "Expert Review", and optionally "Specification Required"
389 [RFC5226].
391 The registration rules for "Specification Required" are followed only
392 if a registration includes a reference to a specification.
393 Registrations can be made without a specification reference.
395 All registrations are reviewed to identify potential duplication
396 between registered elements. Duplicated semantics are not prohibited
397 in the registry, though it is preferred if existing elements are
398 used. The expert review is advised to recommend the use of existing
399 elements following the guidance in [RFC5774]. Any registration that
400 is a duplicate or could be considered a close match for the semantics
401 of an existing element SHOULD include a discussion of the reasons
402 that the existing element was not reused.
404 6. Acknowledgements
406 Thanks to Brian Rosen, Delaine Arnold, Robins George, and anyone else
407 who has tried to extend the civic schema and found it a little
408 unintuitive.
410 7. References
412 7.1. Normative References
414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
415 Requirement Levels", BCP 14, RFC 2119, March 1997.
417 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
418 (DHCPv4 and DHCPv6) Option for Civic Addresses
419 Configuration Information", RFC 4776, November 2006.
421 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
422 Format for Presence Information Data Format Location
423 Object (PIDF-LO)", RFC 5139, February 2008.
425 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
426 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
427 May 2008.
429 [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray,
430 "Namespaces in XML 1.1 (Second Edition)", World Wide Web
431 Consortium Recommendation REC-xml-names11-20060816,
432 August 2006,
433 .
435 7.2. Informative References
437 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
438 10646", STD 63, RFC 3629, November 2003.
440 [RFC4079] Peterson, J., "A Presence Architecture for the
441 Distribution of GEOPRIV Location Objects", RFC 4079,
442 July 2005.
444 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
445 Emergency Context Resolution with Internet Technologies",
446 RFC 5012, January 2008.
448 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
449 Tschofenig, "LoST: A Location-to-Service Translation
450 Protocol", RFC 5222, August 2008.
452 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic
453 Addresses in the Presence Information Data Format Location
454 Object (PIDF-LO): Guidelines and IANA Registry
455 Definition", BCP 154, RFC 5774, March 2010.
457 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
458 RFC 5985, September 2010.
460 Authors' Addresses
462 James Winterbottom
463 Andrew Corporation
464 Andrew Building (39)
465 Wollongong University Campus
466 Northfields Avenue
467 Wollongong, NSW 2522
468 AU
470 Phone: +61 242 212938
471 Email: james.winterbottom@andrew.com
473 Martin Thomson
474 Andrew Corporation
475 Andrew Building (39)
476 Wollongong University Campus
477 Northfields Avenue
478 Wollongong, NSW 2522
479 AU
481 Phone: +61 2 4221 2915
482 Email: martin.thomson@andrew.com
484 Richard Barnes
485 BBN Technologies
486 9861 Broken Land Parkway
487 Columbia, MD 21046
488 US
490 Phone: +1 410 290 6169
491 Email: rbarnes@bbn.com