idnits 2.17.1 draft-ietf-geopriv-revised-civic-lo-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 28, 2006) is 6573 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) == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-location-types-registry-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Expires: October 30, 2006 Andrew 5 April 28, 2006 7 Revised Civic Location Format for PIDF-LO 8 draft-ietf-geopriv-revised-civic-lo-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 30, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines an XML format for the representation of civic 42 location. This format is designed for use with PIDF Location Object 43 (PIDF-LO) documents. The format is based on the civic address 44 definition in PIDF-LO, but adds several new elements based on the 45 civic types defined for DHCP, and adds a hierarchy to address complex 46 road identity schemes. The format also includes support for the 47 xml:lang language tag and restricts the types of elements where 48 appropriate. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5 56 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 7 57 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 8 58 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 8 59 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 9 60 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 9 62 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 11 64 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 7.1. URN sub-namespace registration for 68 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 15 69 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 75 Intellectual Property and Copyright Statements . . . . . . . . . . 20 77 1. Introduction 79 Since the publication of the original PIDF-LO civic specification, in 80 [I-D.ietf-geopriv-pidf-lo], it has been found that the specification 81 is lacking a number of additional parameters that can be used to more 82 precisely specify a civic location. These additional parameters have 83 been largely captured in [I-D.ietf-geopriv-dhcp-civil]. 85 This document revises the GEOPRIV civic form to include the 86 additional civic parameters captured in [I-D.ietf-geopriv-dhcp- 87 civil]. The document also introduces a hierarchical structure for 88 thoroughfare (road) identification which is employed in some 89 countries. New elements are defined to allow for even more precision 90 in specifying a civic location. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 The term "thoroughfare" is used in this document to describe a road 99 or part of a road or other access route along which a final point is 100 identified. This is consistent with the definition used in [UPU- 101 S42]. 103 3. Changes from PIDF-LO 105 3.1. Additional Civic Address Types 107 [I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that 108 may used to describe a civic location. Specifically [I-D.ietf- 109 geopriv-dhcp-civil] lists several civic address types (CAtypes) that 110 require support in the formal PIDF-LO definition that are not in 111 [I-D.ietf-geopriv-pidf-lo]. 113 These changes include and new elements that are required to support 114 more complex structures for naming street addresses, this is 115 described in more detail in Section 3.2. 117 +--------------+--------+-----------------------------+-------------+ 118 | New Civic | CAtype | Description | Example | 119 | Field | | | | 120 +--------------+--------+-----------------------------+-------------+ 121 | BLD | 24 | Building (structure) | Hope | 122 | | | | Theatre | 123 | | | | | 124 | UNIT | 26 | Unit (apartment, suite) | 12a | 125 | | | | | 126 | ROOM | 28 | Room | 450F | 127 | | | | | 128 | PLC | 29 | Place-type | office | 129 | | | | | 130 | POBOX | 31 | Post office box (P.O. box) | U40 | 131 | | | | | 132 | ADDCODE | 32 | Additional Code | 13203000003 | 133 | | | | | 134 | SEAT | 33 | Seat (desk, cubicle, | WS 181 | 135 | | | workstation) | | 136 | | | | | 137 | RD | 34 | Primary road or street | Broadway | 138 | | | | | 139 | RDSEC | 35 | Road section | 14 | 140 | | | | | 141 | RDBR | 36 | Road branch | Lane 7 | 142 | | | | | 143 | RDSUBBR | 37 | Road sub-branch | Alley 8 | 144 | | | | | 145 | PRM | 38 | Road pre-modifier | Old | 146 | | | | | 147 | POM | 39 | Road post-modifier | Extended | 148 +--------------+--------+-----------------------------+-------------+ 150 Table 1: New Civic PIDF-LO Types 152 Building: The "building" (BLD) conveys the name of a single building 153 if the street address includes more than one building or the 154 building name is helpful in identifying the location. (For 155 example, on university campuses, the house number is often not 156 displayed on buildings, while the building name is prominently 157 shown.) 159 Unit: The "unit" (UNIT) contains the name or number of a part of a 160 structure where there are separate administrative units, owners or 161 tenants, such as separate companies or families who occupy that 162 structure. Common examples include suite or apartment 163 designations. 165 Room: A "room" (ROOM) is the smallest identifiable subdivision of a 166 structure. 168 Place type: The "type of place" element (PLC) describes the type of 169 place described by the civic coordinates. For example, it 170 describes whether it is a home, office, street or other public 171 space. The values are drawn from the items in the location types 172 registry [I-D.ietf-geopriv-location-types-registry]. This 173 information makes it easy, for example, for the DHCP client to 174 then populate the presence information. 176 Post office box: The "post office box" element (POBOX) describes a 177 container, such as a pigeon hole, at a central mailing location, 178 where mail is held. 180 Additional code: The "additional code" item (ADDCODE) provides an 181 additional, country-specific code identifying the location. For 182 example, for Japan, it contains the Japan Industry Standard (JIS) 183 address code. The JIS address code provides a unique address 184 inside of Japan, down to the level of indicating the floor of the 185 building. 187 Seat: The "seat" element (SEAT) describes a single place where a 188 person might sit. Common examples include a seat in a theatre and 189 a cubicle in a cube farm. 191 Primary Road Name: The "primary road name" item (RD) is the name 192 given to the root road or street associated with the address. In 193 many cases this will the name of the road or street on which an 194 office or house exists, in some cases it will be the name of road 195 or street from which more granular information stems. In most 196 countries, this field should be used in preference to the "A6" 197 element, which was previously used for street information. 199 Road Section: The "road section" item (RDSEC) is an identifier that 200 represents a specific section or stretch of a primary road. This 201 is a new thoroughfare element and is useful where a primary road 202 reuses street numbering, or branch street names and there is no 203 other way to identify that this has occurred, such as a change in 204 municipality or suburb. 206 Branch Road Name: The "branch road name" item (RDBR) represents the 207 name or identifier of a road/street that intersects or is 208 associated with a primary road. The road branch is a new 209 thoroughfare element and is envisaged being used where branch 210 roads along a primary road reuse names and there is no other way, 211 other than the road section (RDSEC) identifier, to discern a 212 difference between them, such as a change in municipality or 213 suburb. 215 Sub-Branch Road Name: The "sub-branch road name" item (RDSUBBR) 216 represents the name or identifier of a road/street that intersects 217 or is associated with a branch road (RDBR). The road sub-branch 218 is a new thoroughfare element and is envisaged being used where 219 sub-branch roads reuse names and there is no way, other than the 220 road section (RDSEC) identifier, to discern a difference between 221 them, such as a change in municipality or suburb. 223 Road Pre-Modifier: The "road pre-modifier" item (PRM) is an optional 224 element of the complete street name. It is a word or phrase that 225 precedes all other elements of the street name and modifies it, 226 but is separated from the street name by a street name pre- 227 directional. An example is "Old" in "Old North First Street". 229 Road Post-Modifier: The "road post-modifier" item (POM) is an 230 optional element of the complete street name. It is a word or 231 phrase that follows all other elements of the street name and 232 modifies it, but is separated from the street name by a street 233 name post-directional and/or street suffix. An example is 234 "Extended" in "East End Avenue Extended". 236 3.2. New Thoroughfare Elements 238 In some countries a thoroughfare can be broken up into sections, and 239 it is not uncommon for street numbers to be repeated between 240 sections. A road section identifier is required to ensure that an 241 address is unique. For example, "West Alice Parade" has 5 sections, 242 each numbered from 1; unless the section is specified "7 West Alice 243 Parade" could exist in 5 different places. The "RDSEC" element is 244 used to specify the section. 246 Minor streets can share the same name, so that they can only be 247 distinguished by the major thoroughfare with which they intersect. 248 For example, both "West Alice Parade, Section 3" and "Bob Street" 249 could both be interested by a "Carol Lane". The "RDBR" element is 250 used to specify a road branch where the name of the branch does not 251 uniquely identify the road. Road branches MAY also be used where a 252 major thoroughfare is split into sections. 254 Similar to the way that a road branch is associated with a road, a 255 road sub-branch is associated with a road branch. The "RDSUBBR" 256 element is used to identify road sub-branches. 258 The "A6" element is retained for use in those countries that require 259 this level of detail. Where "A6" was previously used for street 260 names, it MUST NOT be used, the "RD" element MUST be used for 261 thoroughfare data. 263 The following example figure shows a fictional arrangement of roads 264 where these new thoroughfare elements are applicable. 266 | || 267 | ---------------|| 268 | Carol La. Carol La. || Bob 269 | || St. 270 | West Alice Pde. || 271 ==========/=================/===============/==========||=========== 272 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5 273 | || 274 ----------| Carol || 275 Alley 2 | La. || 276 | || 278 3.2.1. Street Numbering 280 The introduction of new thoroughfare elements affects the 281 interpretation of several of more specific civic address data. In 282 particular, street numbering (the "HNO" element) applies to the most 283 specific road element specified. That is, the first specified 284 element from: "RDSUBBR", "RDBR", "RDSEC", or "RD". 286 3.2.2. Directionals and other Qualifiers 288 The "PRM", "POM", "PRD", "POD" and "STS" elements always apply to the 289 value of the "RD" element only. If road branches or sub-branches 290 require street suffixes or qualifiers, they MUST be included in the 291 "RDBR" or "RDSUBBR" element text. 293 3.3. Country Element 295 The "country" element differs from that defined in [I-D.ietf-geopriv- 296 pidf-lo] in that it now restricts the value space of the element to 297 two upper case characters, which correspond to the alpha-2 codes in 298 [ISO.3166-1]. 300 3.4. A1 Element 302 The "A1" element is used for the top level subdivision within a 303 country. In the absence of a country-specific guide on how to use 304 the A-series of elements, the second part of the ISO 3166-2 code 305 [ISO.3166-2] for a country subdivision SHOULD be used. The ISO 306 3166-2 code is a formed of a country code and hyphen plus a code of 307 one, two or three characters or numerals. For the "A1" element, the 308 leading country code and hyphen are omitted and only the subdivision 309 code is included. 311 For example, the codes for Canada include CA-BC, CA-ON, CA-QC; 312 Luxembourg has just three single character codes: LU-D, LU-G and 313 LU-L; Australia uses both two and three character codes: AU-ACT, AU- 314 NSW, AU-NT; France uses numerical codes for mainland France and 315 letters for territories: FR-75, FR-NC. This results in the following 316 fragments: 318 CAON 320 LUL 322 AUACT 324 FR75 326 3.5. Languages and Scripts 328 The XML schema defined for civic addresses allows for the addition of 329 the "xml:lang" attribute to all elements except "country" and "PLC", 330 which both contain enumerated values. 332 The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is 333 omitted in favour of using the "xml:lang" attribute. 335 It is RECOMMENDED that each "civicAddress" element use one language 336 only, or a combination of languages that is consistent. Where a 337 civic location is represented in multiple languages multiple 338 "civicAddress" elements SHOULD be included in the PIDF-LO document. 340 3.6. Whitespace 342 The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 343 uses a base type of "token" instead of "string" as used in [I-D.ietf- 344 geopriv-pidf-lo]. 346 The "token" type ensures that whitespace within instance documents is 347 normalized and collapsed before being passed to a processor. This 348 ensures that the following fragments are considered equivalent by XML 349 processors: 351 North Wollongong 353 North 354 Wollongong 356 357 North Wollongong 358 360 Whitespace may still be included in values by using character 361 references, such as " ". 363 4. Civic Address Schema 365 366 373 376 377 378 379 380 382 383 384 385 386 387 388 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 425 426 427 428 430 5. Example 432 433 435 AU 436 NSW 437 Wollongong 438 North Wollongong 439 440 FlindersStreet 441 Campbell Street 442 443 Gilligan's Island 444 Corner 445 Video Rental Store 446 2500 447 Westerns and Classics 448 store 449 Private Box 15 450 452 6. Security Considerations 454 The XML representation described in this document is designed for 455 inclusion in a PIDF-LO document. As such, it is subject to the same 456 security considerations as are described in 457 [I-D.ietf-geopriv-pidf-lo]. Considerations relating to the inclusion 458 of this representation in other XML documents are outside the scope 459 of this document. 461 7. IANA Considerations 463 7.1. URN sub-namespace registration for 464 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' 466 This document calls for IANA to register a new XML namespace, as per 467 the guidelines in [RFC3688]. 469 URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 471 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 472 Martin Thomson (martin.thomson@andrew.com). 474 XML: 476 BEGIN 477 478 480 481 482 GEOPRIV Civic Address 483 484 485

Format for Distributing Civic Address in GEOPRIV

486

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

487 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 488 with the RFC number for this specification.]] 489

See RFCXXXX.

490 491 492 END 494 7.2. XML Schema Registration 496 This section registers an XML schema as per the procedures in 497 [RFC3688]. 499 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 501 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 502 Martin Thomson (martin.thomson@andrew.com). 504 The XML for this schema can be found as the entirety of Section 4 505 of this document. 507 8. References 509 8.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [W3C.REC-xmlschema-2-20041028] 515 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 516 Second Edition", W3C REC REC-xmlschema-2-20041028, 517 October 2004. 519 [I-D.ietf-geopriv-dhcp-civil] 520 Schulzrinne, H., "Dynamic Host Configuration Protocol 521 (DHCPv4 and DHCPv6) Option for Civic Addresses 522 Configuration Information", 523 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 524 January 2006. 526 [I-D.ietf-geopriv-location-types-registry] 527 Schulzrinne, H. and H. Tschofenig, "Location Types 528 Registry", draft-ietf-geopriv-location-types-registry-05 529 (work in progress), March 2006. 531 [ISO.3166-1] 532 International Organization for Standardization, "Codes for 533 the representation of names of countries and their 534 subdivisions - Part 1: Country codes", ISO Standard 3166- 535 1:1997, 1997, 536 . 538 [ISO.3166-2] 539 International Organization for Standardization, "Codes for 540 the representation of names of countries and their 541 subdivisions - Part 2: Country subdivision code", 542 ISO Standard 3166-2:1998, 1998, 543 . 545 8.2. Informative References 547 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 548 January 2004. 550 [I-D.ietf-geopriv-pidf-lo] 551 Peterson, J., "A Presence-based GEOPRIV Location Object 552 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), 553 September 2004. 555 [UPU-S42] Universal Postal Union (UPU), "International Postal 556 Address Components and Templates", UPS SB42-4, July 2004. 558 Appendix A. Acknowledgements 560 The authors would like to thank Henning Schulzrinne for his 561 assistance in defining the additional civic address types, 562 particularly his research into different addressing schemes that lead 563 to the introduction of the thoroughfare elements. Rohan Mahy 564 suggested the ISO 3166-2 recommendation for A1. In addition we would 565 like to thank Jon Peterson for his work in defining the PIDF-LO. 567 Authors' Addresses 569 Martin Thomson 570 Andrew 571 PO Box U40 572 Wollongong University Campus, NSW 2500 573 AU 575 Phone: +61 2 4221 2915 576 Email: martin.thomson@andrew.com 577 URI: http://www.andrew.com/ 579 James Winterbottom 580 Andrew 581 PO Box U40 582 Wollongong University Campus, NSW 2500 583 AU 585 Phone: +61 2 4221 2938 586 Email: james.winterbottom@andrew.com 587 URI: http://www.andrew.com/ 589 Intellectual Property Statement 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Disclaimer of Validity 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 618 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 619 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 620 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Copyright Statement 625 Copyright (C) The Internet Society (2006). This document is subject 626 to the rights, licenses and restrictions contained in BCP 78, and 627 except as set forth therein, the authors retain all their rights. 629 Acknowledgment 631 Funding for the RFC Editor function is currently provided by the 632 Internet Society.