idnits 2.17.1 draft-thomson-revised-civic-lo-01.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 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 401. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '... It is RECOMMENDED that each "civicA...' RFC 2119 keyword, line 175: '...ddress" elements SHOULD be included in...' 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 (October 3, 2005) is 6772 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: '17' on line 142 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-dhcp-civil-07 Summary: 4 errors (**), 0 flaws (~~), 3 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 Expires: April 6, 2006 Andrew 5 October 3, 2005 7 Revised Civic Location Format for PIDF-LO 8 draft-thomson-revised-civic-lo-01.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 April 6, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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. The format also includes support for 46 the xml:lang language tag and restricts the types of elements where 47 appropriate. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Additional Civic Address Types . . . . . . . . . . . . . . 4 54 2.2. Country Element . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. Languages and Scripts . . . . . . . . . . . . . . . . . . 5 56 2.4. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 7 58 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 6.1. URN sub-namespace registration for 62 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 11 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . . . 15 70 1. Introduction 72 Since the publication of the original PIDF-LO civic specification, in 73 [I-D.ietf-geopriv-pidf-lo], it has been found that the specification 74 is lacking a number of additional parameters that can be used to more 75 precisely specify a civic location. These additional parameters have 76 been suitably captured in [I-D.ietf-geopriv-dhcp-civil]. 78 This document revises the GEOPRIV civic form to include the 79 additional civic parameters captured in [I-D.ietf-geopriv-dhcp- 80 civil]. New elements are also defined to allow for even more 81 precision in specifying location information. 83 2. Changes from PIDF-LO 85 2.1. Additional Civic Address Types 87 [I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that 88 may used to describe a civic location. Specifically [I-D.ietf- 89 geopriv-dhcp-civil] lists 6 civic address types (CAtypes) that 90 require support in the formal PIDF-LO definition that are not in 91 [I-D.ietf-geopriv-pidf-lo]. Two additional types are also added that 92 enable a more complete specification of location. These are listed 93 in the table below for completeness. 95 +--------------+--------+-----------------------------+-------------+ 96 | New Civic | CAtype | Description | Example | 97 | Field | | | | 98 +--------------+--------+-----------------------------+-------------+ 99 | BLD | 24 | Building (structure) | Hope | 100 | | | | Theatre | 101 | | | | | 102 | UNIT | 26 | Unit (apartment, suite) | 12a | 103 | | | | | 104 | ROOM | 28 | Room | 450F | 105 | | | | | 106 | SEAT | 33 | Seat (desk, cubicle, | WS 181 | 107 | | | workstation) | | 108 | | | | | 109 | PLC | 29 | Placetype | office | 110 | | | | | 111 | POBOX | 31 | Post office box (P.O. box) | U40 | 112 | | | | | 113 | ADDCODE | 32 | Additional Code | 13203000003 | 114 +--------------+--------+-----------------------------+-------------+ 116 Table 1: New Civic PIDF-LO Types 118 Building: The "building" (BLD) conveys the name of a single building 119 if the street address includes more than one building or the 120 building name is helpful in identifying the location. (For 121 example, on university campuses, the house number is often not 122 displayed on buildings, while the building name is prominently 123 shown.) 125 Unit: The "unit" (UNIT) contains the name or number of a part of a 126 structure where there are separate administrative units, owners or 127 tenants, such as separate companies or families who occupy that 128 structure. Common examples include suite or apartment 129 designations. 131 Room: A "room" (ROOM) is the smallest identifiable subdivision of a 132 structure. 134 Seat: The "seat" element (SEAT) describes a single place where a 135 person might sit. Common examples include a seat in a theatre and 136 a cubicle in a cube farm. 138 Place type: The "type of place" element (PLC) describes the type of 139 place described by the civic coordinates. For example, it 140 describes whether it is a home, office, street or other public 141 space. The values are drawn from the items in the rich presence 142 [17] document. This information makes it easy, for example, for 143 the DHCP client to then populate the presence information. 145 Post office box: The "post office box" element (POBOX) describes a 146 container, such as a pigeon hole, at a central mailing location, 147 where mail is held. 149 Additional code: The "additional code" item (ADDCODE) provides an 150 additional, country-specific code identifying the location. For 151 example, for Japan, it contains the Japan Industry Standard (JIS) 152 address code. The JIS address code provides a unique address 153 inside of Japan, down to the level of indicating the floor of the 154 building. 156 2.2. Country Element 158 The "country" element differs from that defined in [I-D.ietf-geopriv- 159 pidf-lo] in that it now restricts the value space of the element to 160 two upper case characters, which more closely matches the definition 161 in [ISO.3166.1988]. 163 2.3. Languages and Scripts 165 The XML schema defined for civic addresses allows for the addition of 166 the "xml:lang" attribute to all elements except "country" and "PLC", 167 which both contain enumerated values. 169 The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is 170 omitted in favour of using the "xml:lang" attribute. 172 It is RECOMMENDED that each "civicAddress" element use one language 173 only, or a combination of languages that is consistent. Where a 174 civic location is represented in multiple languages multiple 175 "civicAddress" elements SHOULD be included in the PIDF-LO document. 177 2.4. Whitespace 179 The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 3 180 uses a base type of "token" instead of "string" as used in [I-D.ietf- 181 geopriv-pidf-lo]. 183 The "token" type ensures that whitespace within instance documents is 184 normalized and collapsed before being passed to a processor. This 185 ensures that the following fragments are considered equivalent by XML 186 processors: 188 New South Wales 190 New 191 South Wales 193 194 New South 195 Wales 197 Whitespace may still be included in values by using a character 198 reference, such as " ". 200 3. Civic Address Schema 202 203 210 213 214 215 216 217 219 220 221 222 223 224 225 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 256 257 258 259 261 4. Example 263 264 266 DE 267 Bayern Oberbayern 268 269 München 270 271 Marienplatz 8 272 Rathaus 273 80331 274 public 275 Postfach 1000 276 278 5. Security Considerations 280 The XML representation described in this document is designed for 281 inclusion in a PIDF-LO document. As such, it is subject to the same 282 security considerations as are described in 283 [I-D.ietf-geopriv-pidf-lo]. Considerations relating to the inclusion 284 of this representation in other XML documents are outside the scope 285 of this document. 287 6. IANA Considerations 289 This document calls for IANA to register a new XML namespace, as per 290 the guidelines in [RFC3688]. 292 6.1. URN sub-namespace registration for 293 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' 295 URI 296 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr 298 Registrant Contact 299 IETF, GEOPRIV working group 300 Martin Thomson 302 XML 303 BEGIN 304 305 307 308 309 GEOPRIV Civic Address 310 311 312

Format for Distributing Civic Address in GEOPRIV

313

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

314

See RFCXXXX.

315 316 317 END 319 7. References 321 7.1. Normative References 323 [W3C.REC-xmlschema-2-20041028] 324 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 325 Second Edition", W3C REC REC-xmlschema-2-20041028, 326 October 2004. 328 [I-D.ietf-geopriv-dhcp-civil] 329 Schulzrinne, H., "Dynamic Host Configuration Protocol 330 (DHCPv4 and DHCPv6) Option for Civic Addresses 331 Configuration Information", 332 draft-ietf-geopriv-dhcp-civil-07 (work in progress), 333 September 2005. 335 [ISO.3166.1988] 336 International Organization for Standardization, "Codes for 337 the representation of names of countries, 3rd edition", 338 ISO Standard 3166, August 1988. 340 7.2. Informative References 342 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 343 January 2004. 345 [I-D.ietf-geopriv-pidf-lo] 346 Peterson, J., "A Presence-based GEOPRIV Location Object 347 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), 348 September 2004. 350 Appendix A. Acknowledgements 352 The authors would like to thank Henning Schulzrinne for his research 353 and work on defining the additional civic address types. In addition 354 we would like to thank Jon Peterson for his work in defining the 355 PIDF-LO. 357 Authors' Addresses 359 Martin Thomson 360 Andrew 361 PO Box U40 362 Wollongong University Campus, NSW 2500 363 AU 365 Phone: +61 2 4221 2915 366 Email: martin.thomson@andrew.com 367 URI: http://www.andrew.com/ 369 James Winterbottom 370 Andrew 371 PO Box U40 372 Wollongong University Campus, NSW 2500 373 AU 375 Phone: +61 2 4221 2938 376 Email: james.winterbottom@andrew.com 377 URI: http://www.andrew.com/ 379 Intellectual Property Statement 381 The IETF takes no position regarding the validity or scope of any 382 Intellectual Property Rights or other rights that might be claimed to 383 pertain to the implementation or use of the technology described in 384 this document or the extent to which any license under such rights 385 might or might not be available; nor does it represent that it has 386 made any independent effort to identify any such rights. Information 387 on the procedures with respect to rights in RFC documents can be 388 found in BCP 78 and BCP 79. 390 Copies of IPR disclosures made to the IETF Secretariat and any 391 assurances of licenses to be made available, or the result of an 392 attempt made to obtain a general license or permission for the use of 393 such proprietary rights by implementers or users of this 394 specification can be obtained from the IETF on-line IPR repository at 395 http://www.ietf.org/ipr. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights that may cover technology that may be required to implement 400 this standard. Please address the information to the IETF at 401 ietf-ipr@ietf.org. 403 Disclaimer of Validity 405 This document and the information contained herein are provided on an 406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 408 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 409 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 410 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 Copyright Statement 415 Copyright (C) The Internet Society (2005). This document is subject 416 to the rights, licenses and restrictions contained in BCP 78, and 417 except as set forth therein, the authors retain all their rights. 419 Acknowledgment 421 Funding for the RFC Editor function is currently provided by the 422 Internet Society.