Location Types Registry
Extracted elements (17)
Protocols using this registry are encouraged to provide additional mechanisms (e.g., free-text fields with language and character set labeling) to accommodate location types not currently registered, avoiding the need to register every conceivable location term.
Terms are intentionally kept at the level of detail found on geographic maps and are meant to be in common use across cultures and countries. Expert review guidance specifies that tokens must not be specific to a country, region, organization, or company and must be well-defined and widely recognized.
The registry deliberately avoids imposing a strict hierarchy of location descriptions. Multiple terms can apply simultaneously to the same location (e.g., 'restaurant' and 'airport'), and no limit is placed on the number of terms that can describe a single place, as few combinations are physically impossible.
The registry uses protocol tokens (constants) rather than free-text strings to enable systems to operate across multiple languages; a UI can readily translate a finite set of tokens to user-appropriate textual or iconic representations without requiring per-token internationalization.
The location type registry is designed for use by multiple protocols: DHCPv4/DHCPv6 options for civic address information, RADIUS attributes carrying location from client to server, and Rich Presence (RPID) extensions to PIDF all reference this registry as a common vocabulary.
New tokens are assigned after Expert Review following RFC 2434 policies. The Expert Reviewer will generally consult the IETF GeoPRIV working group mailing list or its designated successor. Updates or deletions follow the same procedures.
The location type values listed in this document MUST NOT be presented to the user; they function as tokens or tags, so no internationalization support is required.
To ensure widespread usability across protocols, tokens MUST follow the character set restrictions for XML Names as defined in the XML 1.0 specification.
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.
The 'other' token represents a place without a registered place type representation and is the only location type defined with the 'Note_t' complex type (which carries an xml:lang attribute), allowing a free-text description when no registered token applies.
The 'public' token is defined as an umbrella term encompassing more precise descriptors including 'street', 'public-transport', 'aircraft', 'bus', 'bus-station', 'train', 'train-station', 'airport', 'shopping-area', 'outdoors', and 'watercraft'. It may be used when finer-grained location detail is unavailable or privacy concerns favor less precise terms.
The 'restaurant' token is defined to include cafes, and 'public-transport' encompasses aircraft, bus, train, and ship, illustrating the deliberate inclusion hierarchy used in a subset of token definitions.
The 'unknown' token indicates that the type of place is unknown, distinct from 'other' which indicates a known but unregistered place type.
IANA created a new registry for location type tokens, initially populated with tokens from 'aircraft' through 'watercraft' as listed in Section 3. The registry is maintained both as an XML schema and as a list of tokens with identical content.
IANA registered the URN sub-namespace urn:ietf:params:xml:ns:location-type for XML elements defined by RFC 4589 to describe location types within XML documents. Registrant contact is the IETF GEOPRIV working group.
This document defines a registry for location types and as such does not raise security issues. The registry itself introduces no new protocol mechanisms that could be exploited.
The XML schema at namespace urn:ietf:params:xml:ns:location-type defines each location type as an empty-content XML element (type 'empty'), except 'other' which uses type 'Note_t' (xs:string extended with an optional xml:lang attribute). The schema can be referenced via namespace="##other" in other schemas.