idnits 2.17.1 draft-ietf-geopriv-local-civic-10.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5222, but the abstract doesn't seem to directly say this. It does mention RFC5222 though, so this could be OK. -- The draft header indicates that this document updates RFC4776, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4776, updated by this document, for RFC5378 checks: 2006-11-17) (Using the creation date from RFC5222, updated by this document, for RFC5378 checks: 2006-06-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Dec 2012) is 4143 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 366 -- Looks like a reference, but probably isn't: '1' on line 367 == Missing Reference: 'XX' is mentioned on line 373, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3694 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV J. Winterbottom 3 Internet-Draft CommScope 4 Updates: 5222,4776 (if approved) M. Thomson 5 Intended status: Standards Track Skype 6 Expires: June 4, 2013 R. Barnes 7 BBN Technologies 8 B. Rosen 9 NeuStar, Inc. 10 R. George 11 Huawei Technologies 12 Dec 2012 14 Specifying Civic Address Extensions in PIDF-LO 15 draft-ietf-geopriv-local-civic-10 17 Abstract 19 New fields are occasionally added to civic addresses. A backwardly- 20 compatible mechanism for adding civic address elements to the Geopriv 21 civic address format is described. A formal mechanism for handling 22 unsupported extensions when translating between XML and DHCP civic 23 address forms is defined for entities that need to perform this 24 translation. Intial extensions for some new elements are also 25 defined. The LoST (RFC5222) protocol mechanism that returns civic 26 address element names used for validation of location information is 27 clarified and is normatively updated to require a qualifying 28 namespace identifier on each civic address element returned as part 29 of the validation process. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 4, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 5 68 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6 69 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 70 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 71 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 72 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 8 73 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10 78 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10 79 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11 80 5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11 81 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14 85 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14 86 8.3. Registration Template . . . . . . . . . . . . . . . . . . 15 87 8.4. Registration of the CAtypes defined in this document . . . 15 88 8.5. Registration Policy and Expert Guidance . . . . . . . . . 16 89 8.6. URN sub-namespace registration . . . . . . . . . . . . . . 17 90 8.7. XML Schema Registration . . . . . . . . . . . . . . . . . 18 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 The Geopriv civic location specifications ([RFC4776], [RFC5139]) 100 define an XML and binary representations for civic addresses that 101 allow for the expression of civic addresses. Guidance for the use of 102 these formats for the civic addresses in different countries is 103 included in [RFC5774]. 105 Subsequent to these specifications being produced, use cases for 106 extending the civic address format with new elements have emerged. 107 [RFC5774] describes a mechanism for mapping long-standing address 108 formats into the civic address elements defined in [RFC4776] and 109 [RFC5139]. However, some of these existing address elements do not 110 readily fit into the civic address elements defined in [RFC4776] and 111 [RFC5139]. In these cases creating new civic address elements 112 provides a better solution than overloading existing civic address 113 fields which may cause confusion. 115 The XML format for civic addresses [RFC5139] provides a mechanism 116 that allows for the addition of standardized or privately understood 117 elements. A similar facility for private extension is not provided 118 for the DHCP format [RFC4776], though new specifications are able to 119 define new CAtypes (civic address types). 121 A recipient of a civic address in either format currently has no 122 option other than to ignore elements that it does not understand. 123 This results in any elements that are unknown to that recipient being 124 discarded if a recipient performs a translation between the two 125 formats. In order for a new extension to be preserved through 126 translation by any recipient, the recipient has to understand the 127 extension and know how to correlate an XML element with a CAtype. 129 This document describes how new civic address elements are added. 130 Extensions always starts with the definition of XML elements. A 131 mechanism for carrying the extension in the DHCP format is described. 132 A new XML namespace containing a small number of additional civic 133 elements is also defined and can be used as a template to illustrate 134 how other extensions can be defined as required. 136 These mechanisms ensure that any translation between formats can be 137 performed consistently and without loss of information. Translation 138 between formats can occur without knowledge of every extension that 139 is present. 141 The registry of numeric CAtypes is modified so that creators of 142 extensions can advertise new namespaces and the civic elements to 143 encourage maximum reuse. 145 The additions described in this document are backwardly compatible. 146 Existing implementations may cause extension information to be lost, 147 but the presence of extensions does not affect an implementation that 148 conforms to either [RFC4776] or [RFC5139]. 150 This document also normatively updates [RFC5222] to clarify that the 151 namespace must be included with the element name in the lists of 152 valid, invalid and not checked elements in the 153 part of a LoST response. While the LoST schema does not need to be 154 changed, the example in the document is updated to show the 155 namespaces in the lists. 157 1.1. Motivating Example 159 One instance where translation might be necessary is where a device 160 receives location configuration using DHCP [RFC4776]. Conversion of 161 DHCP information to an XML form is necessary if the device wishes to 162 use the DHCP-provided information in a range of applications, 163 including location-based presence services [RFC4079], and emergency 164 calling [RFC5012]. 166 +--------+ +--------+ +-----------+ 167 | DHCP | DHCP | Device | XML | Recipient | e.g., Presence 168 | Server |--------->| |-------->| | Agent 169 +--------+ +--------+ +-----------+ 171 Figure 1: Conversion Scenario 173 The Device that performs the translation between the DHCP and XML 174 formats might not be aware of some of the extensions that are in use. 175 Without knowledge of these extensions and how they are represented in 176 XML, the Device is forced to discard them. 178 These extensions could be useful, or may be critical, to the ultimate 179 consumers of this information. For instance, an extension element 180 might provide a presence watcher with important information in 181 locating the Device, or an extension might be significant in choosing 182 a particular call route. 184 1.2. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 2. Specifying Civic Address Extensions 192 The civic schema in [RFC5139] defines an ordered structure of 193 elements that can be combined to describe a civic address. The XML 194 extension point at the end of this sequence is used to extend the 195 address. 197 New elements are defined in a new XML namespace [XMLNS]. This is 198 true of address elements with significance within private or 199 localized domains, as well as those that are intended for global 200 applicability. 202 New elements SHOULD use the basic "caType" schema type defined in 203 [RFC5139]. This type provides an optional "xml:lang" attribute. 205 For example, suppose the (fictitious) Central Devon Canals Authority 206 wishes to introduce a new civic element called "bridge". The 207 authority defines an XML namespace that includes a "bridge" element. 208 The namespace needs to be a unique URI, for example 209 "http://devon.canals.example.com/civic". 211 A civic address that includes the new "bridge" element is shown in 212 Figure 2. 214 217 UK 218 Devon 219 Monkokehampton 220 Deckport 221 Cross 223 21451338 225 227 Figure 2: Extended Civic Address Example 229 An entity that receives this location information might not 230 understand the extension address element. As long as the added 231 element is able to be safely ignored, the remainder of the civic 232 address can be used. The result is that the information is not as 233 useful as it could be, but the added element does not prevent the use 234 of the remainder of the address. 236 The address can be passed to other applications, such as a LoST 237 server [RFC5222], without modification. If the application 238 understands the added element(s), it is able to make use of that 239 information. For example, if this civic address is acquired using 240 HELD [RFC5985], it can be included in a LoST request directly. 242 3. Translating Unsupported Elements 244 Unsupported civic address elements can be carried without consequence 245 as long as the format of the address does not change. However, 246 conversion between formats has been shown to be necessary. 248 Format conversion required knowledge of the format of the address 249 elements. An entity performing a conversion between XML and DHCP 250 address formats was forced to discard unrecognized elements. The 251 entity performing the conversion had no way to know the correct 252 element to use in the target format. 254 This document defines a single extension element for the DHCP format 255 that makes knowledge of extensions unnecessary during conversion. 256 This extension element relies on the extension mechanisms defined for 257 the XML format. New extensions to the civic address format MUST be 258 defined only for the XML format; these extensions are then conveyed 259 in DHCP using the extension element. 261 Further extensions to the DHCP format are prohibited: these 262 extensions cannot be safely conveyed in environments where conversion 263 is possible. 265 3.1. XML to DHCP Format Translation 267 Extensions to the XML format [RFC5139] are defined in a new XML 268 namespace [XMLNS]. The XML namespace received in DHCP is expressed 269 as a URL, however, it should not be dereferenced or treated as a 270 source location for the actual schema and doing so will serve no 271 useful prupose. 273 Extensions in the XML format can be added to a DHCP format civic 274 address using an extension CAtype. 276 3.2. Extension Civic Address Type (CAtype) 278 The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: 279 please replace XX here and in Figure 3 and in Figure 5 with the 280 assigned code] includes three values that uniquely identify the XML 281 extension and its value: a namespace URI, the local name of the XML 282 element, and the text content of that element. These three values 283 are all included in the value of the CAtype, each separated by a 284 single whitespace character. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | CAtype (XX) | Length | Namespace URI ... . 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 . Namespace URI (continued) . 292 . ... . 293 . . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Space (U+20) | XML element local name . 296 +---------------+ . 297 . ... . 298 . . 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Space (U+20) | Extension type value . 301 +---------------+ . 302 . ... . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 3: XML Civic Address Extension CAtype 308 CAtype (XX) identifies the extension CAtype. 310 Length is the number of octets used to represent the namespace URI, 311 local name and value. 313 The content of a CAtype (after the CAtype code and length) is UTF-8 314 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. 315 Octets consumed by the namespace URI and local name reduce the space 316 available for values. 318 This conversion only works for elements that have textual content and 319 an optional "xml:lang" attribute. Elements with complex content or 320 other attributes - aside from namespace bindings - MUST be ignored if 321 they are not understood. 323 3.3. DHCP to XML Format Translation 325 The registration of a new CAtype following the process in [RFC4776] 326 means that a recipient that does not know the equivalent XML is 327 unable to produce a complete XML representation of the DHCP civic 328 address. For this reason, this document ends the registration of new 329 numeric CAtypes. No new registrations of numeric CAtypes can be 330 made. 332 In lieu of making new numerical CAtype assignments, this document 333 creates a new extensionCA type which is defined in a manner that lets 334 new civic elements be described in DHCP form by carrying the name 335 space and type name of the extension in parameters of the extensionCA 336 type. 338 When converting to XML, the namespace prefix used for the extension 339 element is selected by the entity that performs the conversion. 341 3.4. Conversion Example 343 The following example civic address contains two extensions: 345 349 US 350 CA 352 2471 353 AQ-374-4(c) 355 LAX 356 Tom Bradley 357 G 358 36B 359 361 Figure 4: XML Example with Multiple Extensions 363 This is converted to a DHCP form as follows: 365 country = US 366 CAtype[0] = en-US 367 CAtype[1] = CA 368 CAtype[XX] = http://postsoftheworld.example.com/ns lamp 2471 369 CAtype[XX] = http://postsoftheworld.example.com/ns pylon AQ-374-4(c) 370 CAtype[XX] = http://example.com/airport/5.0 airport LAX 371 CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley 372 CAtype[XX] = http://example.com/airport/5.0 concourse G 373 CAtype[XX] = http://example.com/airport/5.0 gate 36B 375 Figure 5: Converted DHCP Example with Multiple Extensions 377 4. CAtypes Registry 379 [RFC4776] created the CAtype registry. Among other things, this 380 registry advertised available civic elements. While it has always 381 been possible to use an extension namespace to define civic elements 382 that are not in the CAtype registry, and this document does not 383 change that, the registry is valuable to alert implementors of 384 commonly used civic elements and provides guidance to clients of what 385 elements they should suppport. 387 This document alters the CAtype registry in several ways. It closes 388 the registry to new numeric CAtypes. It deletes the "NENA" column, 389 which is not needed. It adds columns for a namespace and contact, 390 and changes the name of the column currently called "PIDF" to "Local 391 Name". It also adds a column to the registry called "Type". "Type" 392 can have one of two values "A" and "B". Type A elements are intended 393 for wide use with many applications and SHOULD be implemented by all 394 clients unless the client is certain the element will not be 395 encountered. Type "B" civic elements MAY be implemented by any 396 client. 398 Type A civic elements require IETF review, while Type B elements only 399 require an expert review. 401 5. Civic Extensions 403 We use this new extension method to define some additional civic 404 address elements which are needed to correctly encode civic locations 405 in several countries. The definition of these new civic address 406 elements also serves as an example of how to define additional 407 elements using the mechanisms described in this document. 409 5.1. Pole Number 411 In some areas, utility and lamp posts carry a unique identifier, 412 which we call a pole number in this document. In some countries, the 413 label on the lamp post also carries the local emergency service 414 number, such as "110", encouraging callers to use the pole number to 415 identify their location. 417 _.-----,===. 418 | | (''''') 419 | | `---' 420 | | 421 | | ,---------, 422 | | ,---, |Emergency| 423 | | /|,-.|----->| Number | 424 | | / |110| '---------' 425 | | / |`-'| 426 |_|/ | 2 | ,---------, 427 | | | 1 | |Lamp Post| 428 | | | 2 |----->| Number | 429 |-| | 1 | '---------' 430 | |\ | 0 | 431 | | \ | 1 | 432 | | \ | 4 | 433 | | \|,,,| 434 _ | | 435 ``-..|.| 436 ``--.._ 437 `'--.._ 439 Figure 6: Lamp post with emergency number 441 5.2. Mile Post 443 On some roads, trails, railroad rights of way and other linear 444 features, a post with a mile or kilometer distance from one end of 445 the feature may be found (a "milepost"). There are other cases of 446 poles or markers with numeric indications that are not the same as a 447 "house number" or street address number. 449 5.3. Street Type Prefix 451 The civic schema defined in [RFC5139] allows the definition of 452 address "123 Colorado Boulevard", but it does not allow for the easy 453 expression of "123 Boulevard Colorado". Adding a street-type prefix, 454 allows street named in this manner to be more easily represented. 456 5.4. House Number Prefix 458 The civic schema defined in [RFC5139] provides house number suffix 459 element, allowing one to express an address like "123A Main Street", 460 but it does not contain a corresponding house number prefix. The 461 house number prefix element allows the expression of address such as 462 "Z123 Main Street". 464 5.5. XML Extension Schema 466 467 475 477 478 480 481 483 484 486 487 489 491 5.6. Extension examples 493 496 US 497 CA 498 Sacramento 499 I5 500 248 501 22-109-689 502 504 XML Example with Post Number and Mile Post 506 509 US 510 CA 511 Sacramento 512 Colorado 513 223 514 Boulevard 515 A 516 518 XML Example with Street prefix and House Number Prefix 520 6. Using Local Civic Extension with the LoST Protocol 522 One critical use of civic location information is in next generation 523 emergency services applications, in particular call routing 524 applications. In such cases location information is provided to a 525 location-based routing service using the location to service 526 transtion (LoST) protcol [RFC5222]. LoST is used to provide call 527 routing information, but it is also used to validate location 528 information to ensure that it can route to an emergency center when 529 required. 531 LoST is an XML-based protocol and so the namespace extension 532 mechansims described in this document do not impact LoST. When LoST 533 is used for validation a element is returned 534 containing a list of valid, a list of invalid, and a list of 535 unchecked civic elements. Figure 7 is an extract of the validation 536 response in Figure 6 from [RFC5222]. 538 539 country A1 A3 A6 540 PC 541 HNO 542 544 Figure 7: Location Validation Example from LoST (RFC5222) 546 The RelaxNG schema in [RFC5222] requires the elements in each of 547 these lists to be namespace qualified, which makes the example in 548 Figure 6 from [RFC5222] in error. This issue is especially 549 significant when local-civic extensions are used as the domain to 550 which the extensions are attributed may impact their interpretation 551 by the server or client. To ensure that local-civic extensions do 552 not cause issues with LoST server and client implementations, all 553 elements listed in a , , or element MUST 554 be qualified with a namespace. To illustrate this the extract above 555 from figure 6 in [RFC5222] becomes Figure 8. 557 559 ca:country ca:A1 ca:A3 ca:A6 560 ca:PC 561 ca:HNO 562 564 Figure 8: Corrected Location Validation Example 566 If a validation request has also included the extensions defined in 567 section Section 5 then the validation response would look like 568 Figure 9. 570 573 ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP 574 ca:PC 575 ca:HNO cae:MP cae:HNP 576 578 Figure 9: Corrected Location Validation Example 580 7. Security Considerations 582 This document defines a formal way to extend the existing Geopriv 583 civic address schema. While no security threats are directly 584 introduced by this document, creators of new civic address extensions 585 should refer to sections 4.3.1 and 5.1 of [RFC3694] to understand the 586 environments in which these new elements will be used. New elements 587 should only be registered if the person or organization performing 588 the registration understands any associated risks. 590 Security threats applicable to the civic address formats are 591 described in [RFC4776] (DHCP) and [RFC5139] (XML). 593 8. IANA Considerations 595 This document alters the "CAtypes" registry on the "Civic Address 596 Types Registry" page established by [RFC4776]. 598 8.1. CAtype Registration for Extensions 600 IANA has allocated a CAtype code of XX for the extension CAtype. 601 Registrations using this code will be made below, in Section 8.4. 603 8.2. Changes to the CAtype Registry 605 IANA is asked to make the following changes to the CAtype registry: 607 o No registrations of new CAtype numbers in the Civic Address Types 608 Registry are permitted, except by IESG Approval [RFC5226] under 609 unusual circumstances. 611 o The following note will be placed in the header of the CAtypes 612 registry, above the table: 614 Note: As specified in [[this RFC]], new registrations are only 615 accepted for CAtype XX, using the template specified in 616 Section 8.3. 618 o The registration procedures are changed: IETF Review (if Type=A), 619 Expert Review (if Type=B). The designated expert is unchanged. 621 o The reference for the table is changed: [RFC4776], [[this RFC]] 623 o The column called "NENA" is removed. 625 o The column called "PIDF" is renamed to "Local Name". 627 o New columns are added named "Namespace URI", "Contact", "Schema" 628 and "Type". All existing entries will have the following values 629 for those new columns: 631 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 633 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 634 (geopriv@ietf.org) 636 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 638 Type: A 640 8.3. Registration Template 642 New registrations in the Civic Address Types Registry require the 643 following information: 645 CAtype: The assigned numeric CAtype. All new registrations will use 646 the value XX. 648 Namespace URI: A unique identifier for the XML namespace used for 649 the extension element. 651 Local Name: The local name of an XML element that carries the civic 652 address element. 654 Description: A brief description of the semantics of the civic 655 address element. 657 Example (optional): One or more simple examples of the element. 659 Contact: Contact details for the person providing the extension. 661 Specification (optional): A reference to a specification for the 662 civic address element. 664 Schema (optional): A reference to a formal schema (XML schema, 665 RelaxNG, or other form) that defines the extension. 667 Type: "A" or "B". 668 If Type is "A", all clients SHOULD implement this element. If 669 Type is "B", clients MAY implement this element. 671 8.4. Registration of the CAtypes defined in this document 673 This section registers the following four new CATypes in the Civic 674 Address Types Registry. 676 Post Number (see Section 5.1): 677 CAtype: XX 678 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 679 Local Name: PN 680 Description: Post number that is attributed to a lamp post or 681 utility pole. 682 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 683 (geopriv@ietf.org) 685 Specification: [[this RFC]], Section 5 686 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 687 Type: A 689 Mile Post (see Section 5.2): 690 CAtype: XX 691 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 692 Local Name: MP 693 Description: Mile Post a marker indicating distance to or from a 694 place (often a town). 695 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 696 (geopriv@ietf.org) 697 Specification: [[this RFC]], Section 5 698 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 699 Type: A 701 Street Type Prefix (see Section 5.3): 702 CAtype: XX 703 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 704 Local Name: STP 705 Description: Street Type Prefix. 706 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 707 (geopriv@ietf.org) 708 Specification: [[this RFC]], Section 5 709 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 710 Type: A 712 House Number Prefix (see Section 5.4): 713 CAtype: XX 714 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 715 Local Name: HNP 716 Description: House Number Prefix. 717 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 718 (geopriv@ietf.org) 719 Specification: [[this RFC]], Section 5 720 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 721 Type: A 723 8.5. Registration Policy and Expert Guidance 725 The "CAtypes" registry is altered to operate on a registration policy 726 of "Expert Review", and optionally "Specification Required" [RFC5226] 727 if the element being registered has a Type value of "B". 729 The registration rules for "Specification Required" are followed only 730 if a registration includes a reference to a specification. 731 Registrations can be made without a specification reference. 733 If the element being registered has a Type value of "A" then the 734 registration policy is "IETF Review" [RFC5226]. 736 All registrations are reviewed to identify potential duplication 737 between registered elements. Duplicated semantics are not prohibited 738 in the registry, though it is preferred if existing elements are 739 used. The expert review is advised to recommend the use of existing 740 elements following the guidance in [RFC5774]. Any registration that 741 is a duplicate or could be considered a close match for the semantics 742 of an existing element SHOULD include a discussion of the reasons 743 that the existing element was not reused. 745 [RFC6280] provides a comprehensive framework concerning the privacy 746 of location information as pertaining to its use in Internet 747 applications. The expert reviewer is asked to keep the spirit of 748 this document in mind when reviewing new CAtype registrations. 750 8.6. URN sub-namespace registration 752 This document calls for IANA to register a new XML namespace, as per 753 the guidelines in [RFC3688]. 755 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 757 Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org), 758 James Winterbottom (james.Winterbottom@commscope.com) 760 XML: 762 BEGIN 763 764 766 767 768 GEOPRIV Civic Address Extensions 769 770 771

Additional Fields for GEOPRIV Civic Address

772

urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext

773

See RFCXXXX.

774 775 776 END 778 8.7. XML Schema Registration 780 This section registers an XML schema as per the procedures in 781 [RFC3688] 783 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 785 Registrant Contact: IETF GEOPRIV working group, (geopriv@ietf.org), 786 James Winterbottom (james.Winterbottom@commscope.com) 788 XML: The XML for this schema can be found as the entirety of 789 Section 5.5 of this document. 791 9. Acknowledgements 793 Thanks to anyone who has tried to extend the civic schema and found 794 it a little less than intuitive. 796 10. References 798 10.1. Normative References 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 803 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 804 10646", STD 63, RFC 3629, November 2003. 806 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 807 January 2004. 809 [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, 810 "Threat Analysis of the Geopriv Protocol", RFC 3694, 811 February 2004. 813 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 814 (DHCPv4 and DHCPv6) Option for Civic Addresses 815 Configuration Information", RFC 4776, November 2006. 817 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 818 Format for Presence Information Data Format Location 819 Object (PIDF-LO)", RFC 5139, February 2008. 821 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 822 Tschofenig, "LoST: A Location-to-Service Translation 823 Protocol", RFC 5222, August 2008. 825 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 826 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 827 May 2008. 829 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 830 Tschofenig, H., and H. Schulzrinne, "An Architecture for 831 Location and Location Privacy in Internet Applications", 832 BCP 160, RFC 6280, July 2011. 834 [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, 835 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 836 Consortium Recommendation REC-xml-names11-20060816, 837 August 2006, 838 . 840 10.2. Informative References 842 [RFC4079] Peterson, J., "A Presence Architecture for the 843 Distribution of GEOPRIV Location Objects", RFC 4079, 844 July 2005. 846 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 847 Emergency Context Resolution with Internet Technologies", 848 RFC 5012, January 2008. 850 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 851 Addresses in the Presence Information Data Format Location 852 Object (PIDF-LO): Guidelines and IANA Registry 853 Definition", BCP 154, RFC 5774, March 2010. 855 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 856 RFC 5985, September 2010. 858 Authors' Addresses 860 James Winterbottom 861 CommScope 862 Suit 1, Level 2 863 iC Enterprise 1, Innovation Campus 864 Squires Way 865 North Wollongong, NSW 2500 866 AU 868 Phone: +61 242 212938 869 Email: james.winterbottom@commscope.com 870 Martin Thomson 871 Skype 872 3210 Porter Drive 873 Palo Alto, California 94304 874 US 876 Email: martin.thomson@gmail.com 878 Richard Barnes 879 BBN Technologies 880 9861 Broken Land Parkway 881 Columbia, MD 21046 882 US 884 Phone: +1 410 290 6169 885 Email: rbarnes@bbn.com 887 Brian Rosen 888 NeuStar, Inc. 889 470 Conrad Dr 890 Mars, PA 16046 891 US 893 Email: br@brianrosen.net 895 Robins George 896 Huawei Technologies 897 Huawei Base, Bantian, Longgan District 898 Shenzhen, Guangdong 518129 899 P. R. China 901 Phone: +86 755 2878 8314 902 Email: robinsgv@gmail.com