doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4589.txt b/doc/rfc/rfc4589.txt
new file mode 100644
index 0000000..fbf7abf
--- /dev/null
+++ b/doc/rfc/rfc4589.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                     H. Schulzrinne
+Request for Comments: 4589                                   Columbia U.
+Category: Standards Track                                  H. Tschofenig
+                                                                 Siemens
+                                                               July 2006
+
+
+                        Location Types Registry
+
+Status 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 Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Location Types ..................................................3
+   4. Schema ..........................................................6
+   5. IANA Considerations .............................................7
+      5.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 .......................9
+   6. Internationalization Considerations .............................9
+   7. Security Considerations .........................................9
+   8. Acknowledgements ................................................9
+   9. References .....................................................10
+      9.1. Normative References ......................................10
+      9.2. Informative References ....................................10
+
+
+
+
+Schulzrinne & Tschofenig    Standards Track                     [Page 1]
+
+RFC 4589                Location Types Registry                July 2006
+
+
+1.  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.  Common
+
+
+
+Schulzrinne & 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 Considerations
+
+5.1.  Registering Tokens
+
+   This document creates new IANA registries for location types as
+   listed in Section 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 in RFC 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 by
+      RFC4589 to describe location types within XML documents.
+
+   Registrant Contact:  IETF, GEOPRIV working group, geopriv@ietf.org,
+      Henning Schulzrinne, hgs@cs.columbia.edu
+
+
+
+
+Schulzrinne & 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>
+     END
+
+5.3.  Schema Registration for Schema
+      urn:ietf:params:xml:ns:location-type
+
+   URI:  urn:ietf:params:xml:ns:location-type
+
+   Registrant Contact:  IESG
+
+   XML:  See Section 4
+
+6.  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 Justice
+
+
+
+Schulzrinne & Tschofenig    Standards Track                     [Page 9]
+
+RFC 4589                Location Types Registry                July 2006
+
+
+   XML work (see http://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.  References
+
+9.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
+        Recommendation http://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 2006
+
+
+Authors' 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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne & Tschofenig    Standards Track                    [Page 11]
+
+RFC 4589                Location Types Registry                July 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 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 in BCP 78 and BCP 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 at
+   http://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]
+