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