idnits 2.17.1 draft-ietf-geopriv-revised-civic-lo-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. 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 RFC4119, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "A6" element is retained for use in those countries that require this level of detail. Where "A6" was previously used for street names in [RFC4119], it MUST NOT be used, the "RD" element MUST be used for thoroughfare data. However, without additional information these fields MUST not be interchanged when converting between different civic formats. Where civic address information is obtained from another format, such as the DHCP form [RFC4776], the "A6" element MUST be copied directly from the source format. (Using the creation date from RFC4119, updated by this document, for RFC5378 checks: 2004-01-14) -- 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 (February 15, 2007) is 6281 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Thomson 3 Internet-Draft J. Winterbottom 4 Updates: 4119 (if approved) Andrew 5 Intended status: Standards Track February 15, 2007 6 Expires: August 19, 2007 8 Revised Civic Location Format for PIDF-LO 9 draft-ietf-geopriv-revised-civic-lo-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 19, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines an XML format for the representation of civic 43 location. This format is designed for use with PIDF Location Object 44 (PIDF-LO) documents. The format is based on the civic address 45 definition in PIDF-LO, but adds several new elements based on the 46 civic types defined for DHCP, and adds a hierarchy to address complex 47 road identity schemes. The format also includes support for the 48 xml:lang language tag and restricts the types of elements where 49 appropriate. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5 57 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6 58 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7 59 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7 60 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7 61 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8 63 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8 64 3.5.2. Combining Multiple Elements Based on Language 65 Preferences . . . . . . . . . . . . . . . . . . . . . 8 66 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10 68 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. URN sub-namespace registration for 72 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14 73 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 74 7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 15 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 Intellectual Property and Copyright Statements . . . . . . . . . . 19 82 1. Introduction 84 Since the publication of the original PIDF-LO civic specification, in 85 [RFC4119], it has been found that the specification is lacking a 86 number of additional parameters that can be used to more precisely 87 specify a civic location. These additional parameters have been 88 largely captured in [RFC4776]. 90 This document revises the GEOPRIV civic form to include the 91 additional civic parameters captured in [RFC4776]. The document also 92 introduces a hierarchical structure for thoroughfare (road) 93 identification which is employed in some countries. New elements are 94 defined to allow for even more precision in specifying a civic 95 location. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 The term "thoroughfare" is used in this document to describe a road 104 or part of a road or other access route along which a final point is 105 identified. This is consistent with the definition used in 106 [UPU-S42]. 108 3. Changes from PIDF-LO 110 3.1. Additional Civic Address Types 112 [RFC4776] provides a full set of parameters that may be used to 113 describe a civic location. Specifically [RFC4776] lists several 114 civic address types (CAtypes) that require support in the formal 115 PIDF-LO definition that are not in [RFC4119]. 117 These changes include and new elements that are required to support 118 more complex structures for naming street addresses, this is 119 described in more detail in Section 3.2. 121 +---------------+--------+----------------------------+-------------+ 122 | New Civic | CAtype | Description | Example | 123 | Field | | | | 124 +---------------+--------+----------------------------+-------------+ 125 | BLD | 25 | Building (structure) | Hope | 126 | | | | Theatre | 127 | | | | | 128 | UNIT | 26 | Unit (apartment, suite) | 12a | 129 | | | | | 130 | ROOM | 28 | Room | 450F | 131 | | | | | 132 | PLC | 29 | Place-type | office | 133 | | | | | 134 | PCN | 30 | Postal community name | Leonia | 135 | | | | | 136 | POBOX | 31 | Post office box (P.O. box) | U40 | 137 | | | | | 138 | ADDCODE | 32 | Additional Code | 13203000003 | 139 | | | | | 140 | SEAT | 33 | Seat (desk, cubicle, | WS 181 | 141 | | | workstation) | | 142 | | | | | 143 | RD | 34 | Primary road or street | Broadway | 144 | | | | | 145 | RDSEC | 35 | Road section | 14 | 146 | | | | | 147 | RDBR | 36 | Road branch | Lane 7 | 148 | | | | | 149 | RDSUBBR | 37 | Road sub-branch | Alley 8 | 150 | | | | | 151 | PRM | 38 | Road pre-modifier | Old | 152 | | | | | 153 | POM | 39 | Road post-modifier | Extended | 154 +---------------+--------+----------------------------+-------------+ 155 Table 1: New Civic PIDF-LO Types 157 A complete description of these types is included in [RFC4776]. 159 3.2. New Thoroughfare Elements 161 In some countries a thoroughfare can be broken up into sections, and 162 it is not uncommon for street numbers to be repeated between 163 sections. A road section identifier is required to ensure that an 164 address is unique. For example, "West Alice Parade" has 5 sections, 165 each numbered from 1; unless the section is specified "7 West Alice 166 Parade" could exist in 5 different places. The "RDSEC" element is 167 used to specify the section. 169 Minor streets can share the same name, so that they can only be 170 distinguished by the major thoroughfare with which they intersect. 171 For example, both "West Alice Parade, Section 3" and "Bob Street" 172 could both be interested by a "Carol Lane". The "RDBR" element is 173 used to specify a road branch where the name of the branch does not 174 uniquely identify the road. Road branches MAY also be used where a 175 major thoroughfare is split into sections. 177 Similar to the way that a road branch is associated with a road, a 178 road sub-branch is associated with a road branch. The "RDSUBBR" 179 element is used to identify road sub-branches. 181 The "A6" element is retained for use in those countries that require 182 this level of detail. Where "A6" was previously used for street 183 names in [RFC4119], it MUST NOT be used, the "RD" element MUST be 184 used for thoroughfare data. However, without additional information 185 these fields MUST not be interchanged when converting between 186 different civic formats. Where civic address information is obtained 187 from another format, such as the DHCP form [RFC4776], the "A6" 188 element MUST be copied directly from the source format. 190 The following example figure shows a fictional arrangement of roads 191 where these new thoroughfare elements are applicable. 193 | || 194 | ---------------|| 195 | Carol La. Carol La. || Bob 196 | || St. 197 | West Alice Pde. || 198 ==========/=================/===============/==========||=========== 199 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5 200 | || 201 ----------| Carol || 202 Alley 2 | La. || 203 | || 205 3.2.1. Street Numbering 207 The introduction of new thoroughfare elements affects the 208 interpretation of several of more specific civic address data. In 209 particular, street numbering (the "HNO" element) applies to the most 210 specific road element specified. That is, the first specified 211 element from: "RDSUBBR", "RDBR", "RDSEC", or "RD". 213 3.2.2. Directionals and other Qualifiers 215 The "PRM", "POM", "PRD", "POD" and "STS" elements always apply to the 216 value of the "RD" element only. If road branches or sub-branches 217 require street suffixes or qualifiers, they MUST be included in the 218 "RDBR" or "RDSUBBR" element text. 220 3.3. Country Element 222 The "country" element differs from that defined in [RFC4119] in that 223 it now restricts the value space of the element to two upper case 224 characters, which correspond to the alpha-2 codes in [ISO.3166-1]. 226 3.4. A1 Element 228 The "A1" element is used for the top level subdivision within a 229 country. In the absence of a country-specific guide on how to use 230 the A-series of elements, the second part of the ISO 3166-2 code 231 [ISO.3166-2] for a country subdivision SHOULD be used. The ISO 232 3166-2 code is a formed of a country code and hyphen plus a code of 233 one, two or three characters or numerals. For the "A1" element, the 234 leading country code and hyphen are omitted and only the subdivision 235 code is included. 237 For example, the codes for Canada include CA-BC, CA-ON, CA-QC; 238 Luxembourg has just three single character codes: LU-D, LU-G and 239 LU-L; Australia uses both two and three character codes: AU-ACT, AU- 240 NSW, AU-NT; France uses numerical codes for mainland France and 241 letters for territories: FR-75, FR-NC. This results in the following 242 fragments: 244 CAON 246 LUL 248 AUACT 249 FR75 251 3.5. Languages and Scripts 253 The XML schema defined for civic addresses allows for the addition of 254 the "xml:lang" attribute to all elements except "country" and "PLC", 255 which both contain enumerated values. 257 The "script" field defined in [RFC4776] is omitted in favour of using 258 the "xml:lang" attribute. 260 It is RECOMMENDED that each "civicAddress" element use one language 261 only, or a combination of languages that is consistent. Where a 262 civic location is represented in multiple languages multiple 263 "civicAddress" elements SHOULD be included in the PIDF-LO document. 264 For civic addresses that form a complex to describe the same 265 location, these SHOULD be inserted into the same tuple. 267 3.5.1. Converting from the DHCP Format 269 The DHCP format for civic addresses [RFC4776] permits the inclusion 270 of an element multiple times with different languages or scripts. 271 However, this XML form only permits a single instance of each 272 element. Multiple "civicAddress" elements are required if any 273 element is duplicated with different languages. If the same language 274 and script is used for all elements, or no elements are duplicated, 275 the format can be converted into a single civic address. 277 Where there are duplicated elements in different languages, a 278 "civicAddress" element is created for each language that is present. 279 All elements that are in that language are included. Elements that 280 are language independent, like the "country" and "PLC" elements, are 281 added to all "civicAddress" elements. 283 3.5.2. Combining Multiple Elements Based on Language Preferences 285 If the receiver of the XML representation is known, and that receiver 286 has indicated language preferences, a single XML format can be 287 constructed using those preferences. For example, language 288 preferences can be indicated by the "Accept-Language" header in the 289 SIP or HTTP protocols. 291 All elements that have only one value, irrespective of language, are 292 used. Where multiple values exist, each value is assigned a 293 weighting based on the language preferences. The value with the 294 highest weighting is selected. An arbitrary value is selected if two 295 values have the same preference, if there is no preference for the 296 available languages, or if there are conflicting values with the same 297 language. 299 3.6. Whitespace 301 The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 302 uses a base type of "token" instead of "string" as used in [RFC4119]. 304 The "token" type ensures that whitespace within instance documents is 305 normalized and collapsed before being passed to a processor. This 306 ensures that the following fragments are considered equivalent by XML 307 processors: 309 North Wollongong 311 North 312 Wollongong 314 315 North Wollongong 316 318 Whitespace may still be included in values by using character 319 references, such as " ". 321 4. Civic Address Schema 323 324 331 334 335 336 337 338 340 341 342 343 344 345 346 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 384 385 386 387 389 5. Example 391 392 394 AU 395 NSW 396 Wollongong 397 North Wollongong 398 399 FlindersStreet 400 Campbell Street 401 402 Gilligan's Island 403 Corner 404 Video Rental Store 405 2500 406 Westerns and Classics 407 store 408 Private Box 15 409 411 6. Security Considerations 413 The XML representation described in this document is designed for 414 inclusion in a PIDF-LO document. As such, it is subject to the same 415 security considerations as are described in [RFC4119]. 416 Considerations relating to the inclusion of this representation in 417 other XML documents are outside the scope of this document. 419 7. IANA Considerations 421 7.1. URN sub-namespace registration for 422 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' 424 This document calls for IANA to register a new XML namespace, as per 425 the guidelines in [RFC3688]. 427 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 429 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 430 Martin Thomson (martin.thomson@andrew.com). 432 XML: 434 BEGIN 435 436 438 439 440 GEOPRIV Civic Address 441 442 443

Format for Distributing Civic Address in GEOPRIV

444

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

445 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 446 with the RFC number for this specification.]] 447

See RFCXXXX.

448 449 450 END 452 7.2. XML Schema Registration 454 This section registers an XML schema as per the procedures in 455 [RFC3688]. 457 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 459 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 460 Martin Thomson (martin.thomson@andrew.com). 462 The XML for this schema can be found as the entirety of Section 4 463 of this document. 465 7.3. CAtype Registry Update 467 This document updates the civic address type registry established by 468 [RFC4776]. The "PIDF" column of the CAtypes table has been updated 469 to include the types shown in the first column of Table 1. 471 8. References 473 8.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [W3C.REC-xmlschema-2-20041028] 479 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 480 Second Edition", World Wide Web Consortium 481 Recommendation REC-xmlschema-2-20041028, October 2004, 482 . 484 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 485 (DHCPv4 and DHCPv6) Option for Civic Addresses 486 Configuration Information", RFC 4776, November 2006. 488 [ISO.3166-1] 489 International Organization for Standardization, "Codes for 490 the representation of names of countries and their 491 subdivisions - Part 1: Country codes", ISO Standard 3166- 492 1:1997, 1997, 493 . 495 [ISO.3166-2] 496 International Organization for Standardization, "Codes for 497 the representation of names of countries and their 498 subdivisions - Part 2: Country subdivision code", 499 ISO Standard 3166-2:1998, 1998, 500 . 502 8.2. Informative References 504 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 505 January 2004. 507 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 508 Format", RFC 4119, December 2005. 510 [UPU-S42] Universal Postal Union (UPU), "International Postal 511 Address Components and Templates", UPS SB42-4, July 2004. 513 Appendix A. Acknowledgements 515 The authors would like to thank Henning Schulzrinne for his 516 assistance in defining the additional civic address types, 517 particularly his research into different addressing schemes that lead 518 to the introduction of the thoroughfare elements. Rohan Mahy 519 suggested the ISO 3166-2 recommendation for A1. In addition we would 520 like to thank Jon Peterson for his work in defining the PIDF-LO. 522 Authors' Addresses 524 Martin Thomson 525 Andrew 526 PO Box U40 527 Wollongong University Campus, NSW 2500 528 AU 530 Phone: +61 2 4221 2915 531 Email: martin.thomson@andrew.com 532 URI: http://www.andrew.com/ 534 James Winterbottom 535 Andrew 536 PO Box U40 537 Wollongong University Campus, NSW 2500 538 AU 540 Phone: +61 2 4221 2938 541 Email: james.winterbottom@andrew.com 542 URI: http://www.andrew.com/ 544 Full Copyright Statement 546 Copyright (C) The IETF Trust (2007). 548 This document is subject to the rights, licenses and restrictions 549 contained in BCP 78, and except as set forth therein, the authors 550 retain all their rights. 552 This document and the information contained herein are provided on an 553 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 554 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 555 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 556 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 557 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Intellectual Property 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Acknowledgment 586 Funding for the RFC Editor function is provided by the IETF 587 Administrative Support Activity (IASA).