idnits 2.17.1 draft-forte-ecrit-service-classification-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 53 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 2009) is 5551 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Forte 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia University 5 Expires: July 5, 2009 January 2009 7 Labels for Common Location-Based Services 8 draft-forte-ecrit-service-classification-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 5, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document creates a registry for describing the types of services 47 available at a specific location. The registry is expected to be 48 referenced by other protocols that need a common set of service terms 49 as protocol constants. In particular, we define location-based 50 service as either a point at a specific geographic location (e.g., 51 bus stop) or a service covering a specific region (e.g., pizza 52 delivery). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Location-based services . . . . . . . . . . . . . . . . . . . 3 59 4. Guidelines for the creation of new top-level services . . . . 10 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 5.1. Registering new tokens . . . . . . . . . . . . . . . . . . 11 62 5.2. Internationalization Considerations . . . . . . . . . . . 11 63 5.3. Security Considerations . . . . . . . . . . . . . . . . . 11 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 Many mobile devices are now equipped to determine the user's 70 geographic location, either through GPS, cell-tower mapping or a 71 network-based triangulation mechanism. Once location information is 72 available, it is natural to want to look up near-by places that 73 provide a specific service, sometimes called points-of-interest 74 (POI). Examples of such services include restaurants, stores, 75 hospitals, automatic teller machines and museums. 77 To allow such systems to operate across large geographic areas and 78 for multiple languages, it is useful to define a common set of terms, 79 so that the same service is labeled with the same token regardless of 80 who created a particular location service. The number of different 81 labels is clearly potentially very large, but only a relatively small 82 subset of common services is of particular interest to mobile users, 83 such as travelers and commuters. This document focuses on labels 84 commonly found on maps or in navigation devices. 86 This document creates a registry of service labels and an initial set 87 of values. The registry is protocol-agnostic and should work for all 88 protocols that can handle alphanumeric strings, including LoST 89 [RFC5222]. 91 2. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Location-based services 99 When not obvious, the definition of a particular service will be 100 specified in the future. In the following we enumerate a sub-set of 101 the most common location-based services, some of which are also 102 present in [RFC4589]. 104 urn:service:business 106 - business.convention-center 108 urn:service:communication 110 - communication.internet.802.-11 112 - communication.internet.802.-16 113 - communication.internet.802.-3 115 - communication.public-phone 117 urn:service:cultural 119 - cultural.art-gallery 121 - cultural.library 123 - cultural.monument 125 - cultural.museum 127 - cultural.theater 129 urn:service:education 131 - education.college 133 - education.day-care-center 135 - education.nursery 137 - education.primary-school 139 - education.school 141 - education.secondary-school 143 urn:service:entertainment 145 - entertainment.arena 147 - entertainment.basketball-court 149 - entertainment.bingo-hall 151 - entertainment.casino 153 - entertainment.cinema 155 - entertainment.club 157 - entertainment.field.ice-hockey 159 - entertainment.field.soccer 160 - entertainment.park 162 - entertainment.race-track 164 - entertainment.stadium 166 - entertainment.stadium.baseball 168 - entertainment.stadium.football 170 - entertainment.stadium.soccer 172 urn:service:financial 174 - financial.atm 176 - financial.bank 178 - financial.currency-exchange 180 urn:service:food 182 - food.bakery 184 - food.bar 186 - food.beer-garden 188 - food.cafe 190 - food.cafeteria 192 - food.coffee-house 194 - food.doughnut-shop 196 - food.fast-service 198 - food.ice-cream-parlor 200 - food.pancake-house 202 - food.pizza 204 - food.pub 206 - food.root-beer-stand 207 - food.street-vendor 209 - food.tea-house 211 - food.restaurant.barbecue 213 - food.restaurant.buffet 215 - food.restaurant.cn 217 - food.restaurant.creole [Louisiana cuisine] 219 - food.restaurant.de 221 - food.restaurant.diner 223 - food.restaurant.drive-in 225 - food.restaurant.es 227 - food.restaurant.ethnic 229 - food.restaurant.fast-casual 231 - food.restaurant.fast-food 233 - food.restaurant.fr 235 - food.restaurant.gr 237 - food.restaurant.hamburger 239 - food.restaurant.hot-dog 241 - food.restaurant.it 243 - food.restaurant.kosher 245 - food.restaurant.kr 247 - food.restaurant.other 249 - food.restaurant.pizzeria 251 - food.restaurant.revolving 253 - food.restaurant.seafood 254 - food.restaurant.steakhouse 256 - food.restaurant.tavern 258 - food.restaurant.theme [Such as Disney restaurants] 260 - food.restaurant.us 262 - food.restaurant.vegan 264 - food.restaurant.vegetarian 266 [Generally speaking, one "restaurant" entry per country can be 267 added, each with its own country suffix. Suffixes to be used here 268 are specified in [ISO3166].] 270 urn:service:fuel 272 - fuel.biodiesel-station 274 - fuel.cng-station 276 - fuel.diesel-station 278 - fuel.electricity-station 280 - fuel.ethanol-station 282 - fuel.gasoline-station 284 - fuel.hydrogen-station 286 - fuel.lng-station 288 - fuel.lpg-station 290 urn:service:government 292 - government.courthouse 294 - government.military-base 296 - government.prison 298 urn:service:lodging 300 - lodging.bed-and-breakfast 301 - lodging.hostel 303 - lodging.hotel 305 - lodging.motel 307 urn:service:medical 309 - medical.dentist 311 - medical.emergency-room 313 - medical.hospital 315 - medical.veterinarian 317 urn:service:religious 319 - religious.church.adventist 321 - religious.church.anabaptist 323 - religious.church.anglican 325 - religious.church.baptist.national 327 - religious.church.baptist.southern 329 - religious.church.congregationalist 331 - religious.church.episcopalian 333 - religious.church.greek-orthodox 335 - religious.church.latter-day-saints [Also known as Mormon church] 337 - religious.church.lutheran 339 - religious.church.methodist 341 - religious.church.pentecostal 343 - religious.church.presbyterian 345 - religious.church.protestant 347 ["Protestant" comprises: Adventist, Anabaptist, Baptist, 348 Congregationalist, Lutheran, Methodist, Presbyterian, Reformed, 349 Pentecostal, Restorationist] 351 - religious.church.reformed 353 - religious.church.restorationist 355 - religious.church.roman-catholic 357 - religious.house-of-worship 359 - religious.kingdom-hall 361 - religious.mosque 363 - religious.synagogue 365 - religious.temple.buddhist 367 - religious.temple.hindu 369 - religious.temple.masonic 371 urn:service:retail 373 - retail.bakery 375 - retail.barber 377 - retail.books 379 - retail.butcher 381 - retail.car-repair 383 - retail.clothing 385 - retail.electronics 387 - retail.fish 389 - retail.flowers 391 - retail.food 393 - retail.games 395 - retail.glass 396 - retail.jewelry 398 - retail.movies 400 - retail.music 402 - retail.news 404 - retail.optician 406 - retail.other 408 - retail.shoes 410 - retail.shopping-mall 412 - retail.spirits 414 - retail.tailor 416 - retail.travel 418 urn:service:transportation 420 - transportation.airport 422 - transportation.bycicle-rental 424 - transportation.bus-stop 426 - transportation.car-rental 428 - transportation.mechanic 430 - transportation.parking 432 - transportation.port 434 - transportation.subway 436 - transportation.taxi-stand 438 - transportation.train-station 440 4. Guidelines for the creation of new top-level services 442 The number of services that can be defined is very large. New 443 services, however, SHOULD at least satisfy the following guidelines. 445 - The service has to be of general interest; 447 - It should not be specific to a particular country or region; 449 - The language in which the new service is defined MUST be English 450 (this is a protocol token, not meant to be shown to humans); 452 - The newly defined services SHOULD correspond to a standard 453 statistical classification of enterprises or services, such as the 454 North American Industry Classification System (NAICS). 456 5. IANA Considerations 458 Registration template and URN scheme for emergency and non-emergency 459 services have been defined in [RFC5031] in Sections 3 and 4, 460 respectively. 462 5.1. Registering new tokens 464 This document creates new IANA registries for location-based services 465 as listed in Section 3, starting with 466 'urn:service:business.convention-center' and finishing with 467 'urn:service:transportation.train-station'. 469 Aside from the labels defined here, document 470 [draft-ietf-ecrit-service-urn-policy] defines the registration policy 471 for new service-identifying labels. 473 5.2. Internationalization Considerations 475 The service values listed in this document MUST NOT be presented to 476 the user. The values therefore have the characteristic of tokens or 477 tags and no internationalization support is required. 479 5.3. Security Considerations 481 This document defines a registry for location-based services and as 482 such does not raise security issues. The same security 483 considerations as in [RFC5031] apply. 485 6. References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 491 Emergency and Other Well-Known Services", RFC 5031, 492 January 2008. 494 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 495 Tschofenig, "LoST: A Location-to-Service Translation 496 Protocol", RFC 5222, August 2008. 498 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 499 Registry", July 2006. 501 [ISO3166] International Organization for Standardization (ISO), 502 "English country names and code elements", July 2006. 504 [draft-ietf-ecrit-service-urn-policy] 505 Forte, A. and H. Schulzrinne, "Policy for defining new 506 service-identifying labels for non-emergency services 507 (Internet draft - work in progress)", December 2009. 509 Authors' Addresses 511 Andrea G. Forte 512 Columbia University 513 Department of Computer Science 514 1214 Amsterdam Avenue, MC 0401 515 New York, NY 10027 516 USA 518 Email: andreaf@cs.columbia.edu 520 Henning Schulzrinne 521 Columbia University 522 Department of Computer Science 523 1214 Amsterdam Avenue, MC 0401 524 New York, NY 10027 525 USA 527 Email: hgs@cs.columbia.edu