idnits 2.17.1 draft-ietf-geopriv-revised-civic-lo-06.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 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. 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 directly say this. It does mention RFC4119 though, so this could be OK. 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 (October 17, 2007) is 6036 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 October 17, 2007 6 Expires: April 19, 2008 8 Revised Civic Location Format for PIDF-LO 9 draft-ietf-geopriv-revised-civic-lo-06.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 April 19, 2008. 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 and replaces the civic location format in RFC 45 4119. The format is based on the civic address definition in 46 PIDF-LO, but adds several new elements based on the civic types 47 defined for DHCP, and adds a hierarchy to address complex road 48 identity schemes. The format also includes support for the xml:lang 49 language tag and restricts the types of elements where 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 Field | CAtype | Description | Example | 123 +-----------+--------+-------------------------------+--------------+ 124 | BLD | 25 | Building (structure) | Hope Theatre | 125 | | | | | 126 | UNIT | 26 | Unit (apartment, suite) | 12a | 127 | | | | | 128 | ROOM | 28 | Room | 450F | 129 | | | | | 130 | PLC | 29 | Place-type | office | 131 | | | | | 132 | PCN | 30 | Postal community name | Leonia | 133 | | | | | 134 | POBOX | 31 | Post office box (P.O. box) | U40 | 135 | | | | | 136 | ADDCODE | 32 | Additional Code | 13203000003 | 137 | | | | | 138 | SEAT | 33 | Seat (desk, cubicle, | WS 181 | 139 | | | workstation) | | 140 | | | | | 141 | RD | 34 | Primary road or street | Broadway | 142 | | | | | 143 | RDSEC | 35 | Road section | 14 | 144 | | | | | 145 | RDBR | 36 | Road branch | Lane 7 | 146 | | | | | 147 | RDSUBBR | 37 | Road sub-branch | Alley 8 | 148 | | | | | 149 | PRM | 38 | Road pre-modifier | Old | 150 | | | | | 151 | POM | 39 | Road post-modifier | Extended | 152 +-----------+--------+-------------------------------+--------------+ 154 Table 1: New Civic PIDF-LO Types 156 A complete description of these types is included in [RFC4776]. 158 3.2. New Thoroughfare Elements 160 In some countries a thoroughfare can be broken up into sections, and 161 it is not uncommon for street numbers to be repeated between 162 sections. A road section identifier is required to ensure that an 163 address is unique. For example, "West Alice Parade" has 5 sections, 164 each numbered from 1; unless the section is specified "7 West Alice 165 Parade" could exist in 5 different places. The "RDSEC" element is 166 used to specify the section. 168 Minor streets can share the same name, so that they can only be 169 distinguished by the major thoroughfare with which they intersect. 170 For example, both "West Alice Parade, Section 3" and "Bob Street" 171 could both be interested by a "Carol Lane". The "RDBR" element is 172 used to specify a road branch where the name of the branch does not 173 uniquely identify the road. Road branches MAY also be used where a 174 major thoroughfare is split into sections. 176 Similar to the way that a road branch is associated with a road, a 177 road sub-branch is associated with a road branch. The "RDSUBBR" 178 element is used to identify road sub-branches. 180 The "A6" element is retained for use in those countries that require 181 this level of detail. Where "A6" was previously used for street 182 names in [RFC4119], it MUST NOT be used, the "RD" element MUST be 183 used for thoroughfare data. However, without additional information 184 these fields MUST not be interchanged when converting between 185 different civic formats. Where civic address information is obtained 186 from another format, such as the DHCP form [RFC4776], the "A6" 187 element MUST be copied directly from the source format. 189 The following example figure shows a fictional arrangement of roads 190 where these new thoroughfare elements are applicable. 192 | || 193 | ---------------|| 194 | Carol La. Carol La. || Bob 195 | || St. 196 | West Alice Pde. || 197 ==========/=================/===============/==========||=========== 198 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5 199 | || 200 ----------| Carol || 201 Alley 2 | La. || 202 | || 204 3.2.1. Street Numbering 206 The introduction of new thoroughfare elements affects the 207 interpretation of several of more specific civic address data. In 208 particular, street numbering (the "HNO" element) applies to the most 209 specific road element specified. That is, the first specified 210 element from: "RDSUBBR", "RDBR", "RDSEC", or "RD". 212 3.2.2. Directionals and other Qualifiers 214 The "PRM", "POM", "PRD", "POD" and "STS" elements always apply to the 215 value of the "RD" element only. If road branches or sub-branches 216 require street suffixes or qualifiers, they MUST be included in the 217 "RDBR" or "RDSUBBR" element text. 219 3.3. Country Element 221 The "country" element differs from that defined in [RFC4119] in that 222 it now restricts the value space of the element to two upper case 223 characters, which correspond to the alpha-2 codes in [ISO.3166-1]. 225 3.4. A1 Element 227 The "A1" element is used for the top level subdivision within a 228 country. In the absence of a country-specific guide on how to use 229 the A-series of elements, the second part of the ISO 3166-2 code 230 [ISO.3166-2] for a country subdivision SHOULD be used. The ISO 231 3166-2 code is a formed of a country code and hyphen plus a code of 232 one, two or three characters or numerals. For the "A1" element, the 233 leading country code and hyphen are omitted and only the subdivision 234 code is included. 236 For example, the codes for Canada include CA-BC, CA-ON, CA-QC; 237 Luxembourg has just three single character codes: LU-D, LU-G and 238 LU-L; Australia uses both two and three character codes: AU-ACT, AU- 239 NSW, AU-NT; France uses numerical codes for mainland France and 240 letters for territories: FR-75, FR-NC. This results in the following 241 fragments: 243 CAON 245 LUL 247 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 language-neutral values. The range of allowed 256 values for "country" are defined in [ISO.3166-1]; the range of 257 allowed values for "PLC" are defined in the IANA registry defined by 258 [RFC4589]. 260 The "script" field defined in [RFC4776] is omitted in favour of using 261 the "xml:lang" attribute. 263 It is RECOMMENDED that each "civicAddress" element use one language 264 only, or a combination of languages that is consistent. Where a 265 civic location is represented in multiple languages multiple 266 "civicAddress" elements SHOULD be included in the PIDF-LO document. 267 For civic addresses that form a complex to describe the same 268 location, these SHOULD be inserted into the same tuple. 270 3.5.1. Converting from the DHCP Format 272 The DHCP format for civic addresses [RFC4776] permits the inclusion 273 of an element multiple times with different languages or scripts. 274 However, this XML form only permits a single instance of each 275 element. Multiple "civicAddress" elements are required if any 276 element is duplicated with different languages. If the same language 277 and script is used for all elements, or no elements are duplicated, 278 the format can be converted into a single civic address. 280 Where there are duplicated elements in different languages, a 281 "civicAddress" element is created for each language that is present. 282 All elements that are in that language are included. Elements that 283 are language independent, like the "country" and "PLC" elements, are 284 added to all "civicAddress" elements. 286 3.5.2. Combining Multiple Elements Based on Language Preferences 288 If the receiver of the XML representation is known, and that receiver 289 has indicated language preferences, a single XML format can be 290 constructed using those preferences. For example, language 291 preferences can be indicated by the "Accept-Language" header in the 292 SIP or HTTP protocols. 294 All elements that have only one value, irrespective of language, are 295 used. Where multiple values exist, each value is assigned a 296 weighting based on the language preferences. The value with the 297 highest weighting is selected. An arbitrary value is selected if two 298 values have the same preference, if there is no preference for the 299 available languages, or if there are conflicting values with the same 300 language. 302 3.6. Whitespace 304 The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 305 uses a base type of "token" instead of "string" as used in [RFC4119]. 307 The "token" type ensures that whitespace within instance documents is 308 normalized and collapsed before being passed to a processor. This 309 ensures that the following fragments are considered equivalent by XML 310 processors: 312 North Wollongong 314 North 315 Wollongong 317 318 North Wollongong 319 321 Whitespace may still be included in values by using character 322 references, such as " ". 324 4. Civic Address Schema 326 327 334 337 338 339 340 341 343 344 345 346 347 348 349 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 383 384 385 387 388 389 390 392 5. Example 394 396 AU 397 NSW 398 Wollongong 399 North Wollongong 400 401 FlindersStreet 402 Campbell Street 403 404 Gilligan's Island 405 Corner 406 Video Rental Store 407 2500 408 Westerns and Classics 409 store 410 Private Box 15 411 413 6. Security Considerations 415 The XML representation described in this document is designed for 416 inclusion in a PIDF-LO document. As such, it is subject to the same 417 security considerations as are described in [RFC4119]. 418 Considerations relating to the inclusion of this representation in 419 other XML documents are outside the scope of this document. 421 7. IANA Considerations 423 7.1. URN sub-namespace registration for 424 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' 426 This document calls for IANA to register a new XML namespace, as per 427 the guidelines in [RFC3688]. 429 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 431 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 432 Martin Thomson (martin.thomson@andrew.com). 434 XML: 436 BEGIN 437 438 440 441 442 GEOPRIV Civic Address 443 444 445

Format for Distributing Civic Address in GEOPRIV

446

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

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

See RFCXXXX.

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