idnits 2.17.00 (12 Aug 2021) /tmp/idnits23571/draft-ietf-geopriv-local-civic-03.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 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 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 (Feb 2012) is 3748 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 337 -- Looks like a reference, but probably isn't: '1' on line 338 == Missing Reference: 'XX' is mentioned on line 344, 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 (==), 6 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 (if approved) M. Thomson 5 Intended status: Standards Track Skype 6 Expires: August 4, 2012 R. Barnes 7 BBN Technologies 8 B. Rosen 9 NeuStar, Inc. 10 R. George 11 Huawei Technologies 12 Feb 2012 14 Specifying Civic Address Extensions in PIDF-LO 15 draft-ietf-geopriv-local-civic-03 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 protocol mechanism that returns civic address 26 element names used for validation of location information is 27 clarified to require a namespace on each element. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 4, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Motivating Example . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Specifying Civic Address Extensions . . . . . . . . . . . . . 4 67 3. Translating Unsupported Elements . . . . . . . . . . . . . . . 6 68 3.1. XML to DHCP Format Translation . . . . . . . . . . . . . . 6 69 3.2. Extension Civic Address Type (CAtype) . . . . . . . . . . 6 70 3.3. DHCP to XML Format Translation . . . . . . . . . . . . . . 7 71 3.4. Conversion Example . . . . . . . . . . . . . . . . . . . . 7 72 4. CAtypes Registry . . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Civic Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Pole Number . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Mile Post . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.3. Street Type Prefix . . . . . . . . . . . . . . . . . . . . 10 77 5.4. House Number Prefix . . . . . . . . . . . . . . . . . . . 10 78 5.5. XML Extension Schema . . . . . . . . . . . . . . . . . . . 11 79 5.6. Extension examples . . . . . . . . . . . . . . . . . . . . 11 80 6. Using Local Civic Extension with the LoST Protocol . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 8.1. CAtype Registration for Extensions . . . . . . . . . . . . 14 84 8.2. Changes to the CAtype Registry . . . . . . . . . . . . . . 14 85 8.3. URN sub-namespace registration for 86 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' . . 14 87 8.4. XML Schema Registration . . . . . . . . . . . . . . . . . 15 88 8.5. Registration Template . . . . . . . . . . . . . . . . . . 15 89 8.6. Registration Policy and Expert Guidance . . . . . . . . . 17 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 The Geopriv civic location specifications ([RFC4776], [RFC5139]) 99 define an XML and binary representations for civic addresses that 100 allow for the expression of civic addresses. Guidance for the use of 101 these formats for the civic addresses in different countries is 102 included in [RFC5774]. 104 Subsequent to these specifications being produced, use cases for 105 extending the civic address format with new elements have emerged. 106 Extension elements do not readily fit existing elements, as 107 recommended in [RFC5774]. 109 The XML format for civic addresses [RFC5139] provides a mechanism 110 that allows for the addition of standardized or privately understood 111 elements. A similar facility for private extension is not provided 112 for the DHCP format [RFC4776], though new specifications are able to 113 define new CAtypes (civic address types). 115 A recipient of a civic address in either format currently has no 116 option other than to ignore elements that it does not understand. 117 This results in any elements that are unknown to that recipient being 118 discarded if a recipient performs a translation between the two 119 formats. In order for a new extension to be preserved through 120 translation by any recipient, the recipient has to understand the 121 extension and know how to correlate an XML element with a CAtype. 123 This document describes how new civic address elements are added. 124 Extensions always starts with the definition of XML elements. A 125 mechanism for carrying the extension in the DHCP format is described. 126 A new XML namespace containing a small number of additional civic 127 elements is also defined and can be used as a template to illustrate 128 how other extensions can be defined as required. 130 These mechanisms ensure that any translation between formats can be 131 performed consistently and without loss of information. Translation 132 between formats can occur without knowledge of every extension that 133 is present. 135 The registry of numeric CAtypes is modified so that creators of 136 extension can advertise new namespaces and the civic elements to 137 encourage maximum reuse. 139 The additions described in this document are backwardly compatible. 140 Existing implementations may cause extension information to be lost, 141 but the presence of extensions does not affect an implementation that 142 conforms to either [RFC4776] or [RFC5139]. 144 This document also normatively updates [RFC5222] to clarify that the 145 namespace must be included with the element name in the lists of 146 valid, invalid and not checked elements in the 147 part of a LoST response. While the LoST schema does not need to be 148 changed, the example in the document is updated to show the 149 namespaces in the lists. 151 1.1. Motivating Example 153 One instance where translation might be necessary is where a device 154 receives location configuration using DHCP [RFC4776]. Conversion of 155 DHCP information to an XML form is necessary if the device wishes to 156 use the DHCP-provided information in a range of applications, 157 including location-based presence services [RFC4079], and emergency 158 calling [RFC5012]. 160 +--------+ +--------+ +-----------+ 161 | DHCP | DHCP | Device | XML | Recipient | e.g., Presence 162 | Server |--------->| |-------->| | Agent 163 +--------+ +--------+ +-----------+ 165 Conversion Scenario 167 The Device that performs the translation between the DHCP and XML 168 formats might not be aware of some of the extensions that are in use. 169 Without knowledge of these extensions and how they are represented in 170 XML, the Device is forced to discard them. 172 These extensions could be useful - or critical - to the ultimate 173 consumers of this information. For instance, an extension element 174 might provide a presence watcher with important information in 175 locating the Device or an extension might be significant in choosing 176 a particular call route. 178 1.2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. Specifying Civic Address Extensions 186 The civic schema in [RFC5139] defines an ordered structure of 187 elements that can be combined to describe a civic address. The XML 188 extension point at the end of this sequence is used to extend the 189 address. 191 New elements are defined in a new XML namespace [XMLNS]. This is 192 true of address elements with significance within private or 193 localized domains, as well as those that are intended for global 194 applicability. 196 New elements SHOULD use the basic "caType" schema type defined in 197 [RFC5139]. This type provides an optional "xml:lang" attribute. 199 For example, suppose the (fictitious) Central Devon Canals Authority 200 wishes to introduce a new civic element called "bridge". The 201 authority defines an XML namespace that includes a "bridge" element. 202 The namespace needs to be a unique URI, for example 203 "http://devon.canals.org.uk/civic". 205 A civic address that includes the new "bridge" element is shown in 206 Figure 1. 208 211 UK 212 Devon 213 Monkokehampton 214 Deckport 215 Cross 217 21451338 219 221 Figure 1: Extended Civic Address Example 223 An entity that receives this location information might not 224 understand the extension address element. As long as the added 225 element is able to be safely ignored, the remainder of the civic 226 address can be used. The result is that the information is not as 227 useful as it could be, but the added element does not prevent the use 228 of the remainder of the address. 230 The address can be passed to other applications, such as a LoST 231 server [RFC5222], without modification. If the application 232 understands the added elements, it is able to make use of that 233 information. For example, if this civic address is acquired using 234 HELD [RFC5985], it can be included in a LoST request directly. 236 3. Translating Unsupported Elements 238 Unsupported civic address elements can be carried without consequence 239 only as long as the format of the address does not change. When 240 converting between the XML and DHCP formats, these unsupported 241 elements are necessarily discarded: the entity performing the 242 translation has no way to know the correct element to use in the 243 target format. 245 All extensions MUST be defined using the mechanism described in this 246 document. Extensions that use numeric CAtypes or other mechanisms 247 cannot be safely translated between XML and DHCP representations. 249 An entity that does not support these extension mechanisms is 250 expected to remove elements it doesn't understand when performing 251 conversions. 253 3.1. XML to DHCP Format Translation 255 Extensions to the XML format [RFC5139] are defined in a new XML 256 namespace [XMLNS]. 258 Extensions in the XML format can be added to a DHCP format civic 259 address using an extension CAtype. 261 3.2. Extension Civic Address Type (CAtype) 263 The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor: 264 please replace XX here and in the figure below with the assigned 265 code] includes three values that uniquely identify the XML extension 266 and its value: a namespace URI, the local name of the XML element, 267 and the text content of that element. These three values are all 268 included in the value of the CAtype, each separated by a single 269 whitespace character. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | CAtype (XX) | Length | Namespace URI ... . 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 . Namespace URI (continued) ... . 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Space (U+20) | XML element local name ... . 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Space (U+20) | Extension type value ... . 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: XML Civic Address Extension CAtype 285 The content of a CAtype (after the CAtype code and length) is UTF-8 286 encoded Unicode text [RFC3629]. A maximum of 255 octets is allowed. 287 Octets consumed by the namespace URI and local name reduce the space 288 available for values. 290 This conversion only works for elements that have textual content and 291 an optional "xml:lang" attribute. Elements with complex content or 292 other attributes - aside from namespace bindings - MUST be ignored if 293 they are not understood. 295 3.3. DHCP to XML Format Translation 297 The registration of a new CAtype following the process in [RFC4776] 298 means that a recipient that does not know the equivalent XML is 299 unable to produce a complete XML representation of the DHCP civic 300 address. For this reason, this document ends the registration of new 301 numeric CAtypes. No new registrations of numeric CAtypes can be 302 made. 304 In lieu of making new numerical CAtype assignments, this document 305 creates a new extensionCA type which is defined in a manner that lets 306 new civic elements be described in DHCP form by carrying the name 307 space and type name of the extension in parameters of the extensionCA 308 type. 310 When converting to XML, the namespace prefix used for the extension 311 element is selected by the entity that performs the conversion. 313 3.4. Conversion Example 314 The following example civic address contains two extensions: 316 320 US 321 CA 323 2471 324 AQ-374-4(c) 326 LAX 327 Tom Bradley 328 G 329 36B 330 332 Figure 3: XML Example with Multiple Extensions 334 This is converted to a DHCP form as follows: 336 country = US 337 CAtype[0] = en-US 338 CAtype[1] = CA 339 CAtype[XX] = http://postsoftheworld.net/ns lamp 2471 340 CAtype[XX] = http://postsoftheworld.net/ns lamp AQ-374-4(c) 341 CAtype[XX] = http://example.com/airport/5.0 airport LAX 342 CAtype[XX] = http://example.com/airport/5.0 terminal Tom Bradley 343 CAtype[XX] = http://example.com/airport/5.0 concourse G 344 CAtype[XX] = http://example.com/airport/5.0 gate 36B 346 Figure 4: Converted DHCP Example with Multiple Extensions 348 4. CAtypes Registry 350 [RFC4776] created the CAtype registry. Among other things, this 351 registry advertised available civic elements. While it has always 352 been possible to use an extension namespace to define civic elements 353 that are not in the CAtype registry, and this document does not 354 change that, the registry is valuable to alert implementors of 355 commonly used civic elements and provides guidance to clients of what 356 elements they should suppport. 358 This document alters the CAtype registry in several ways. It closes 359 the registry to new numeric CAtypes. It deletes the "NENA" column, 360 which is not needed. It adds columns for a namespace and contact, 361 and changes the name of the column currently called "PIDF" to "Local 362 Name". It also adds a column to the registry called "Type". "Type" 363 can have one of two values "A" and "B". Type A elements are intended 364 for wide use with many applications and SHOULD be implemented by all 365 clients unless the client is certain the element will not be 366 encountered. Type "B" civic elements MAY be implemented by any 367 client. 369 Type A civic elements require IETF review, while Type B elements only 370 require an expert review. 372 5. Civic Extensions 374 We use this new extension method to define some additional civic 375 address elements which are needed to correctly encode civic locations 376 in several countries. The definition of these new civic address 377 elements also serves as an example of how to define additional 378 elements using the mechanisms described in this document. 380 5.1. Pole Number 382 In some areas, utility and lamp posts carry a unique identifier, 383 which we call a pole number in this document. In some countries, the 384 label on the lamp post also carries the local emergency service 385 number, such as "110", encouraging callers to use the pole number to 386 identify their location. 388 _.-----,===. 389 | | (''''') 390 | | `---' 391 | | 392 | | ,---------, 393 | | ,---, |Emergency| 394 | | /|,-.|----->| Number | 395 | | / |110| '---------' 396 | | / |`-'| 397 |_|/ | 2 | ,---------, 398 | | | 1 | |Lamp Post| 399 | | | 2 |----->| Number | 400 |-| | 1 | '---------' 401 | |\ | 0 | 402 | | \ | 1 | 403 | | \ | 4 | 404 | | \|,,,| 405 _ | | 406 ``-..|.| 407 ``--.._ 408 `'--.._ 410 Figure 5: Lamp post with emergency number 412 5.2. Mile Post 414 On some roads, trails, railroad rights of way and other linear 415 features, a post with a mile or kilometer distance from one end of 416 the feature may be found (a "milepost"). There are other cases of 417 poles or markers with numeric indications that are not the same as a 418 "house number" or street address number. 420 5.3. Street Type Prefix 422 The civic schema defined in [RFC5139] allows the definition of 423 address "123 Colorado Boulevard", but it does not allow for the easy 424 expression of "123 Boulevard Colorado". Adding a street-type prefix, 425 allows street named in this manner to be more easily represented. 427 5.4. House Number Prefix 429 The civic schema defined in [RFC5139] provides house number suffix 430 element, allowing one to express an address like "123A Main Street", 431 but it does not contain a corresponding house number prefix. The 432 house number prefix element allows the expression of address such as 433 "Z123 Main Street". 435 5.5. XML Extension Schema 437 438 446 448 449 451 452 454 455 457 458 460 462 5.6. Extension examples 464 US 468 CA 469 Sacramento 470 I5 471 248 472 22-109-689 473 475 XML Example with Post Number and Mile Post 477 US 481 CA 482 Sacramento 483 Colorado 484 223 485 Boulevard 486 A 487 489 XML Example with Street prefix and House Number Prefix 491 6. Using Local Civic Extension with the LoST Protocol 493 One critical use of civic location information is in next generation 494 emergency services applications, in particular call routing 495 applications. In such cases location information is provided to a 496 location-based routing service using the location to service 497 transtion (LoST) protcol [RFC5222]. LoST is used to provide call 498 routing information, but it is also used to validate location 499 information to ensure that it can route to an emergency center when 500 required. 502 LoST is an XML-based protocol and so the namespace extension 503 mechansims described in this document do not impact LoST. When LoST 504 is used for validation a element is returned 505 containing a list of valid, a list of invalid, and a list of 506 unchecked civic elements. Figure 6 is an extract of the validation 507 response in Figure 6 from [RFC5222]. 509 510 country A1 A3 A6 511 PC 512 HNO 513 515 Figure 6: Location Validation Example from LoST (RFC5222) 517 The RelaxNG schema in [RFC5222] requires the elements in each of 518 these lists to be namespace qualified, which makes the example in 519 Figure 6 from [RFC5222] in error. This issue is especially 520 significant when local-civic extensions are used as the domain to 521 which the extensions are attributed may impact their interpretation 522 by the server or client. To ensure that local-civic extensions do 523 not cause issues with LoST server and client implementations, all 524 elements listed in a , , or element MUST 525 be qualified with a namespace. To illustrate this the extract above 526 from figure 6 in [RFC5222] becomes Figure 7. 528 530 ca:country ca:A1 ca:A3 ca:A6 531 ca:PC 532 ca:HNO 533 535 Figure 7: Corrected Location Validation Example 537 If validation request has also included the extensions defined in 538 section Section 5 then the validation would response would look like 539 Figure 8. 541 544 ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP 545 ca:PC 546 ca:HNO cae:MP cae:HNP 547 549 Figure 8: Corrected Location Validation Example 551 7. Security Considerations 553 This document defines a formal way to extend the existing Geopriv 554 civic address schema. No security threats are introduced by this 555 document. 557 Security threats applicable to the civic address formats are 558 described in [RFC4776] (DHCP) and [RFC5139] (XML). 560 8. IANA Considerations 562 This document alters the "CAtypes" registry established by [RFC4776]. 564 8.1. CAtype Registration for Extensions 566 IANA has allocated a CAtype code of XX for the extension CAtype. 568 [[IANA/RFC-EDITOR: Please replace XX with the allocated CAtype]] 570 8.2. Changes to the CAtype Registry 572 No further registration of numeric CAtypes is permitted. 574 The column called "NENA" is removed. 576 The column called "PIDF" is renamed to "Local Name". 578 New columns are added named "Namespace URI", "Contact", "Schema" and 579 "Type". 581 New registrations use the registration template in Section 8.5. 583 8.3. URN sub-namespace registration for 584 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext' 586 This document calls for IANA to register a new XML namespace, as per 587 the guidelines in [RFC3688]. 589 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 591 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 592 James Winterbottom (james.winterbottom@commscope.com). 594 XML: 596 BEGIN 597 598 600 601 602 GEOPRIV Civic Address Extensions 603 604 605

Additional Fields for GEOPRIV Civic Address

606

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

607 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 608 with the RFC number for this specification.]] 609

See RFCXXXX.

610 611 613 END 615 8.4. XML Schema Registration 617 This section registers an XML schema as per the procedures in 618 [RFC3688]. 620 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 622 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 623 James Winterbottom (james.Winterbottom@commscope.com). 625 The XML for this schema can be found as the entirety of 626 Section 5.5 of this document. 628 8.5. Registration Template 630 New registrations in the "CAtypes" registry require the following 631 information: 633 CAtype: The assigned numeric CAtype. All new registrations use the 634 value XX. [[IANA/RFC-Editor: update XX] Existing registrations 635 use their assigned value. 637 Namespace URI: A unique identifier for the XML namespace used for 638 the extension element. 640 Local Name: The local name of an XML element that carries the civic 641 address element. 643 Description: A brief description of the semantics of the civic 644 address element. 646 (Optional) Example: One or more simple examples of the element. 648 Contact: Contact details for the person providing the extension. 650 (Optional) Specification: A reference to a specification for the 651 civic address element. 653 (Optional) Schema: A reference to a formal schema (XML schema, 654 RelaxNG, or other form) that defines the extension. 656 Type: If Type is "A", all clients SHOULD implement this element. If 657 Type is "B", clients MAY implement this element. 659 Registrations from [RFC4776] and [RFC5139] are registered with the 660 following form: 662 CAtype: (The existing CAtype.) 664 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 666 Local Name: (The contents of the PIDF column.) 668 Description: (The existing description for the element.) 670 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 671 (geopriv@ietf.org). 673 Specification: RFC4776 and RFC5139 675 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 677 Type: A 679 Registration of the schema defined in this document in Section 5.5. 681 CAtype: The assigned numeric CAtype value is XX. [[IANA/RFC-Editor: 682 update XX] 684 Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext 686 Local Name: PN, MP, STP, HNP 688 Description: PN: Post number that is attributed to a lamp post or 689 utility pole. 691 Description: MP: Mile Post a marker indicating distance to or from a 692 place (often a town). 694 Description: STP: Street Type Prefix. 696 Description: HNP: House Number Prefix. 698 Contact: The IESG (iesg@ietf.org); the GEOPRIV working group 699 (geopriv@ietf.org). 701 Specification: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC 702 URL and replace XXXX with the RFC number for this specification.]] 704 Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext 706 Type: A 708 8.6. Registration Policy and Expert Guidance 710 The "CAtypes" registry is altered to operate on a registration policy 711 of "Expert Review", and optionally "Specification Required" [RFC5226] 712 if the element being registered has a Type value of "B". 714 The registration rules for "Specification Required" are followed only 715 if a registration includes a reference to a specification. 716 Registrations can be made without a specification reference. 718 If the element being registered has a Type value of "A" then the 719 registration policy is "IETF Review". 721 All registrations are reviewed to identify potential duplication 722 between registered elements. Duplicated semantics are not prohibited 723 in the registry, though it is preferred if existing elements are 724 used. The expert review is advised to recommend the use of existing 725 elements following the guidance in [RFC5774]. Any registration that 726 is a duplicate or could be considered a close match for the semantics 727 of an existing element SHOULD include a discussion of the reasons 728 that the existing element was not reused. 730 9. Acknowledgements 732 Thanks to anyone who has tried to extend the civic schema and found 733 it a little unintuitive. 735 10. References 737 10.1. Normative References 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 743 January 2004. 745 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 746 (DHCPv4 and DHCPv6) Option for Civic Addresses 747 Configuration Information", RFC 4776, November 2006. 749 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 750 Format for Presence Information Data Format Location 751 Object (PIDF-LO)", RFC 5139, February 2008. 753 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 755 Tschofenig, "LoST: A Location-to-Service Translation 756 Protocol", RFC 5222, August 2008. 758 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 759 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 760 May 2008. 762 [XMLNS] Hollander, D., Layman, A., Tobin, R., and T. Bray, 763 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 764 Consortium Recommendation REC-xml-names11-20060816, 765 August 2006, 766 . 768 10.2. Informative References 770 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 771 10646", STD 63, RFC 3629, November 2003. 773 [RFC4079] Peterson, J., "A Presence Architecture for the 774 Distribution of GEOPRIV Location Objects", RFC 4079, 775 July 2005. 777 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 778 Emergency Context Resolution with Internet Technologies", 779 RFC 5012, January 2008. 781 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 782 Addresses in the Presence Information Data Format Location 783 Object (PIDF-LO): Guidelines and IANA Registry 784 Definition", BCP 154, RFC 5774, March 2010. 786 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 787 RFC 5985, September 2010. 789 Authors' Addresses 791 James Winterbottom 792 CommScope 793 Suit 1, Level 2 794 iC Enterprise 1, Innovation Campus 795 Squires Way 796 North Wollongong, NSW 2500 797 AU 799 Phone: +61 242 212938 800 Email: james.winterbottom@commscope.com 801 Martin Thomson 802 Skype 803 3210 Porter Drive 804 Palo Alto, California 94304 805 US 807 Email: martin.thomson@gmail.com 809 Richard Barnes 810 BBN Technologies 811 9861 Broken Land Parkway 812 Columbia, MD 21046 813 US 815 Phone: +1 410 290 6169 816 Email: rbarnes@bbn.com 818 Brian Rosen 819 NeuStar, Inc. 820 470 Conrad Dr 821 Mars, PA 16046 822 US 824 Email: br@brianrosen.net 826 Robins George 827 Huawei Technologies 828 Huawei Base, Bantian, Longgan District 829 Shenzhen, Guangdong 518129 830 P. R. China 832 Phone: +86 755 2878 8314 833 Email: robinsg@huawei.com