idnits 2.17.1 draft-ietf-geopriv-dhcp-civil-09.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 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 16, 2006) is 6646 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: 'Country' on line 720 == Unused Reference: '9' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 756, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 765, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3066 (ref. '4') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3315 (ref. '6') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 3694 (ref. '12') == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-location-types-registry-03 -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '17') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '18') (Obsoleted by RFC 6225) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: July 20, 2006 January 16, 2006 6 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic 7 Addresses Configuration Information 8 draft-ietf-geopriv-dhcp-civil-09 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 July 20, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document specifies a Dynamic Host Configuration Protocol (DHCPv4 42 and DHCPv6) option containing the civic location of the client or the 43 DHCP server. The Location Configuration Information (LCI) includes 44 information about the country, administrative units such as states, 45 provinces and cities, as well as street addresses, postal community 46 names and building information. The option allows multiple 47 renditions of the same address in different scripts and languages. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Format of the DHCP Civic Location Option . . . . . . . . . . . 7 54 3.1 Overall Format for DHCPv4 . . . . . . . . . . . . . . . . 7 55 3.2 Overall Format for DHCPv6 . . . . . . . . . . . . . . . . 7 56 3.3 Element Format . . . . . . . . . . . . . . . . . . . . . . 8 57 3.4 Civic Address Components . . . . . . . . . . . . . . . . . 8 58 4. Postal Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 59 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 64 8.2 Informative References . . . . . . . . . . . . . . . . . . 21 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 66 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 67 Intellectual Property and Copyright Statements . . . . . . . . 23 69 1. Terminology 71 In this document, the key words "MUST", "MUSTNOT", "REQUIRED", 72 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 73 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 74 indicate requirement levels for compliant implementations. 76 2. Introduction 78 Many end system services can benefit by knowing the approximate 79 location of the end device. In particular, IP telephony devices need 80 to know their location to contact the appropriate emergency response 81 agency and to be found by emergency responders. 83 There are two common ways to identify the location of an object, 84 either through geospatial coordinates or by so-called civic 85 addresses. Geospatial coordinates indicate longitude, latitude and 86 altitude, while civic addresses indicate a street address. 88 The civic address is commonly, but not necessarily, closely related 89 to the postal address, used by the local postal service to deliver 90 mail. However, not all postal addresses correspond to street 91 addresses. For example, the author's address is a postal address 92 that does not appear on any street or building sign. Naturally, post 93 office boxes would be unsuitable for the purposes described here. 94 The term 'civil address' or 'jurisdictional address' is also 95 sometimes used instead of civic address. This document mainly 96 supports civic addresses, but allows to indicate the postal community 97 name if it differs from the civic name. 99 A related document [18] describes a DHCPv4 [2] option for conveying 100 geospatial information to a device. This draft describes how DHCPv4 101 and DHCPv6 [6] can be used to convey the civic and postal address to 102 devices. Both geospatial and civic formats be used simultaneously, 103 increasing the chance to deliver accurate and timely location 104 information to emergency responders. 106 This document only defines the delivery of location information from 107 the DHCP server to the client, due to security concerns related to 108 using DHCP to update the database. Within the GEOPRIV architecture 109 as defined by RFC 3693 [11], the defined mechanism in this document 110 for conveying initial location information is known as a "sighting" 111 function. Sighting functions are not required to have security 112 capabilities and are only intended to be configured in trusted and 113 controlled environments. (A classic example of the sighting function 114 is a Global Positioning System wired directly to a network node.) 115 After initial location information has been introduced, it MUST be 116 afforded the protections defined in RFC 3694 [12]. Therefore, 117 location information SHOULD NOT be sent from a DHCP client to a DHCP 118 server. If a client decides to send location information to the 119 server, it is implicitly granting that server unlimited retention and 120 distribution permissions. 122 End systems that obtain location information via the mechanism 123 described here then use other protocol mechanisms to communicate this 124 information to an emergency call center or to convey it as part of 125 presence information. 127 Civic information is useful since it often provides additional, 128 human-usable information particularly within buildings. Also, 129 compared to geospatial information, it is readily obtained for most 130 occupied structures and can often be interpreted even if incomplete. 131 For example, for many large university or corporate campuses, 132 geocoding information to building and room granularity may not be 133 readily available. 135 Unlike geospatial information, the format for civic and postal 136 information differs from country to country. The initial set of data 137 fields is derived from standards published by the United States 138 National Emergency Number Association (NENA) [21] and takes into 139 account addressing conventions for a number of countries in different 140 areas of the world. It is anticipated that other countries can reuse 141 many of the data elements, but the draft also establishes an IANA 142 registry for defining additional civic location data fields. 144 The same civic and postal address information can often be rendered 145 in multiple languages and scripts. For example, Korean addresses are 146 often shown in Hangul, Latin and Kanji, while some older cities have 147 multiple language variants (Munich, Muenchen and Monaco, for 148 example). Since DHCPv4 and DHCPv6 do not currently support a 149 mechanism to query for a specific script or language, the DHCP server 150 SHOULD provide all common renderings to the client and MUST provide 151 at least the rendering in the language and script appropriate to the 152 location indicated. For example, for use in presence information, 153 the target may be visiting from a foreign country and want to convey 154 the information in a format suitable for watchers in its home 155 country. For emergency services, the rendering in the local language 156 is likely to be most appropriate. To provide multiple renderings, 157 the server repeats sequences of address elements, prefixing each with 158 'language' and/or 'script' element (see Section 3.3). The language 159 and script remain in effect for subsequent elements until overridden 160 by another language or script element. Since the DHCP client is 161 unlikely to be the final consumer of the location information, the 162 DHCP server has to provide all appropriate language and script 163 versions, which the client then passes on via some other GEOPRIV 164 using protocol, typically encoded in a presence-based GEOPRIV 165 location object format [19]. 167 The DHCP server MAY provide location information for multiple 168 locations related to the target, for example, both the network 169 element and the network jack itself. This is likely to help in 170 debugging network problems, for example. 172 This document calls for various operational decisions. For example, 173 an administrator has to decide when to provide the location of the 174 DHCP server or other network elements even if these may be a good 175 distance away from the client. The administrator must also consider 176 whether to include both civic and geospatial information if these may 177 differ. The document does not specify the criteria to be used in 178 making these choices, as these choices are likely to depend strongly 179 on local circumstances and need to be based on local, human 180 knowledge. 182 If a network provides civic location information via both DHCPv4 and 183 DHCPv6, the information conveyed by two protocols MUST be the same. 185 As discussed in Security Considerations (Section 6), the 186 GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when 187 the DHCPv4 client has included this option in its 'parameter request 188 list' (RFC 2131 [2], Section 3.5). Similarly, the 189 OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only 190 when the DHCPv6 client has included this option in its OPTION_ORO. 192 The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be 193 used if the civic address option exceeds the maximum DHCPv4 option 194 size of 255 octets. 196 3. Format of the DHCP Civic Location Option 198 3.1 Overall Format for DHCPv4 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | GEOCONF_CIVIC | N | what | country | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | code | civic address elements ... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Code GEOCONF_CIVIC: The code for this DHCP option is TBD by IANA. 210 N: The length of this option is variable. The minimum length is 3. 212 what: The 'what' element describes which location the DHCP entry 213 refers to. Currently, three options are defined: the location of 214 the DHCP server (a value of 0), the location of the network 215 element believed to be closest to the client (a value of 1) or the 216 location of the client (a value of 2). Option (2) SHOULD be used, 217 but may not be known. Options (0) and (1) SHOULD NOT be used 218 unless it is known that the DHCP client is in close physical 219 proximity to the server or network element. 221 country code: The two-letter ISO 3166 country code in capital ASCII 222 letters, e.g., DE or US. (Civic addresses always contain country 223 designations, suggesting the use of a fixed-format field to save 224 space.) 226 civic address elements: Zero or more elements comprising the civic 227 and/or postal address, with the format described below 228 (Section 3.3). 230 3.2 Overall Format for DHCPv6 232 The DHCPv6 [6] civic address option refers generally to the client as 233 a whole. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | OPTION_GEOCONF_CIVIC | option-len | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | what | country code | . 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 242 . civic address elements . 243 . ... . 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 option-code: OPTION_GEOCONF_CIVIC (TBD) 248 option-len: Length of the Countrycode, 'what' and civic address 249 elements. 251 what: See above (Section 3.1). 253 country code: See above (Section 3.1). 255 civic address elements: See above (Section 3.1). 257 3.3 Element Format 259 For both DHCPv4 and DHCPv6, each civic address element has the 260 following format: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | CAtype | CAlength | CAvalue ... 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 CAtype: A one-octet descriptor of the data civic address value. 270 CAlength: The length, in octets, of the CAvalue, not including the 271 CAlength field itself. 273 CAvalue: The civic address value, as described in detail below. 275 3.4 Civic Address Components 277 Since each country has different administrative hierarchies, with 278 often the same (English) names, this specification adopts a simple 279 hierarchical notation that is then instantiated for each country. We 280 assume that five levels are sufficient for sub-national divisions 281 above the street level. 283 All elements are OPTIONAL and can appear in any order. 285 Component values MUST be encoded as UTF-8 [7]. They SHOULD be 286 written in mixed case, following the customary spelling. The script 287 indication (CAtype=128) MUST be written in mixed-case, with the first 288 letter a capital letter. 290 Abbreviations MUST NOT be used unless indicated for each element. 291 Abbreviations do not need a trailing period. 293 It is RECOMMENDED that all elements in a particular script (CAtype 294 128) and language (CAtype 0) be grouped together as that reduces the 295 number of script and language identifiers needed. 297 For each script and language, elements SHOULD be included in numeric 298 order from lowest to highest of their CAtype. In general, an element 299 is labeled in its language and script by the most recent 'language 300 tag' (CAtype = 0) element preceding it. Since not all elements 301 depend on the script and language, a client accumulates the elements 302 by CAtype and then selects the most desirable language and script 303 rendition if there are multiple elements for the same CAtype. 305 +----------------------+----------------------+---------------------+ 306 | CAtype | label | description | 307 +----------------------+----------------------+---------------------+ 308 | 1 | A1 | national | 309 | | | subdivisions | 310 | | | (state, canton, | 311 | | | region, province, | 312 | | | prefecture) | 313 | | | | 314 | 2 | A2 | county, parish, gun | 315 | | | (JP), district (IN) | 316 | | | | 317 | 3 | A3 | city, township, shi | 318 | | | (JP) | 319 | | | | 320 | 4 | A4 | city division, | 321 | | | borough, city | 322 | | | district, ward, | 323 | | | chou (JP) | 324 | | | | 325 | 5 | A5 | neighborhood, block | 326 | | | | 327 | 6 | A6 | group of streets | 328 | | | below the | 329 | | | neighborhood level | 330 +----------------------+----------------------+---------------------+ 332 Table 1 334 For specific countries, the administrative sub-divisions are 335 described below. 337 CA (Canada): The mapping to NENA designations is shown in 338 parentheses. A1 designates the province (STA), A2 the county 339 (CNA), A3 the city or town (MCN). 341 DE (Germany): A1 represents the state (Bundesstaat), A2 the county 342 (Regierungsbezirk), A3 the city (Stadt, Gemeinde), A4 the district 343 (Bezirk). Street suffixes (STS) are used only for designations 344 that are a separate word (e.g., Marienthaler Strasse). 346 JP (Japan): A1 repreents the metropolis (To, Fu) or prefecture (Ken, 347 Do), A2 the city (Shi) or rural area (Gun), A3 the ward (Ku) or 348 village (Mura), A4 the town (Chou or Machi), A5 the city district 349 (Choume) and A6 the block (Banchi or Ban). 351 KR (Korea): A1 represents the province (Do), A2 the county (gun), A3 352 the city or village (ri), A4 the urban district (gu), A5 a 353 neighborhood (dong). 355 US (United States): The mapping to NENA designations is shown in 356 parentheses. A1 designates the state (STA), using the the two- 357 letter state and possession abbreviations recommended by the 358 United States Postal Service Publication 28 [20], Appendix B. A2 359 designates the county, parish (Louisiana) or borough (Alaska) 360 (CNA). A3 designates the civic community name, e.g., city or 361 town. It is also known as the municipal jurisdiction. (MCN) The 362 optional element A4 contains the community place name, such as 363 "New bope Community" or "Urbanizacion" in Puerto Rico. The civic 364 community name (MCN) reflects the political boundaries. These 365 boundaries may differ from postal delivery assignments, the postal 366 community name (PCN), for historical or practical reasons. 368 Mappings and considerations for additional countries should be 369 written up in documents titled "Civic Addresses for [Country] (XY)", 370 where "XY" represents the two-letter country code, e.g., "Civic 371 Address Considerations for France (FR)". 373 Additional CA types appear in many countries and are simply omitted 374 where they are not needed or known: 376 +------------+------------+-------------+-------------+-------------+ 377 | CAtype | NENA | PIDF | Description | Examples | 378 +------------+------------+-------------+-------------+-------------+ 379 | 0 | | | language | i-default | 380 | | | | | [3] | 381 | | | | | | 382 | 16 | PRD | PRD | leading | N | 383 | | | | street | | 384 | | | | direction | | 385 | | | | | | 386 | 17 | POD | POD | trailing | SW | 387 | | | | street | | 388 | | | | suffix | | 389 | | | | | | 390 | 18 | STS | STS | street | Ave, Platz | 391 | | | | suffix or | | 392 | | | | type | | 393 | | | | | | 394 | 19 | HNO | HNO | house | 123 | 395 | | | | number | | 396 | | | | | | 397 | 20 | HNS | HNS | house | A, 1/2 | 398 | | | | number | | 399 | | | | suffix | | 400 | | | | | | 401 | 21 | LMK | LMK | landmark or | Columbia | 402 | | | | vanity | University | 403 | | | | address | | 404 | | | | | | 405 | 22 | LOC | LOC | additional | South Wing | 406 | | | | location | | 407 | | | | information | | 408 | | | | | | 409 | 23 | NAM | NAM | name | Joe's | 410 | | | | (residence | Barbershop | 411 | | | | and office | | 412 | | | | occupant) | | 413 | | | | | | 414 | 24 | ZIP | PC | postal/zip | 10027-1234 | 415 | | | | code | | 416 | | | | | | 417 | 25 | | | building | Low Library | 418 | | | | (structure) | | 419 | | | | | | 420 | 26 | | | unit | Apt 42 | 421 | | | | (apartment, | | 422 | | | | suite) | | 423 | | | | | | 424 | 27 | | FLR | floor | 4 | 425 | | | | | | 426 | 28 | | | room number | 450F | 427 | | | | | | 428 | 29 | | | placetype | office | 429 | | | | | | 430 | 30 | PCN | | postal | Leonia | 431 | | | | community | | 432 | | | | name | | 433 | | | | | | 434 | 31 | | | post office | 12345 | 435 | | | | box (P.O. | | 436 | | | | Box) | | 437 | | | | | | 438 | 32 | | | additional | 13203000003 | 439 | | | | code | | 440 | | | | | | 441 | 33 | | SEAT | seat (desk, | WS 181 | 442 | | | | cubicle, | | 443 | | | | workstation | | 444 | | | | ) | | 445 | | | | | | 446 | 34 | | | Primary | Broadway | 447 | | | | road or | | 448 | | | | street | | 449 | | | | | | 450 | 35 | | | Road | 14 | 451 | | | | section | | 452 | | | | | | 453 | 36 | | | Road branch | Lane 7 | 454 | | | | | | 455 | 37 | | | Road | Alley 8 | 456 | | | | sub-branch | | 457 | | | | | | 458 | 38 | | | Street name | Old | 459 | | | | pre-modifie | | 460 | | | | r | | 461 | | | | | | 462 | 39 | | | Street name | Service | 463 | | | | post-modifi | | 464 | | | | er | | 465 | | | | | | 466 | 128 | | | script | Latn | 467 | | | | | | 468 | 255 | | | reserved | | 469 +------------+------------+-------------+-------------+-------------+ 471 The CA types labeled in the second column correspond to items from 472 the NENA "Recommended Formats & Protocols For ALI Data Exchange, ALI 473 Response & GIS Mapping" [21], but are applicable to most countries. 474 The "NENA" column refers to the data dictionary name in Exhibit 18 of 475 [21]. 477 The column labeled PIDF indicates the element name from [19]. (Some 478 elements were added to this document after the PIDF location object 479 definition had been completed. These elements currently do not have 480 a PIDF-LO equivalent.) 482 Language: The "language" item (CAtype 0) optionally identifies the 483 language used for presenting the address information, drawing from 484 the tags for identifying languages in [4], as discussed in [16]. 485 If omitted, the default value for this tag is "i-default" [3]. 487 Script: The "script" item (CAtype 128) optionally identifies the 488 script used for presenting the address information, drawing from 489 the tags for identifying scripts described in [15] and elaborated 490 on in Section 2.2.3 of [16]. If omitted, the default value for 491 this tag is "Latn". 493 POD, PRD: The abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be 494 used for POD (trailing street suffix) and PRD (leading street 495 direction) in English-speaking countries. 497 STS: STS designates a street suffix or type. In the United States 498 (US), the abbreviations recommended by the United States Postal 499 Service Publication 28 [20], Appendix C, SHOULD be used. 501 HNS: HNS ("house number") is a modifier to a street address; it does 502 not identify parts of a street address. 504 LMK: LMK ("landmark", CAtype 21) is a string name for a location. It 505 conveys the same information as the street address, but reflects 506 common local designation of a structure, a group of buildings or a 507 place that helps recipients locate the place. For example, an 508 industrial park may have a widely-recognized name that is more 509 readily found than a single street address. Some places, such as 510 parks, may not have street names or house numbers and SHOULD be 511 identified by a LMK string. In addition, this component can be 512 used to indicate where postal delivery locations differ from the 513 jurisdictional one. 515 LOC: LOC ("location", CAtype 22) is an unstructured string specifying 516 additional information about the location, such as the part of a 517 building or other unstructured information. 519 PCN: The postal community name (CAtype 30) and the post office box 520 (CAtype 31) allow the recipient to construct a postal address. 521 The post office box field should contain the words "P.O. Box" or 522 other locally appropriate postal designation. 524 NAM: The NAM object is used to aid user location ("Joe Miller", 525 "Alice's Dry Cleaning"). It does not identify the person using a 526 communications device, but rather the person or organization 527 associated with the address. 529 LMK: While a landmark (LMK, CAtype 21) can indicate a complex of 530 buildings, 'building' (CAtype 25) conveys the name of a single 531 building if the street address includes more than one building or 532 the building name is helpful in identifying the location. (For 533 example, on university campuses, the house number is often not 534 displayed on buildings, while the building name is prominently 535 shown.) 537 Unit: The 'unit' object (CAtype 26) contains the name or number of a 538 part of a structure where there are separate administrative units, 539 owners or tenants, such as separate companies or families who 540 occupy that structure. Common examples include suite or apartment 541 designations. 543 Room: A 'room' (CAtype 28) is the smallest identifiable subdivision 544 of a structure. 546 Type of place: The "type of place" item (CAtype 29) describes the 547 type of place described by the civic coordinates. For example, it 548 describes whether it is a home, office, street or other public 549 space. The values are drawn from the items in the location types 550 registry [14]. This information makes it easy, for example, for 551 the DHCP client to then populate the presence information. Since 552 this is an IANA-registered token, the language and script 553 designations do not apply for this element. 555 Additional code: The "additional code" item (CAtype 32) provides an 556 additional, country-specific code identifying the location. For 557 example, for Japan, it contains the Japan Industry Standard (JIS) 558 address code. The JIS address code provides a unique address 559 inside of Japan, down to the level of indicating the floor of the 560 building. 562 SEAT: The "seat" item (CAtype 33) designates a place where a person 563 might sit, such as a seat in a stadium or theater, or a cubicle in 564 an open-plan office or a booth in a trade-show. 566 Primary road: The "primary road" item (CAtype 34) given to the road 567 or street name associated with the address. If CAtypes 35 through 568 37 are not specified, the building or designated location is found 569 on that street. If some of CAtypes 35 through 37 are specified, 570 this designates the main road, off of which the smaller streets 571 branch off and where the structure or building is actually 572 located. 574 Road section: The "road section" item (CAtype 35) designates a 575 specific section or stretch of a primary road. This is a new 576 thoroughfare element and is useful where a primary road is divided 577 into sections that re-use the same street number ranges. 579 Branch Road Name: The "branch road name" item (CAtype 36) represents 580 the name or identifier of a road or street that intersects or is 581 associated with a primary road. The branch road name is only used 582 in countries where side streets do not have unique names within a 583 municipality or other administrative unit, but rather must be 584 qualified by the name of the primary road name that they branch 585 off of. 587 Sub-Branch Road Name: The "sub-branch road name" (CAtype 37) item 588 represents the name of a street that branches off a branch road 589 (CAtype 36). The sub-branch road name is only used in countries 590 where such streets are named relative to the primary road name and 591 branch road that they connect with. 593 Street Name Pre-Modifier: The "street name pre-modifier" (CAtype 38) 594 is an optional element of the complete street name. It is a word 595 or phrase that precedes all other elements of the street name and 596 modifies it, but is separated from the street name by a street 597 name pre-directional. An example is "Old" in "Old North First 598 Street". 600 Street Name Post-Modifier: The "street name post-modifier" (CAtype 601 39) is an optional element of the complete street name. It is a 602 word or phrase that follows all other elements of the street name 603 and modifies it, but is separated from the street name by a street 604 name post-directional and/or street suffix. An example is 605 "Extended" in "East End Avenue Extended". 607 4. Postal Addresses 609 In general, a recipient can construct a postal address by using all 610 language-appropriate elements, including the postal code (ZIP, CAtype 611 24). However, certain elements override the civic address components 612 to create a postal address. If the elments include a post office box 613 (CAtype 31), the street address components (CAtype 34, PRD, POD, STS, 614 HNO, HNS) are replaced with the post office box element. If a postal 615 community name is specified, the civic community name (typically, A3) 616 is replaced by the postal community name (PCN, CAtype 30). Country- 617 specific knowledge is required to create a valid postal address. The 618 formating of such addresses is beyond the scope of this document. 620 5. Example 622 Rather than showing the precise byte layout of a DHCP option, we show 623 a symbolic example below, representing the civic address of the 624 Munich city hall in Bavaria, Germany. The city and state name are 625 also conveyed in English and Italian in addition to German; the other 626 items are assumed to be common across all languages. All languages 627 use the latin script. 629 +--------+---------------------+ 630 | CAtype | CAvalue | 631 +--------+---------------------+ 632 | 0 | de | 633 | | | 634 | 128 | Latn | 635 | | | 636 | 1 | Bayern | 637 | | | 638 | 2 | Oberbayern | 639 | | | 640 | 3 | M=U+00FCnchen | 641 | | | 642 | 6 | Marienplatz | 643 | | | 644 | 19 | 8 | 645 | | | 646 | 21 | Rathaus | 647 | | | 648 | 24 | 80331 | 649 | | | 650 | 29 | government-building | 651 | | | 652 | 31 | Postfach 1000 | 653 | | | 654 | 0 | en | 655 | | | 656 | 1 | Bavaria | 657 | | | 658 | 3 | Munich | 659 | | | 660 | 0 | it | 661 | | | 662 | 1 | Baviera | 663 | | | 664 | 3 | Monaco | 665 +--------+---------------------+ 667 6. Security Considerations 669 The security considerations discussed in the GEOPRIV architecture 670 defined by RFC 3693 [11] apply. 672 Where critical decisions might be based on the value of this 673 GEOCONF_CIVIC option, DHCPv4 authentication in RFC3118 [5] SHOULD be 674 used to protect the integrity of the DHCP options. 676 Since there is no privacy protection for DHCP messages, an 677 eavesdropper who can monitor the link between the DHCP server and 678 requesting client can discover the information contained in this 679 option. Thus, usage of this option on networks without access 680 restrictions or network-layer or link-layer privacy mechanisms is NOT 681 RECOMMENDED. 683 To minimize the unintended exposure of location information, the 684 GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when 685 the DHCPv4 client has included this option in its 'parameter request 686 list' (RFC 2131 [2], Section 3.5). Similarly, the 687 OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only 688 when the DHCPv6 client has included this option in its OPTION_ORO. 690 7. IANA Considerations 692 This document requests that IANA register a new DHCPv4 and DHCPv6 693 option code for the Civic Address (GEOCONF_CIVIC and 694 OPTION_GEOCONF_CIVIC, respectively). 696 This document establishes a new IANA registry for CAtypes designating 697 civic address components. According to RFC 2434 [17], this registry 698 operates under the "Specification Required" rules. The IANA 699 registration needs to include the following information: 701 CAtype: Numeric identifier, assigned by IANA. 703 Brief description: Short description identifying the meaning of the 704 element. 706 Reference to published specification: A stable reference to an RFC or 707 other permanent and readily available reference, in sufficient 708 detail so that interoperability between independent 709 implementations is possible. 711 Country-specific considerations: If applicable, notes whether the 712 element is only applicable or defined for certain countries. 714 The initial list of registrations is contained in Section 3.4. 716 Updates to country-specific considerations for previously-defined 717 CAtypes are not defined by IANA registrations since they are 718 descriptive, not a registration of identifiers. As noted earlier, 719 country-specific conventions are instead written up in documents 720 titled "Civic Addresses for [Country] (XY)". 722 8. References 724 8.1 Normative References 726 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 727 Levels", BCP 14, RFC 2119, March 1997. 729 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 730 March 1997. 732 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 733 BCP 18, RFC 2277, January 1998. 735 [4] Alvestrand, H., "Tags for the Identification of Languages", 736 BCP 47, RFC 3066, January 2001. 738 [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 739 RFC 3118, June 2001. 741 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 742 Carney, "Dynamic Host Configuration Protocol for IPv6 743 (DHCPv6)", RFC 3315, July 2003. 745 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 746 STD 63, RFC 3629, November 2003. 748 [8] Lemon, T. and S. Cheshire, "Encoding Long Options in the 749 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 750 November 2002. 752 [9] Droms, R., "DNS Configuration options for Dynamic Host 753 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 754 December 2003. 756 [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 757 January 2004. 759 [11] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 760 Polk, "Geopriv Requirements", RFC 3693, February 2004. 762 [12] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 763 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 765 [13] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 766 J. Peterson, "Presence Information Data Format (PIDF)", 767 RFC 3863, August 2004. 769 [14] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", 770 draft-ietf-geopriv-location-types-registry-03 (work in 771 progress), August 2005. 773 [15] International Organization for Standardization, ISO., "ISO 774 15924:2004. Information and documentation - Codes for the 775 representation of names of scripts", January 2004. 777 8.2 Informative References 779 [16] Phillips, A. and M. Davis, "Tags for Identifying Languages", 780 draft-ietf-ltru-registry-14 (work in progress), October 2005. 782 [17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 783 Considerations Section in RFCs", BCP 26, RFC 2434, 784 October 1998. 786 [18] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 787 Configuration Protocol Option for Coordinate-based Location 788 Configuration Information", RFC 3825, July 2004. 790 [19] Peterson, J., "A Presence-based GEOPRIV Location Object 791 Format", RFC 4119, December 2005. 793 [20] United States Postal Service, "Postal Addressing Standards", 794 November 2000. 796 [21] National Emergency Number Assocation, "NENA Recommended Formats 797 and Protocols For ALI Data Exchange, ALI Response and GIS 798 Mapping", NENA NENA-02-010, January 2002. 800 Author's Address 802 Henning Schulzrinne 803 Columbia University 804 Department of Computer Science 805 450 Computer Science Building 806 New York, NY 10027 807 US 809 Phone: +1 212 939 7004 810 Email: hgs+geopriv@cs.columbia.edu 811 URI: http://www.cs.columbia.edu 813 Appendix A. Acknowledgments 815 Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, 816 David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson 817 and Hannes Tschofenig provided helpful comments. Examples and 818 inspiration were drawn from the Street Address Data Standard of the 819 Federal Geographic Data Committee. 821 Intellectual Property Statement 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr@ietf.org. 845 Disclaimer of Validity 847 This document and the information contained herein are provided on an 848 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 849 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 850 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 851 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 852 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 853 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 855 Copyright Statement 857 Copyright (C) The Internet Society (2006). This document is subject 858 to the rights, licenses and restrictions contained in BCP 78, and 859 except as set forth therein, the authors retain all their rights. 861 Acknowledgment 863 Funding for the RFC Editor function is currently provided by the 864 Internet Society.