Movatterモバイル変換

Network Working Group                                     H. SchulzrinneRequest for Comments: 4589                                   Columbia U.Category: Standards Track                                  H. Tschofenig                                                                 Siemens                                                               July 2006Location Types RegistryStatus of This Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2006).Abstract   This document creates a registry for describing the types of places a   human or end system might be found.  The registry is then referenced   by other protocols that need a common set of location terms as   protocol constants.  Examples of location terms defined in this   document include aircraft, office, and train station.Table of Contents1. Introduction ....................................................22. Terminology .....................................................33. Location Types ..................................................34. Schema ..........................................................65. IANA Considerations .............................................75.1. Registering Tokens .........................................7      5.2. URN Sub-Namespace Registration for           urn:ietf:params:xml:ns:location-type .......................8      5.3. Schema Registration for Schema           urn:ietf:params:xml:ns:location-type .......................96. Internationalization Considerations .............................97. Security Considerations .........................................98. Acknowledgements ................................................99. References .....................................................109.1. Normative References ......................................109.2. Informative References ....................................10Schulzrinne & Tschofenig    Standards Track                     [Page 1]

RFC 4589                Location Types Registry                July 20061.  Introduction   This document creates a registry for location type tokens.  We   anticipate that the network, through configuration or management   protocols, tells a mobile device what kind of location it finds   itself in.  The device and associated software can then tailor its   behavior to the environment.  For example, this document defines the   terms "classroom", "place-of-worship", and "theater".  A considerate   owner of a cell phone might program the device to switch from ringer   to vibrate mode in such environments.  Just knowing the geographic   location, be it as civic (street address) or geospatial coordinates,   would generally not allow the device to make a similar decision.   Naturally, the number of descriptive terms for physical environments   is almost unbounded.  This registry tries to identify common terms   that are likely to be useful for communications devices and for   controlling and guiding communications behavior.  The terms roughly   correspond to the level of details of location descriptions and icons   found on geographic maps, for example, and are meant to be in common   use across a variety of cultures and countries.  The registration   process described in the IANA Considerations section allows this list   to be extended as needed, while aiming to prevent an unnecessary   explosion in the registry.   The use of tokens (i.e., protocol constants) makes it easier to build   systems across multiple languages.  A user interface can readily   translate a finite set of tokens to user-appropriate textual or   iconic representations.  Protocols using this registry are encouraged   to provide additional mechanisms to accommodate location types not   currently registered via free-text fields with appropriate language   and character set labeling.   The terms defined in this registry do not attempt to provide a   hierarchy of location descriptions, except in certain special cases.   For example, the term "restaurant" is defined to include the term   "cafe", and the term "public" encompasses a range of descriptors, as   noted below.  The registry makes these more generic terms available   as often the more detailed distinctions may not be available, or   privacy concerns suggest the use of less precise terms that are still   sufficient to guide communications behavior or evaluate the source of   a phone call or message, say.   In many cases, a location might be described by multiple terms that   apply at the same time.  For example, the combination of "restaurant"   and "airport" is immediately recognizable.  This registry makes no   attempt to limit the number of terms that can be used to describe a   single place or to restrict what combinations are allowed, given that   there are few combinations that are physically impossible.  CommonSchulzrinne & Tschofenig    Standards Track                     [Page 2]

RFC 4589                Location Types Registry                July 2006   sense is probably a better guide here; the authors would not want to   rule out creative business models such as combinations of "parking"   and "restaurant" or "bar" and "hospital".  The number of terms that   can be used within the same protocol element is left to the protocol   description.   This document does not describe how the values of the registry are to   be used, as this description is provided by other documents.  For   example, [5] describes options for carrying civic address   information, including the place type attributes listed in this   document, using the Dynamic Host Configuration Protocol (DHCPv4 and   DHCPv6).  A usage for Remote Authentication Dial-In User Service   (RADIUS) is described in [6], where this information is conveyed from   the RADIUS client to the RADIUS server.  Rich presence (RPID [4])   also utilizes the values of the location types registry.2.  Terminology   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [1].3.  Location Types   This section describes types of locations where an entity is located.   The entity is not further specified and can be a person or an object   such as a network access point or end system.   aircraft:  A device that is used or intended to be used for flight in      the air, such as an airplane, helicopter, gyroplane, glider, or      lighter-than-air devices like a balloon.   airport:  A place from which aircrafts operate, such as an airport or      heliport.   arena:  Enclosed area used for sports events.   automobile:  An automotive vehicle, usually four-wheeled, designed      for passenger transportation, such as a car.   bank:  Business establishment in which money is kept for saving,      commercial purposes, is invested, supplied for loans, or      exchanged.   bar:  A bar or saloon.   bicycle:  A vehicle with two wheels tandem, a steering handle, a      saddle seat, and pedals by which it is propelled.Schulzrinne & Tschofenig    Standards Track                     [Page 3]

RFC 4589                Location Types Registry                July 2006   bus:  A large motor vehicle designed to carry passengers.   bus-station:  Terminal that serves bus passengers, such as a bus      depot or bus terminal.   cafe:  Usually a small and informal establishment that serves various      refreshments (such as coffee); coffee shop.   classroom:  Academic classroom or lecture hall.   club:  Dance club, nightclub, or discotheque.   construction:  Construction site.   convention-center:  Convention center or exhibition hall.   government:  Government building, such as those used by the      legislative, executive, or judicial branches of governments,      including court houses, police stations, and military      installations.   hospital:  Hospital, hospice, medical clinic, mental institution, or      doctor's office.   hotel:  Hotel, motel, inn, or other lodging establishment.   industrial:  Industrial setting, such as a manufacturing floor or      power plant.   library:  Library or other public place in which literary and      artistic materials, such as books, music, periodicals, newspapers,      pamphlets, prints, records, and tapes, are kept for reading,      reference, or lending.   motorcycle:  A two-wheeled automotive vehicle, including a scooter.   office:  Business setting, such as an office.   other:  A place without a registered place type representation.   outdoors:  Outside a building, in or into the open air, such as a      park or city streets.   parking:  A parking lot or parking garage.   place-of-worship:  A religious site where congregations gather for      religious observances, such as a church, chapel, meetinghouse,      mosque, shrine, synagogue, or temple.Schulzrinne & Tschofenig    Standards Track                     [Page 4]

RFC 4589                Location Types Registry                July 2006   prison:  Correctional institution where persons are confined while on      trial or for punishment, such as a prison, penitentiary, jail,      brig.   public:  Public area such as a shopping mall, street, park, public      building, train station, or airport or in public conveyance such      as a bus, train, plane, or ship.  This general description      encompasses the more precise descriptors 'street', 'public-      transport', 'aircraft', 'bus', 'bus-station', 'train', 'train-      station', 'airport', 'shopping-area', 'outdoors', and      'watercraft'.   public-transport:  Any form of public transport, including aircraft,      bus, train, or ship.   residence:  A private or residential setting, not necessarily the      personal residence of the entity, e.g., including a friend's home.   restaurant:  Restaurant, coffee shop, or other public dining      establishment.   school:  School or university property, but not necessarily a      classroom or library.   shopping-area:  Shopping mall or shopping area.  This area is a      large, often enclosed, shopping complex containing various stores,      businesses, and restaurants usually accessible by common      passageways.   stadium:  Large, usually open structure for sports events, including      a racetrack.   store:  Place where merchandise is offered for sale, such as a shop.   street:  A public thoroughfare, such as an avenue, street, alley,      lane, or road, including any sidewalks.   theater:  Theater, lecture hall, auditorium, classroom, movie      theater, or similar facility designed for presentations, talks,      plays, music performances, and other events involving an audience.   train:  Train, monorail, maglev, cable car, or similar conveyance.   train-station:  Terminal where trains load or unload passengers or      goods; railway station, railroad station, railroad terminal, train      depot.Schulzrinne & Tschofenig    Standards Track                     [Page 5]

RFC 4589                Location Types Registry                July 2006   truck:  An automotive vehicle suitable for hauling, used primarily to      carry goods rather than people.   underway:  In a land-, water-, or aircraft that is underway (in      motion).   unknown:  The type of place is unknown.   warehouse:  Place in which goods or merchandise are stored, such as a      storehouse or self-storage facility.   water:  In, on, or above bodies of water, such as an ocean, lake,      river, canal, or other waterway.   watercraft:  On a vessel for travel on water such as a boat or ship.4.  Schema   This registry can be used in two ways, first, as a list of tokens, to   be referenced by appropriate protocols that accept textual tokens,   and second, as a schema, with its own namespace, referenced by other   schema, either explicitly or via namespace="##other".   <?xml version="1.0" encoding="UTF-8"?>   <xs:schema targetNamespace="urn:ietf:params:xml:ns:location-type"      xmlns="urn:ietf:params:xml:ns:location-type"      xmlns:xs="http://www.w3.org/2001/XMLSchema"      elementFormDefault="qualified"      attributeFormDefault="unqualified">     <xs:complexType name="empty"/>      <xs:complexType name="Note_t">        <xs:simpleContent>          <xs:extension base="xs:string">            <xs:attribute ref="xml:lang"/>          </xs:extension>        </xs:simpleContent>      </xs:complexType>     <xs:element name="aircraft" type="empty" />     <xs:element name="airport" type="empty" />     <xs:element name="arena" type="empty" />     <xs:element name="automobile" type="empty" />     <xs:element name="bank" type="empty" />     <xs:element name="bar" type="empty" />     <xs:element name="bicyle" type="empty" />     <xs:element name="bus" type="empty" />Schulzrinne & Tschofenig    Standards Track                     [Page 6]

RFC 4589                Location Types Registry                July 2006     <xs:element name="bus-station" type="empty" />     <xs:element name="cafe" type="empty" />     <xs:element name="classroom" type="empty" />     <xs:element name="club" type="empty" />     <xs:element name="construction" type="empty" />     <xs:element name="convention-center" type="empty" />     <xs:element name="government" type="empty" />     <xs:element name="hospital" type="empty" />     <xs:element name="hotel" type="empty" />     <xs:element name="industrial" type="empty" />     <xs:element name="library" type="empty" />     <xs:element name="motorcycle" type="empty" />     <xs:element name="office" type="empty" />     <xs:element name="other" type="Note_t"/>     <xs:element name="outdoors" type="empty" />     <xs:element name="parking" type="empty" />     <xs:element name="place-of-worship" type="empty" />     <xs:element name="prison" type="empty" />     <xs:element name="public" type="empty" />     <xs:element name="public-transport" type="empty" />     <xs:element name="residence" type="empty" />     <xs:element name="restaurant" type="empty" />     <xs:element name="school" type="empty" />     <xs:element name="shopping-area" type="empty" />     <xs:element name="stadium" type="empty" />     <xs:element name="store" type="empty" />     <xs:element name="street" type="empty" />     <xs:element name="theater" type="empty" />     <xs:element name="train" type="empty" />     <xs:element name="train-station" type="empty" />     <xs:element name="truck" type="empty" />     <xs:element name="underway" type="empty" />     <xs:element name="unknown" type="empty" />     <xs:element name="warehouse" type="empty" />     <xs:element name="water" type="empty" />     <xs:element name="watercraft" type="empty" />   </xs:schema>5.  IANA Considerations5.1.  Registering Tokens   This document creates new IANA registries for location types as   listed inSection 3, starting with 'aircraft' and finishing with   'watercraft'.   IANA will maintain this registry both in the form of an XML schema   and a list of tokens, with the same content.Schulzrinne & Tschofenig    Standards Track                     [Page 7]

RFC 4589                Location Types Registry                July 2006   Following the policies outline inRFC 2434 [2], new tokens are   assigned after Expert Review.  The Expert Reviewer will generally   consult the IETF GeoPRIV working group mailing list or its designated   successor.  Updates or deletions of tokens from the registration   follow the same procedures.   The expert review should be guided by a few common sense   considerations.  For example, tokens should not be specific to a   country, region, organization, or company; they should be well-   defined and widely recognized.  The expert's support of IANA will   include providing IANA with the new token(s) when the update is   provided only in the form of a schema, and providing IANA with the   new schema element(s) when the update is provided only in the form of   a token.   To ensure widespread usability across protocols, tokens MUST follow   the character set restrictions for XML Names [3].   Each registration must include the name of the token and a brief   description similar to the ones offered herein for the initial   registrations contained this document:   Token Identifier:  Identifier of the token.   Description:  Brief description indicating the meaning of the token,      including one or more examples where the term encompasses several      more precise terms.   XML namespace:  Tokens MAY be used as elements within other      appropriate XML documents.  Each token lists the namespace it is      part of, typically urn:ietf:params:xml:ns:location-type:ext, where      'ext' is the name of the extension.   Note that the usage of these tokens is not limited to XML and the   'Token Identifier' is the XML element content and not the XML element   name.5.2.  URN Sub-Namespace Registration for      urn:ietf:params:xml:ns:location-type   URI:  urn:ietf:params:xml:ns:location-type   Description:  This is the XML namespace for XML elements defined byRFC4589 to describe location types within XML documents.   Registrant Contact:  IETF, GEOPRIV working group, geopriv@ietf.org,      Henning Schulzrinne, hgs@cs.columbia.eduSchulzrinne & Tschofenig    Standards Track                     [Page 8]

RFC 4589                Location Types Registry                July 2006   XML:   BEGIN     <?xml version="1.0"?>     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">     <html xmlns="http://www.w3.org/1999/xhtml     <head>          <meta http-equiv="content-type"          content="text/html;charset=iso-8859-1"/>          <title>Location Types Registry</title>     </head>     <body>         <h1>Namespace for Location Types</h1>         <h2>urn:ietf:params:xml:ns:location-type</h2>         <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4589.txt">RFC4589</a>.</p>      </body>      </html>     END5.3.  Schema Registration for Schema      urn:ietf:params:xml:ns:location-type   URI:  urn:ietf:params:xml:ns:location-type   Registrant Contact:  IESG   XML:  SeeSection 46.  Internationalization Considerations   The location type values listed in this document MUST NOT be   presented to the user.  The values therefore have the characteristic   of tokens or tags and no internationalization support is required.7.  Security Considerations   This document defines a registry for location types and as such does   not raise security issues.8.  Acknowledgements   Vijay Gurbani, Paul Kyzivat, and Jonathan Rosenberg contributed to   RPID [4], which led to the location types listed in this document.   Many thanks to Harald Alvestrand, Frank Ellermann, Bill Fenner, Ted   Hardie, David Kessens, Allison Mankin, Jon Peterson, and Sam Hartman   for their suggestions.  Rick Jones pointed us to the Global JusticeSchulzrinne & Tschofenig    Standards Track                     [Page 9]

RFC 4589                Location Types Registry                July 2006   XML work (seehttp://it.ojp.gov/jxdm/) that helped us to add more   values to the location registry.   Some of the definitions are derived from the Merriam-Webster Online   Dictionary.9.  References9.1.  Normative References   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA        Considerations Section in RFCs",BCP 26,RFC 2434, October 1998.   [3]  Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and F.        Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",        World Wide Web Consortium        Recommendationhttp://www.w3.org/TR/2004/REC-xml-20040204,        February 2004.9.2.  Informative References   [4]  Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence        Information Data Format (PIDF)", Work in Progress,        December 2005.   [5]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4        and DHCPv6) Option for Civic Addresses Configuration        Information", Work in Progress, January 2006.   [6]  Tschofenig, H.,"Carrying Location Objects in RADIUS", Work in        Progress, March 2006.Schulzrinne & Tschofenig    Standards Track                    [Page 10]

RFC 4589                Location Types Registry                July 2006Authors' Addresses   Henning Schulzrinne   Columbia University   Department of Computer Science   450 Computer Science Building   New York, NY  10027   USA   Phone: +1 212 939 7042   EMail: schulzrinne@cs.columbia.edu   URI:http://www.cs.columbia.edu/~hgs   Hannes Tschofenig   Siemens   Otto-Hahn-Ring 6   Munich, Bavaria  81739   Germany   EMail: Hannes.Tschofenig@siemens.com   URI:http://www.tschofenig.comSchulzrinne & Tschofenig    Standards Track                    [Page 11]

RFC 4589                Location Types Registry                July 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use of   such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at   ietf-ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is provided by the IETF   Administrative Support Activity (IASA).Schulzrinne & Tschofenig    Standards Track                    [Page 12]