idnits 2.17.1 draft-ietf-geopriv-location-types-registry-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 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 521. ** 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 (May 21, 2006) is 6551 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) ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-24) exists of draft-ietf-geopriv-radius-lo-06 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 H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: November 22, 2006 H. Tschofenig 5 Siemens 6 May 21, 2006 8 Location Types Registry 9 draft-ietf-geopriv-location-types-registry-06 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 November 22, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document creates a registry for describing the types of places a 43 human or end system might be found. The registry is then referenced 44 by other protocols that need a common set of location terms as 45 protocol constants. Examples of location terms defined in this 46 document include aircraft, office and train station. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Location Types . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 55 5.1 Registering Tokens . . . . . . . . . . . . . . . . . . . . 11 56 5.2 URN Sub-Namespace Registration for 57 'urn:ietf:params:xml:ns:location-type' . . . . . . . . . . 12 58 5.3 Schema Registration for Schema 59 urn:ietf:params:xml:ns:location-type . . . . . . . . . . . 12 60 6. Internationalization Considerations . . . . . . . . . . . . . 13 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 65 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . 18 69 1. Introduction 71 This document creates a registry for location type tokens. We 72 anticipate that the network, through configuration or management 73 protocols, tells a mobile device what kind of location it finds 74 itself in. The device and associated software can then tailor its 75 behavior to the environment. For example, this document defines the 76 terms "classroom", "place-of-worship" and "theater". A considerate 77 owner of a cell phone might program the device to switch from ringer 78 to vibrate mode in such environments. Just knowing the geographic 79 location, be it as civic (street address) or geospatial coordinates 80 would generally not allow the device to make a similar decision. 82 Naturally, the number of descriptive terms for physical environments 83 is almost unbounded. This registry tries to identify common terms 84 that are likely to be useful for communications devices and for 85 controlling and guiding communication behavior. The terms roughly 86 correspond to the level of details of location descriptions and icons 87 found on geographic maps, for example, and are meant to be in common 88 use across a variety of cultures and countries. The registration 89 process described in the IANA Considerations section allows to extend 90 this list as needed, while aiming to prevent an unnecessary explosion 91 in the registry. 93 The use of tokens, i.e., protocol constants, makes it easier to build 94 systems across multiple languages. A user interface can readily 95 translate a finite set of tokens to user-appropriate textual or 96 iconic representations. Protocols using this registry are encouraged 97 to provide additional mechanisms to accommodate location types not 98 currently registered via free-text fields with appropriate language 99 and character set labeling. 101 The terms defined in this registry do not attempt to provide a 102 hierarchy of location descriptions, except in certain special cases. 103 For example, the term "restaurant" is defined to include the term 104 "cafe" and the term "public" encompasses a range of descriptors, as 105 noted below. The registry makes these more generic terms available 106 as often the more detailed distinctions may not be available, or 107 privacy concerns suggest the use of less precise terms that are still 108 sufficient to guide communications behavior or evaluate the source of 109 a phone call or message, say. 111 In many cases, a location might be described by multiple terms that 112 apply at the same time. For example, the combination of "restaurant" 113 and "airport" is immediately recognizable. This registry makes no 114 attempt to limit the number of terms that can be used to describe a 115 single place or to restrict what combinations are allowed, given that 116 there are few combinations that are physically impossible. Common 117 sense is probably a better guide here; the authors would not want to 118 rule out creative business models such as combinations of "parking" 119 and "restaurant" or "bar" and "hospital". The number of terms that 120 can be used within the same protocol element is left to the protocol 121 description. 123 This document does not describe how the values of the registry are to 124 be used, as this description is provided by other documents. For 125 example, [4], describes a options for carrying civic address 126 information, including the place-type attributes listed in this 127 document, using the Dynamic Host Configuration Protocol (DHCPv4 and 128 DHCPv6). A usage for RADIUS is described in [5], where this 129 information is conveyed from the RADIUS client to the RADIUS server. 130 Rich presence (RPID [6]) also utilizes the values of the location 131 type registry. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [1]. 139 3. Location Types 141 This section describes types of location where an entity is located. 142 The entity is not further specified and can be a person or an object 143 such as a network access point or end system. 145 aircraft: A device that is used or intended to be used for flight in 146 the air, such as an airplane, helicopter, gyroplane, glider or 147 lighter-than-air devices like a balloon. 149 airport: A place from which aircraft operate, such as an airport or 150 heliport. 152 arena: Enclosed area used for sports events. 154 automobile: A usually four-wheeled automotive vehicle designed for 155 passenger transportation, such as a car. 157 bank: Business establishment in which money is kept for saving or 158 commercial purposes or is invested, supplied for loans, or 159 exchanged. 161 bar: A bar or saloon. 163 bus: A large motor vehicle designed to carry passengers. 165 bicycle: A vehicle with two wheels tandem, a steering handle, a 166 saddle seat, and pedals by which it is propelled. 168 bus-station: Terminal that serves bus passengers, such as a bus depot 169 or bus terminal. 171 cafe: Usually small and informal establishment serving various 172 refreshments (such as coffee); coffee shop. 174 classroom: Academic classroom or lecture hall. 176 club: Dance club, nightclub or discotheque. 178 construction: Construction site. 180 convention-center: Convention center or exhibition hall. 182 government: Government building, such as those used by the 183 legislative, executive, or judicial branches of governments, 184 including court houses, police stations and military 185 installations. 187 hospital: Hospital, hospice, medical clinic, mental institution, or 188 doctor's office. 190 hotel: Hotel, motel, inn or other lodging establishment. 192 industrial: Industrial setting, such as a manufacturing floor or 193 power plant. 195 library: Library or other public place in which literary and artistic 196 materials, such as books, music, periodicals, newspapers, 197 pamphlets, prints, records, and tapes, are kept for reading, 198 reference, or lending. 200 motorcycle: A two-wheeled automotive vehicle, including a scooter. 202 office: Business setting, such as an office. 204 other: A place without a registered place type representation. 206 outdoors: Outside a building, in or into the open air, such as a park 207 or city streets. 209 parking: A parking lot or parking garage. 211 place-of-worship: A religious site where congregations gather for 212 religious observances, such as a church, chapel, meetinghouse, 213 mosque, shrine, synagogue, or temple. 215 prison: Correctional institution where persons are confined while on 216 trial or for punishment, such as a prison, penitentiary, jail, 217 brig. 219 public: Public area such as a shopping mall, street, park, public 220 building, train station, airport or in public conveyance such as a 221 bus, train, plane or ship. This general description encompasses 222 the more precise descriptors 'street', 'public-transport', 223 'aircraft', 'bus', 'bus-station', 'train', 'train-station', 224 'airport', 'shopping-area', 'outdoors', and 'watercraft'. 226 public-transport: Any form of public transport, including aircraft, 227 bus, train or ship. 229 residence: A private or residential setting, not necessarily the 230 personal residence of the entity, e.g., including a friend's home. 232 restaurant: Restaurant, coffee shop or other public dining 233 establishment. 235 school: School or university property, but not necessarily a 236 classroom or library. 238 shopping-area: Shopping mall or shopping area. This area is a large, 239 often enclosed shopping complex containing various stores, 240 businesses, and restaurants usually accessible by common 241 passageways. 243 stadium: Large, usually open structure for sports events, including a 244 racetrack. 246 store: Place where merchandise is offered for sale, such as a shop. 248 street: A public thoroughfare, such as a avenue, street, alley, lane, 249 road, including any sidewalks. 251 theater: Theater, lecture hall, auditorium, class room, movie theater 252 or similar facility designed for presentations, talks, plays, 253 music performances and other events involving an audience. 255 train: Train, monorail, maglev, cable car or similar conveyance. 257 train-station: Terminal where trains load or unload passengers or 258 goods; railway station, railroad station, railroad terminal, train 259 depot. 261 truck: An automotive vehicle suitable for hauling, used primarily to 262 carry goods rather than people. 264 underway: In a land, water, or air craft which is underway (in 265 motion). 267 unknown: The type of place is unknown. 269 warehouse: Place in which goods or merchandise are stored, such as a 270 storehouse or self-storage facility. 272 water: In, on or above bodies of water, such as an ocean, lake, 273 river, canal or other waterway. 275 watercraft: On a vessel for travel on water such as a boat or ship. 277 4. Schema 279 This registry can be used in two ways, first,as a list of tokens, to 280 be referenced by appropriate protocols that accept textual tokens and 281 secondly as a schema, with its own namespace, referenced by other 282 schema, either explicity or via namespace="##other". 284 285 291 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 338 5. IANA Considerations 340 5.1 Registering Tokens 342 This document creates new IANA registries for location types as 343 listed in Section 3 starting with 'aircraft' and finishing with 344 'watercraft'. 346 IANA will maintain this registry both in the form of an XML schema 347 and a list of tokens, with the same content. 349 Following the policies outline in RFC 2434 [2], new tokens are 350 assigned after Expert Review by the Expert Reviewer appointed by the 351 IESG. The same procedure applies to updates of tokens within the 352 registry and to deleting tokens from the registry. 354 The expert review should be guided by a few common-sense 355 considerations. For example, tokens should not be specific to a 356 country, region, organization or company, should be well-defined and 357 should be widely recognized. The Expert's support of IANA will 358 include providing IANA with the new token(s) when the update is 359 provided only in the form of a schema, and providing IANA with the 360 new schema element(s) when the update is provided only in the form of 361 a token. 363 To ensure widespread usability across protocols, tokens MUST follow 364 the character set restrictions for XML Names [3]. 366 Each registration must include the name of the token and a brief 367 description similar to the ones offered in for the initial 368 registrations contained this document: 370 Token Identifier: Identifier of the token. 372 Description: Brief description indicating the meaning of the token, 373 including one or more examples where the term encompasses several 374 more precise terms. 376 XML namespace: Tokens MAY be used as elements within other 377 appropriate XML documents. Each token lists the namespace it is 378 part of, typically urn:ietf:params:xml:ns:location-type:ext, where 379 'ext' is the name of the extension. 381 Note that the usage of these tokens is not limited to XML and the 382 'Token Identifier' is the XML element content and not the XML element 383 name. 385 5.2 URN Sub-Namespace Registration for 386 'urn:ietf:params:xml:ns:location-type' 388 URI: urn:ietf:params:xml:ns:location-type 390 Description: This is the XML namespace for XML elements defined by 391 RFCXXXX [RFC editor: replace with RFC number] to describe 392 location types within XML documents. 394 Registrant Contact: IETF, GEOPRIV working group, geopriv@ietf.org, 395 Henning Schulzrinne, hgs@cs.columbia.edu 397 XML: 399 BEGIN 400 401 403 407 Location Types Registry 408 409 410

Namespace for Location Types

411

urn:ietf:params:xml:ns:location-type

412

See RFC&rfc.number; [RFC 413 editor: replace with RFC number].

414 415 416 END 418 5.3 Schema Registration for Schema urn:ietf:params:xml:ns:location-type 420 URI: please assign 422 Registrant Contact: IESG 424 XML: See Section 4 426 6. Internationalization Considerations 428 The location-type values listed in this document MUST NOT be 429 presented to the user. The values therefore have the characteristic 430 of tokens or tags and no internationalization support is required. 432 7. Security Considerations 434 This document defines a registry for location types and as such does 435 not raise security issues. 437 8. Acknowledgements 439 Vijay Gurbani, Paul Kyzivat and Jonathan Rosenberg contributed to 440 RPID [6], which lead to the location types listed in this document. 441 Many thanks to Harald Alvestrand, Frank Ellermann, Bill Fenner, Ted 442 Hardie, David Kessens, Allison Mankin, Jon Peterson and Sam Hartman 443 for their suggestions. Rick Jones pointed us to the Global Justice 444 XML work (see http://it.ojp.gov/jxdm/) that helped us to add more 445 values to the location registry. 447 Some of the definitions are derived from the Merriam-Webster Online 448 Dictionary. 450 9. References 452 9.1 Normative References 454 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 455 Levels", BCP 14, RFC 2119, March 1997. 457 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 458 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 460 [3] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. 461 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 462 W3C REC REC-xml-20040204, February 2004. 464 9.2 Informative References 466 [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 467 and DHCPv6) Option for Civic Addresses Configuration 468 Information", draft-ietf-geopriv-dhcp-civil-09 (work in 469 progress), January 2006. 471 [5] Tschofenig, H., "Carrying Location Objects in RADIUS", 472 draft-ietf-geopriv-radius-lo-06 (work in progress), March 2006. 474 [6] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence 475 Information Data Format (PIDF)", draft-ietf-simple-rpid-10 476 (work in progress), December 2005. 478 Authors' Addresses 480 Henning Schulzrinne 481 Columbia University 482 Department of Computer Science 483 450 Computer Science Building 484 New York, NY 10027 485 USA 487 Phone: +1 212 939 7042 488 Email: schulzrinne@cs.columbia.edu 489 URI: http://www.cs.columbia.edu/~hgs 490 Hannes Tschofenig 491 Siemens 492 Otto-Hahn-Ring 6 493 Munich, Bavaria 81739 494 Germany 496 Email: Hannes.Tschofenig@siemens.com 497 URI: http://www.tschofenig.com 499 Intellectual Property Statement 501 The IETF takes no position regarding the validity or scope of any 502 Intellectual Property Rights or other rights that might be claimed to 503 pertain to the implementation or use of the technology described in 504 this document or the extent to which any license under such rights 505 might or might not be available; nor does it represent that it has 506 made any independent effort to identify any such rights. Information 507 on the procedures with respect to rights in RFC documents can be 508 found in BCP 78 and BCP 79. 510 Copies of IPR disclosures made to the IETF Secretariat and any 511 assurances of licenses to be made available, or the result of an 512 attempt made to obtain a general license or permission for the use of 513 such proprietary rights by implementers or users of this 514 specification can be obtained from the IETF on-line IPR repository at 515 http://www.ietf.org/ipr. 517 The IETF invites any interested party to bring to its attention any 518 copyrights, patents or patent applications, or other proprietary 519 rights that may cover technology that may be required to implement 520 this standard. Please address the information to the IETF at 521 ietf-ipr@ietf.org. 523 Disclaimer of Validity 525 This document and the information contained herein are provided on an 526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 528 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 529 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 530 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 533 Copyright Statement 535 Copyright (C) The Internet Society (2006). This document is subject 536 to the rights, licenses and restrictions contained in BCP 78, and 537 except as set forth therein, the authors retain all their rights. 539 Acknowledgment 541 Funding for the RFC Editor function is currently provided by the 542 Internet Society.