Network Working Group J. Peterson
Request for Comments: 4119 NeuStar
Category: Standards Track December 2005
A Presence-based GEOPRIV Location Object Format
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 (2005).
Abstract
This document describes an object format for carrying geographical
information on the Internet. This location object extends the
Presence Information Data Format (PIDF), which was designed for
communicating privacy-sensitive presence information and which has
similar properties.
Peterson Standards Track [Page 1]
RFC 4119 GEOPRIV Location Object December 2005
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Location Object Format ..........................................4
2.1. Baseline PIDF Usage ........................................4
2.2. Extensions to PIDF for Location and Usage Rules ............5
2.2.1. 'location-info' Element .............................5
2.2.2. 'usage-rules' Element ...............................7
2.2.3. 'method' Element ....................................9
2.2.4. 'provided-by' Element ...............................9
2.2.5. Schema Definitions .................................10
2.3. Example Location Objects ..................................14
3. Carrying PIDF in a Using Protocol ..............................15
4. Securing PIDF ..................................................15
5. Security Considerations ........................................17
6. IANA Considerations ............................................17
6.1. 'method' Tokens ...........................................17
6.2. 'provided-by' Elements ....................................18
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
7. Acknowledgements ...............................................19
A. Appendix: NENA Provided-by Schema ..............................20
A.1. dataProvider XML Schema ...................................21
Normative References ..............................................22
Informative References ............................................22
1. Introduction
Geographical location information describes a physical position in
the world that may correspond to the past, present, or future
location of a person, event, or device. Numerous applications used
in the Internet today benefit from sharing location information
(including mapping/navigation applications, 'friend finders' on cell
phones, and so on). However, such applications may disclose the
whereabouts of a person in a manner contrary to the user's
preferences. Privacy lapses may result from poor protocol security
(which permits eavesdroppers to capture location information),
inability to articulate or accommodate user preferences, or similar
defects common in existing systems. The privacy concerns surrounding
the unwanted disclosure of a person's physical location are among the
more serious issues that confront users on the Internet.
Consequently, a need has been identified to convey geographical
location information within an object that includes a user's privacy
and disclosure preferences and which is protected by strong
cryptographic security. Previous work [13] has observed that this
problem bears some resemblance to the general problem of
Peterson Standards Track [Page 2]
RFC 4119 GEOPRIV Location Object December 2005
communicating and securing presence information on the Internet.
Presence (defined in [12]) provides a real-time communications
disposition for a user, and thus has similar requirements for
selective distribution and security.
Therefore, this document extends the XML-based Presence Information
Data Format (PIDF [2]) to allow the encapsulation of location
information within a presence document.
This document does not invent any format for location information
itself. Numerous existing formats based on civic location,
geographic coordinates, and the like, have been developed in other
standards fora. Instead, this document defines an object that is
suitable both for identifying and encapsulating preexisting location
information formats, and for providing adequate security and policy
controls to regulate the distribution of location information over
the Internet.
The location object described in this document can be used
independently of any 'using protocol', as the term is defined in the
GEOPRIV requirements [10]. It is considered an advantage of this
proposal that existing presence protocols (such as [14]) would
natively accommodate the location object format defined in this
document, and be capable of composing location information with other
presence information, because this location object is an extension of
PIDF. However, the usage of this location object format is not
limited to presence-using protocols-- any protocol that can carry XML
or MIME types can carry PIDF.
Some of the requirements in [10] and [11] concern data collection and
usage policies associated with location objects. This document
provides only the minimum markup necessary for a user to express the
necessary privacy preferences as specified by the GEOPRIV
requirements (the three basic elements in [11]). However, this
document does not demonstrate how a full XML-based ruleset,
accommodating the needs of Location Servers, could be embedded in
PIDF. It is assumed that other protocols (such as HTTP) will be used
to move rules between Rule Holders and Location Servers, and that
full rulesets will be defined in a separate document.
1.1. Conventions Used in This Document
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].
Peterson Standards Track [Page 3]
RFC 4119 GEOPRIV Location Object December 2005
2. Location Object Format
2.1. Baseline PIDF Usage
The GEOPRIV requirements [10] (or REQ for short) specify the need for
a name for the person, place or thing that location information
describes (REQ 2.1). PIDF has such an identifier already: every
PIDF document has an "entity" attribute of the 'presence' element
that signifies the URI of the entity whose presence the document
describes. Consequently, if location information is contained in a
PIDF document, the URI in the "entity" attribute of the 'presence'
element indicates the target of that location information (the
'presentity'). The URI in the "entity" attribute generally uses the
"pres" URI scheme defined in [3]. Such URIs can serve as unlinkable
pseudonyms (per REQ 12).
PIDF optionally contains a 'contact' element that provides a URI
where the presentity can be reached by some means of communication.
Usually, the URI scheme in the value of the 'contact' element gives
some sense of how the presentity can be reached; if it uses the SIP
URI scheme, for example, SIP can be used, and so on. Location
information can be provided without any associated means of
communication. Thus, the 'contact' element may or may not be
present, as desired by the creator of the PIDF document.
PIDF optionally contains a 'timestamp' element that designates the
time at which the PIDF document was created. This element
corresponds to REQ 2.7a.
PIDF contains a 'status' element, which is mandatory. 'status'
contains an optional child element, 'basic', that describes the
presentity's communications disposition (in very broad terms: either
OPEN or CLOSED). For the purposes of this document, it is not
necessary for 'basic' status to be included. If, however,
communications disposition is included in a PIDF document above and
beyond geolocation, then 'basic' status may appear in a PIDF document
that uses these extensions.
PIDF also contains a 'tuple' umbrella element, which holds an "id"
element used to uniquely identify a segment of presence information
so that changes to this information can be tracked over time (as
multiple notifications of presence are received). 'timestamp',
'status', and 'contact' are composed under 'tuple'.
Peterson Standards Track [Page 4]
RFC 4119 GEOPRIV Location Object December 2005
2.2. Extensions to PIDF for Location and Usage Rules
This XML Schema extends the 'status' element of PIDF with a complex
element called 'geopriv'. There are two major subelements that are
encapsulated within geopriv: one for location information, and one
for usage rules. Both of these subelements are mandatory, and are
described in subsequent sections. By composing these two subelements
under 'geopriv', the usage rules are clearly and explicitly
associated with the location information.
For extensibility (see REQ 1.4), the schema allows any other
subelements to appear under the 'geopriv' element. Two other
optional subelements are included in this document: one that
indicates the method by which geographical location was determined,
and one that allows an explicit designation of the entity that
provided the information.
2.2.1. 'location-info' Element
Each 'geopriv' element MUST contain one 'location-info' element. A
'location-info' element consists of one or more chunks of location
information (per REQ 2.5). The format of the location information
(REQ 2.6) is identified by the imported XML Schema, which describes
the namespace in question. All PIDF documents that contain a
'geopriv' element MUST contain one or more import directives
indicating the XML Schema(s) that are used for geographic location
formats.
In order to ensure interoperability of GEOPRIV implementations, it is
necessary to select a baseline location format that all compliant
implementations support (see REQ 3.1). Because it satisfies REQ
2.5.1, this document works from the assumption that Geography Markup
Language (GML) 3.0 [15] shall be this mandatory format (a MUST
implement for all PIDF implementations supporting the 'geopriv'
element).
GML is an extraordinarily thorough and versatile system for modeling
all manner of geographic object types, topologies, metadata,
coordinate reference systems, and units of measurement. The simplest
package for GML supporting location
information is the 'feature.xsd' schema. Although 'feature.xsd' can
express complicated geographical concepts, it requires very little
markup to provide basic coordinate points for the most commonly used
cases. Various format descriptions (including latitude/longitude
based location information) are supported by Feature (see section
7.4.1.4 of [15] for examples), which resides here:
Peterson Standards Track [Page 5]
RFC 4119 GEOPRIV Location Object December 2005
urn:opengis:specification:gml:schema-xsd:feature:v3.0
Note that by importing the Feature schema, necessary GML baseline
schemas are transitively imported.
Complex features (such as modeling topologies and polygons,
directions and vectors, temporal indications of the time for which a
particular location is valid for a target) are also available in GML,
but require importing additional schemas. For the purposes of
baseline interoperability as defined by this document, only support
for the 'feature.xsd' GML schema is REQUIRED.
Implementations MAY support the civic location format (civicLoc)
defined in Section 2.2.5. civicLoc provides the following elements:
+----------------------+----------------------+---------------------+
| Label | Description | Example |
+----------------------+----------------------+---------------------+
| country | The country is | US |
| | identified by the | |
| | two-letter ISO 3166 | |
| | code. | |
| | | |
| A1 | national | New York |
| | subdivisions (state, | |
| | region, province, | |
| | prefecture) | |
| | | |
| A2 | county, parish, gun | King's County |
| | (JP), district (IN) | |
| | | |
| A3 | city, township, shi | New York |
| | (JP) | |
| | | |
| A4 | city division, | Manhattan |
| | borough, city | |
| | district, ward, chou | |
| | (JP) | |
| | | |
| A5 | neighborhood, block | Morningside Heights |
| | | |
| A6 | street | Broadway |
| | | |
| PRD | Leading street | N, W |
| | direction | |
| | | |
| POD | Trailing street | SW |
| | suffix | |
Peterson Standards Track [Page 6]
RFC 4119 GEOPRIV Location Object December 2005
| | | |
| STS | Street suffix | Avenue, Platz, |
| | | Street |
| | | |
| HNO | House number, | 123 |
| | numeric part only. | |
| | | |
| HNS | House number suffix | A, 1/2 |
| | | |
| LMK | Landmark or vanity | Low Library |
| | address | |
| | | |
| LOC | Additional location | Room 543 |
| | information | |
| | | |
| FLR | Floor | 5 |
| | | |
| NAM | Name (residence, | Joe's Barbershop |
| | business or office | |
| | occupant) | |
| | | |
| PC | Postal code | 10027-0401 |
+----------------------+----------------------+---------------------+
Either the GML 3.0 geographical information format element, or the
location format element ('civicLoc') defined in this document, MAY
appear in a 'location-info' element. Both MAY also be used in the
same 'location-info' element. In summary, the feature.xsd schema of
GML 3.0 MUST be supported by implementations compliant with this
specification, and the civicLoc format MAY be supported by
implementations compliant with this specification.
2.2.2. 'usage-rules' Element
At the time this document was written, the policy requirements for
GEOPRIV objects were not definitively completed. However, the
'usage-rules' element exists to satisfy REQ 2.8 and the requirements
of the GEOPRIV policy requirements [11] document. Each 'geopriv'
element MUST contain one 'usage-rules' element, even if the Rule
Maker has requested that all subelements be given their default
values.
Following the policy requirements document (Section 3.1), there are
three fields that need to be expressible in Location Objects
throughout their lifecycle (from Generator to Recipient): one field
that limits retransmission, one that limits retention, and one that
contains a reference to external rulesets. Those three fields are
Peterson Standards Track [Page 7]
RFC 4119 GEOPRIV Location Object December 2005
instantiated here by the first three elements. The fourth element
provides a generic space for human-readable policy directives. Any
of these fields MAY be present in a Location Object 'usage-rules'
element; none are required to be.
'retransmission-allowed': When the value of this element is 'no', the
Recipient of this Location Object is not permitted to share the
enclosed Location Information, or the object as a whole, with
other parties. When the value of this element is 'yes',
distributing this Location is permitted (barring an existing out-
of-band agreement or obligation to the contrary). By default, the
value MUST be assumed to be 'no'. Implementations MUST include
this field, with a value of 'no', if the Rule Maker specifies no
preference.
'retention-expires': This field specifies an absolute date at which
time the Recipient is no longer permitted to possess the location
information and its encapsulating Location Object; both may be
retained only until the time specified by this field. By default,
the value MUST be assumed to be twenty-four hours from the
'timestamp' element in the PIDF document, if present; if the
'timestamp' element is also not present, then the value MUST be
assumed to be twenty-four hours from the time at which the
Location Object is received by the Location Recipient. If the
value in the 'retention-expires' element has already passed when
the Location Recipient receives the Location Object, the Recipient
MUST discard the Location Object immediately.
'ruleset-reference': This field contains a URI that indicates where a
fuller ruleset of policies, related to this object, can be found.
This URI SHOULD use the HTTPS URI scheme; and if it does, the
server that holds these rules MUST authenticate any attempt to
access these rules. Usage rules themselves may divulge private
information about a Target or Rule Maker. The URI MAY,
alternatively, use the CID URI scheme [7], in which case it MUST
denote a MIME body carried with the Location Object by the using
protocol. Rulesets carried as MIME bodies SHOULD be encrypted and
signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored
by Location Servers or Location Recipients. Note that in order to
avoid network lookups that result in an authorization failure,
creators of Location Objects MAY put HTTPS-based ruleset-
references into an encrypted external MIME body referenced by a
CID; in this way, recipients of the Location Object that are
unable to decrypt the external MIME body will not learn the HTTPS
URI unless they are able to decrypt the MIME body.
Peterson Standards Track [Page 8]
RFC 4119 GEOPRIV Location Object December 2005
'note-well': This field contains a block of text containing further
generic privacy directives. These directives are intended to be
human-readable only, not to be processed by any automaton.
2.2.3. 'method' Element
The optional 'method' element describes the way that the location
information was derived or discovered. An example of this element
(for a geographical position system) is:
See Peterson Standards Track [Page 18] RFC 4119 GEOPRIV Location Object December 2005 RFC4119.
END 7. Acknowledgements This document was produced with the assistance of many members of the GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS for a close read of the document. The civic location format described in this document was proposed by Henning Schulzrinne for communicating location information in DHCP, and has been appropriated in its entirety for this document. James M. Polk provided the text related to the 'method' element, and much of the text for the 'provided-by' element. The text of Appendix A was written by Nadine Abbott. Peterson Standards Track [Page 19] RFC 4119 GEOPRIV Location Object December 2005 A. Appendix: NENA Provided-By Schema The following registers the XML namespace urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated schema below, for usage within the 'provided-by' element of PIDF-LO. The dataProvider namespace was developed by the US National Emergency Number Administration (NENA) for next-generation emergency communications needs. This appendix is non-normative for implementers of PIDF-LO implementations and MAY support the dataProvider namespace. Other registrants of 'provided-by' namespaces are invited to use the registration below as an informative example. URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV working group, (geopriv@ietf.org), Nadine Abbott (nabbott@telcordia.com). XML: BEGINSee RFC4119.
END Peterson Standards Track [Page 20] RFC 4119 GEOPRIV Location Object December 2005 A.1. dataProvider XML Schema