SIMPLE R. Pailer
Internet-Draft mobilkom austria AG
Intended status: Standards Track March 20, 2007
Expires: September 21, 2007
A Location Presence Event Package for the Session Initiation Protocol
(SIP)
draft-pailer-locpres-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 21, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of location presence.
Presence is defined as the willingness and ability of a user to
communicate with other users on the network. Presence data is
general information about the state of a user like "on-line" and
"off-line". Location presence extends conventional presence by
taking the physical location of a user into account. Location
Pailer Expires September 21, 2007 [Page 1]
Internet-Draft Locpres Event Package March 2007
presence is information about the geographical position of a user.
Subscriptions and notifications of location presence are supported by
defining an event package within the general SIP event notification
framework. This protocol is also compliant with the Common Presence
Profile (CPP) framework.
Requirements Language
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 RFC 2119 [1].
Pailer Expires September 21, 2007 [Page 2]
Internet-Draft Locpres Event Package March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Relation to SIP Presence RFC 3856 . . . . . . . . . . . . . . 8
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9
5. Location Presence Event Package . . . . . . . . . . . . . . . 10
5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10
5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 10
5.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. SUBSCRIBE Body examples . . . . . . . . . . . . . . . 11
5.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13
5.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
5.5.1. NOTIFY body examples . . . . . . . . . . . . . . . . . 15
5.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 22
5.7. Notifier generation of NOTIFY requests . . . . . . . . . . 22
5.8. Subscriber processing of NOTIFY requests . . . . . . . . . 22
5.9. Handling of forked requests . . . . . . . . . . . . . . . 22
5.10. Rate of notifications . . . . . . . . . . . . . . . . . . 23
5.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 23
5.12. Use of URIs to Retrieve State . . . . . . . . . . . . . . 23
6. Usage of Presence URIs . . . . . . . . . . . . . . . . . . . . 24
7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.1. Location Presence Event Package . . . . . . . . . . . . . 29
9.2. MIME Registration for
application/location-presence-pidf+xml . . . . . . . . . . 29
9.3. MIME Registration for
application/location-presence-delta-filter+xml . . . . . . 30
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-presence-filter . . . . . 30
9.5. Schema Registration For location-presence-filter . . . . . 31
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 31
9.7. Schema Registration For containment . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Filtering and Reporting Location Notifications in
PIDF-LO documents (Normative) . . . . . . . . . . . . 35
A.1. Location Presence Filter Format . . . . . . . . . . . . . 35
A.1.1. Location Presence Filter Schema . . . . . . . . . . . 36
A.2. Containment . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. Containment Schema . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
Pailer Expires September 21, 2007 [Page 3]
Internet-Draft Locpres Event Package March 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 40
Pailer Expires September 21, 2007 [Page 4]
Internet-Draft Locpres Event Package March 2007
1. Introduction
This document specifies a location presence event package for the
Session Initiation Protocol (SIP) [2] according to the general SIP
event notification framework [3]. Location presence data is
information about the geographical position of a user. The location
presence protocol builds on the concepts of the general SIP presence
event package [4], but extends conventional presence by specifying
entities and rules for the processing of subscriptions and
notifications of location presence data.
Location presence data is needed in order to implement Location Based
Services (LBS). LBS provide added value by taking into account the
physical position of mobile users. Location presence data may
consist of plain geographical coordinates, access point cell IDs,
civil location in form of postal addresses or more abstract
definitions like 'in the office', 'at home'. Examples of services
are a map showing the user's current location or changing the
handling of incoming calls when the user enters a specified area.
The system architecture of the location presence event package is
based on the following two assumptions:
1. The optimal source for geographical location data is the
user's terminal. Typically a GPS module is used to obtain
location information. A network-based location method may be
used as a fall-back option.
2. Geographical location is a special type of presence
information that is referred to as 'location presence data'.
The fundamental assumption that leads to the reuse of the presence
architecture is that location information is regarded as a kind of
presence information [5]. The position of a user may in general be
related to his presence state. The access to both presence and
location data has the same requirements regarding security and
privacy.
Location presence data however shows some essential differences from
conventional presence data. Location data is semantically different
from classic presence data. Presence attributes, defined as the Rich
Presence Information Data Format (RPID) in RFC4480 [6] such as
location type, activity, sphere, etc. can each take a small set of
values, whereas geographical location has a continuous range of
values, limited only by location data accuracy. This requires
different handling of subscriptions for location presence data.
Pailer Expires September 21, 2007 [Page 5]
Internet-Draft Locpres Event Package March 2007
Whereas for conventional presence all watchers subscribe to changes
that occur to a subset of attributes, for location data each watcher
application may define different criteria for triggering events.
Hence, publishing and storing location information on servers like
normal presence information is not useful. Location data may also
originate from different sources than normal presence state. The
architecture of the location presence event package takes these
differences into account.
This document defines a Location Presence Agent (LPA). The LPA is a
Presence Agent for location data that is co-located with the Presence
User Agent in the user's mobile terminal. It is the task of the LPA
to process SUBSCRIBE requests for location presence data and to
provide location information in NOTIFY messages. As the LPA is a
software component running in the user's terminal, direct access to
location information (e.g. from a GPS module) is possible. This
means also that location data is distributed peer-to-peer between the
watcher and the presentity and that the user has full control over
the distribution of sensitive location data.
Notifications for conventional presence are sent out, when the
presence status of the presentity changes. In the case of location
data however, there is no predefined set of states. Therefore the
watcher has to describe in the body of the SUBSCRIBE message the
trigger conditions when the LPA should send out NOTIFY messages.
Otherwise the LPA would have to send notifications independently of
the actual need for that data. Trigger conditions for location data
is described in Appendix A and includes triggers, if a presentity has
moved a specified distance in horizontal or vertical direction, if a
presentity has exceeded a specified velocity, or if a presentity
enters/exits a certain area. Trigger conditions are necessary to
reduce the cardinality of the location presence state space.
Reducing the amount of notifications to a minimum is of utmost
importance for mobile applications, because sending messages over a
wireless link uses up battery and needs access network capacity. It
is the most important advantage of a terminal-based location method
that it supports triggered location notifications in a simple and
scalable way. This means that the trigger logic has to be
implemented in the terminal in form of an LPA.
The computing capacity of a mobile terminal will restrict the number
and complexity of location presence data trigger criteria that can be
processed in parallel. This document therefore specifies the
possibility to identify a specific trigger condition by a URL in an
'xlink:href' attribute. A presentity may publish a list of
predefined trigger conditions that a watcher can consequently
subscribe to. A predefined trigger condition that is named and
identifiable by a URI is a geographical tag defined by the
Pailer Expires September 21, 2007 [Page 6]
Internet-Draft Locpres Event Package March 2007
presentity. Unlike fixed presence states defined in RPID, trigger
conditions can be created dynamically so that notifications for
location presence data can be built around a user defined folksonomy
of geotags.
In order to provide location presence data for terminals that are not
equipped with a GPS module, or for terminals that are outside of GPS
coverage, a Location Presence Data Aggregator (LPDA) component is
specified in this document that aggregates location presence data
from different sources. An alternative location data source may be a
network based location enabler such as a 3GPP LCS [7]. Network based
location enablers are specified for 2G and 3G wireless networks but
offer in general a level of location data accuracy (~150 m) that is
significant inferior to satellite based systems like GPS.
Furthermore most deployed network based location enablers do not
support triggered location updates so that polling schemes have to be
used to track users which does not scale well. The LPDA acts as a
state agent for the presentity and may issue subscriptions to several
location data sources.
The location presence event package is compliant with the Common
Presence Profile (CPP) framework [8]. It builds on the architecture
defined for conventional presence like privacy mechanisms, security
considerations, watcher information or authorization data. The
location presence event package however considers location data
specific requirements regarding subscription handling, location data
sources, location data format and location data aggregation.
2. Definitions
This document uses the terms as defined in RFC2778 [9] and RFC3856
[4].
Additionally, the following terms are defined and/or additionally
clarified:
Location Presence Agent (LPA): The LPA is a Presence Agent (PA) for
location data that is co-located with the Presence User Agent
(PUA) in the user's mobile terminal. A PA that is co-located with
a PUA is also referred to as Edge Presence Server in [4]. It is
the task of the LPA to process SUBSCRIBE requests for location
presence data and to provide location information in NOTIFY
messages.
Location Presence Data Aggregator (LPDA): The LPDA aggregates
location presence data from different location data sources. The
LPDA is a Presence Server acting as a state agent that is not co-
located with the PUA. The LPDA may act as a subscriber and send
Pailer Expires September 21, 2007 [Page 7]
Internet-Draft Locpres Event Package March 2007
SUBSCRIBE requests to several location data sources, in particular
towards a LPA.
3. Relation to SIP Presence RFC 3856
The location presence event package is a SIP event package according
to RFC 3265 [3] that integrates location enabler with SIP presence
specified in RFC 3856 [4]. A location enabler is any kind of
positioning method that allows to query the geographical location of
a user's terminal. This specification identifies data about the
physical presence at a certain place to be a specialized form of
general presence information and refers to it as 'location presence
data'. Location presence data has the same requirements regarding
authorization, authentication and security as conventional presence.
It is the intention of this specification to extend RFC 3856 [4]
rather than to define a separate presence system. In particular it
is assumed that authorization of location presence subscriptions uses
the same framework and infrastructure as conventional presence.
Location presence data is however sufficiently different from
conventional presence in order to justify the specification in a
location presence event package. There are several reasons for that.
First location services usually target mobile terminals. It is the
goal of this specification to restrict location presence data formats
to a complexity that can be handled by mobile terminals with
restricted computing resources and limited battery capacity. This
specification extends conventional presence by defining location
presence data content formats.
Second it is of utmost importance to limit the use of wireless access
capacity to the absolute minimum. A subscriber SHOULD avoid to poll
a presentity for location presence data change. A notifier SHOULD
avoid to flood the network with location presence data. The location
presence data event package extends conventional presence by
specifying a filter document format that allows a systematic control
of notification rates.
Third notification rates can only be controlled effectively at the
source of location presence data. Thus subscriptions including
filter criteria have to be routed to the PA in control. In case of a
LPA that is co-located with the PUA, the filters are executed in the
mobile terminal. This means that the routing of location presence
subscriptions will most probably be different from routing of
subscriptions for conventional presence. By specifying an own event
package name, subscriptions and notifications for location presence
data can be routed independently of conventional presence.
Pailer Expires September 21, 2007 [Page 8]
Internet-Draft Locpres Event Package March 2007
4. Overview of Operation
A subscriber that wants to get notifications about the location
presence of a presentity, sends a SUBSCRIBE request to the
presentity. The Request-URI of the SUBSCRIBE requests identifies the
presentity by its SIP URI, SIPS URI or presence (pres) URI. The
SUBSCRIBE request may also carry a filter document in its body, that
describes, when a location presence notification should be sent. The
request is routed to a presence agent that is acting on behalf of the
presentity. This specification defines two dedicated presence
agents. The LPA is co-located with the PUA in order to accommodate
positioning methods built into the terminal (e.g. a GPS module).
LPDA is used to aggregate location data that originates from
different positioning methods.
The presence agent first authenticates the subscription, then
authorizes it. It is expected that the same authorization mechanism
like for conventional presence is used. If authorized, a 200 OK
response is returned. If authorization could not be obtained at this
time, the subscription is considered "pending", and a 202 response is
returned. In both cases, the PA sends an immediate NOTIFY message
containing the location presence state of the presentity and of the
subscription. Location presence data is transported in a PIDF-LO
document [10], that may be empty in the case of a pending
subscription or may contain some bogus information in order to
protect the privacy of the presentity.
The presence agent will send NOTIFY messages when the user's location
changes sufficiently to trigger a location presence data update.
Changes in the state of the subscription itself can also trigger
NOTIFY requests; that state is carried in the Subscription-State
header field of the NOTIFY, and would typically indicate whether the
subscription is active, pending or terminated.
The initial SUBSCRIBE message establishes a "dialog" with the
presence agent. The subscription persists for a duration that is
negotiated as part of the initial SUBSCRIBE. The subscriber will
need to refresh the subscription before its expiration, if he wishes
to retain the subscription. This is accomplished by sending a
SUBSCRIBE refresh within the same dialog established by the initial
SUBSCRIBE.
The subscriber can terminate the subscription by sending a SUBSCRIBE
with an Expires header field value of zero. This causes an immediate
termination of the subscription. A NOTIFY request is then generated
by the presence agent with the current location. An initial
SUBSCRIBE with an Expires value of zero can be used as a one-time
location fetch.
Pailer Expires September 21, 2007 [Page 9]
Internet-Draft Locpres Event Package March 2007
The presence agent can terminate the subscription at any time by
sending a NOTIFY request with a Subscription-State header field
indicating that the subscription has been terminated.
5. Location Presence Event Package
This document specifies the Location Presence SIP event package
according to RFC 3265 [3]. [3] defines a SIP extension framework for
subscribing to, and receiving notifications of, events. It is the
task of a specific event package to define the concrete events on top
of this generic SIP event framework. This section defines the
specific part of the Location Presence event package as required in
[3].
5.1. Event Package Name
The name of this package is 'locpres'. As specified in [3], the
package name is used in the Event header field of SUBSCRIBE and
NOTIFY requests.
5.2. Event Package Parameters
The Location Presence event package does not define any additional
parameters.
5.3. SUBSCRIBE Bodies
A SUBSCRIBE request in the location presence event package MAY
contain a body. The request-URI, which identifies the presentity,
combined with the event package name 'locpres' is sufficient for SIP
request routing.
A subscription for location presence with an empty body is equivalent
to a request for the current location of the presentity. The
notifier MAY answer this request, depending on privacy policies, with
a NOTIFY message, containing the current position of the presentity.
If a subscriber wants to control the conditions, when a notification
is sent by the notifier, it MAY add a filter document to the
SUBSCRIBE body. The default format for filter documents complying to
this specification is 'application/
location-presence-delta-filter+xml' (see Appendix A) and all
notifiers complying to this specification MUST be able to process
such filters.
The notifier MAY provide a list of acceptable filter documents by
means not specified in this document. A subscriber may for example
Pailer Expires September 21, 2007 [Page 10]
Internet-Draft Locpres Event Package March 2007
follow a URL given in an 'xlink:href' attribute to download a 'gml:
extentOf' description of an area. If such a provided 'gml:Polygon'
element contains a 'gml:id' attribute, this 'gml:id' attribute SHOULD
be sent with the filter document. If the provided 'gml:Polygon'
element contains a 'gml:name' element this 'gml:name' element SHOULD
be sent with the filter document.
An initial SUBSCRIBE request establishes a SIP dialog with the PA.
Subsequent SUBSCRIBE messages may be sent by the subscriber to
refresh a subscription. These SUBSCRIBE refreshes MAY have an empty
body without invalidating the filter document sent in the initial
SUBSCRIBE. A subscriber MUST NOT change a filter specification in a
subsequent SUBSCRIBE.
5.3.1. SUBSCRIBE Body examples
This section shows XML instance documents of typical SUBSCRIBE
bodies.
The following XML instance document is an example of a subscription
that specifies a movement filter. The presentity should only send
out notification events, if the current location differs by 5 meters
horizontally or vertically compared to the last notification.
5
5
Pailer Expires September 21, 2007 [Page 11]
Internet-Draft Locpres Event Package March 2007
The following XML instance document is an example of a subscription
that specifies a containment filter. The presentity should only send
out notification events on enter or exit of the specified area.
myOffice
48.222761 16.369345
48.222518 16.371018
48.221049 16.369951
48.220977 16.369135
48.222761 16.369345
The following XML instance document is an example of a subscription
that specifies a containment filter. The presentity should only send
out notification events on enter or exit of the area referenced by an
xlink.
Pailer Expires September 21, 2007 [Page 12]
Internet-Draft Locpres Event Package March 2007
5.4. Subscription Duration
Notifications for locations presence are controlled by location
presence filter documents in the body of the SUBSCRIBE message. A
NOTIFY message is sent, when a trigger condition of the filter is
met, e.g. if a presentity has moved a specified distance in
horizontal or vertical direction, if a presentity has exceeded a
specified velocity, or if a presentity enters/exits a certain area.
According to [3] the subscriber MAY specify a subscription expiration
time in the Expires header of the SUBSCRIBE message. If no Expires
header is present in the SUBSCRIBE message, the following default
values MUST be used:
o if the SUBSCRIBE message contains a valid location presence filter
document, the default expiration is 3600 seconds.
o if the SUBSCRIBER message does not contain a valid location
presence filter document, the default expiration time is 0
seconds.
5.5. NOTIFY Bodies
The body of a notification of the location presence event package
contains a presence document. This document contains the
geographical data describing the location presence of the presentity
that the watcher subscribed to. All subscribers and notifiers MUST
support the "application/location-presence-pidf+xml" presence data
format as described in this document. The subscribe request MAY
contain an Accept header field. If no such header field is present,
it has a default value of "application/location-presence-pidf+xml".
If the header field is present, it MUST include "application/
location-presence-pidf+xml", and MAY include any other types capable
of representing location presence.
The content of presence information data containing location
information is further specified as a PIDF Location Object (PIDF-LO)
in [10]. PIDF-LO refers to the Geography Markup Language (GML) 3.0
[14] for coding location information and in particular to the GML
'feature.xsd' XML schema. GML is a thorough and versatile system for
modeling all manner of geographic object types, topologies, metadata,
coordinate reference systems and units of measurement. Since the
publication of the PIDF-LO specification, the Open Geospatiale
Consortium has published GML version 3.1 [11] that deprecates some
elements used in PIDF-LO.
The target system for a location presence implementation is most
likely a mobile terminal. In order to reduce the complexity of
Pailer Expires September 21, 2007 [Page 13]
Internet-Draft Locpres Event Package March 2007
implementing a notifier complying to this location presence event
package specification, a notifier is REQUIRED to implement the
restrictions and updates to the original PIDF-LO specification as
follows:
o The implementation MUST use GML 3.1 [11] for PIDF-LO locations.
o Locations in GML MUST be encoded either as a 'gml:position'
element for point geometries or a 'gml:extentOf' element for
surface geometries. The 'gml:position' or 'gml:extentOf' elements
MAY refer to the geometry elements by giving an URL in an 'xlink:
href' attribute.
o The implementation MUST use either the GML 3.1 geometry elements
'gml:Point' or 'gml:Polygon' for encoding locations.
o The 'gml:Polygon' geometry MUST have not more than 4 unique
points, therefore having not more than 5 points in total, building
a general quadrangle. The points MUST be encoded as 'gml:pos'
elements contained in a 'gml:LinearRing' element inside a 'gml:
exterior' element.
o The location presence notifier MUST set the 'srsName' attribute of
the 'gml:Point' or the 'gml:Polygon' geometry to
'urn:ogc:def:crs:EPSG::4326' [15]. The European Petroleum Survey
Group (EPSG) geodetic parameter dataset [16] specifies coordinate
reference system (CRS) definitions that describe geographical
positions unambiguously. 'EPSG:4326' is a common geographic
projection that refers to WGS84 (latitude, longitude) coordinates
in degrees with Greenwich as the central meridian. Latitude is an
angular measurement ranging from 0o at the Equator to +90o at the
north pole and -90o at the south pole. Longitude is given as an
angular measurement ranging from 0o at the central meridian to
+180o eastward and -180o westward. Geographical coordinates MUST
be encoded in 'gml:pos' elements using WGS84 notation (latitude
followed by longitude) and the unit of measurement MUST be decimal
degrees.
o The 'gml:Point' or the 'gml:Polygon' MAY contain a 'gml:id'
attribute. If present, the 'gml:id' value MUST be unique for the
presentity identified by the entity attribute of the 'presence'
element.
o The 'gml:Point' or the 'gml:Polygon' MAY contain a 'gml:name'
element.
The notifier MUST indicate presence at a location in one of the
following formats:
Pailer Expires September 21, 2007 [Page 14]
Internet-Draft Locpres Event Package March 2007
o The position is given directly in a PIDF-LO 'location-info'
element in form of a 'gml:position' or a 'gml:extendOf' element.
The 'location-info' element MAY be empty in case the presentity
does not want to reveal its position.
o The position is given in a PIDF-LO 'location-info' element,
containing a 'pidfResource' element defined in Appendix A.2.1 that
lists a set of 'containment' status elements . Each containment
element MUST contain a 'gml:position' or a 'gml:extendOf' element
as described above.
A notifier MUST use 'containment' status elements to encode location
presence, if the subscriber provided an 'application/
location-presence-delta-filter+xml' filter document containing an
'enterOrExit' element.
A notifier that wants to aggregate location data that was acquired
from different sources MUST add a separate 'tuple' element to the
presence information document for each location data set. The
PIDF-LO 'geopriv' element in each tuple MUST use a PIDF-LO 'method'
element for each location and the positioning methods MUST NOT be the
same for any tuple.
A location presence event package notifier MAY use location encoding
schemes other than specified above, but the subscriber MUST request
such a format explicitly in an Accept header.
A notifier that does not want to reveal its location to the
subscriber MAY send an empty PIDF-LO 'location-info' element.
Further versions of this specification may refer to the documents
[17] and [18] regarding restrictions and interoperability
considerations for the use of GML inside PIDF-LO documents. [17]
for example defines its own 'Circle' element (a center point and a
radius) that is missing in the basic feature.xsd schema of GML.
5.5.1. NOTIFY body examples
This section shows XML instance documents of typical NOTIFY bodies.
Pailer Expires September 21, 2007 [Page 15]
Internet-Draft Locpres Event Package March 2007
The following XML instance document is an example of a notification
that encodes a PIDF-LO location in a GML 3.1 point geometry. The GPS
coordinates given in the 'pos' element are for Vienna, Austria.
48.208481 16.372601
false
GPS
Pailer Expires September 21, 2007 [Page 16]
Internet-Draft Locpres Event Package March 2007
The following XML instance document is an example of a notification
that encodes a PIDF-LO location in GML 3.1. The actual geometry
element is linked by an 'xlink:href' attribute.
false
Pailer Expires September 21, 2007 [Page 17]
Internet-Draft Locpres Event Package March 2007
The following XML instance document is an example of a notification
that encodes a PIDF-LO location in a GML 3.1 polygon geometry.
myOffice
48.222761 16.369345
48.222518 16.371018
48.221049 16.369951
48.220977 16.369135
48.222761 16.369345
false
The following XML instance document is an example of a notification
that encodes a PIDF-LO location as a set of containment status
elements.
Pailer Expires September 21, 2007 [Page 18]
Internet-Draft Locpres Event Package March 2007
myOffice
48.222761 16.369345
48.222518 16.371018
48.221049 16.369951
48.220977 16.369135
48.222761 16.369345
false
Pailer Expires September 21, 2007 [Page 19]
Internet-Draft Locpres Event Package March 2007
The following XML instance document is an example of an empty
notification.
The following XML instance document is an example of a notification
that aggregates location data from a GPS module in the terminal and
the location of a wireless cell, where the terminal is booked in.
Pailer Expires September 21, 2007 [Page 20]
Internet-Draft Locpres Event Package March 2007
48.208481 16.372601
GPS
false
48.207741 16.371378
Cell
false
Pailer Expires September 21, 2007 [Page 21]
Internet-Draft Locpres Event Package March 2007
5.6. Notifier processing of SUBSCRIBE requests
The processing rules specified in section 6.6 of RFC 3856 [4], in
particular regarding Authentication and Authorization, apply also for
the location presence event package.
5.7. Notifier generation of NOTIFY requests
A notifier SHOULD check the subscriber's authorization, before
sending location presence notifications.
The location presence event package specifies location filters , that
MAY be used by the notifier to control the rate of notifications. It
is the general idea of this document to reduce the number of NOTIFY
messages to the necessary amount instead of using less scalable
techniques like flooding or polling. If no filter document is passed
with a subscription, the notifier SHOULD answer with at least one
notification, containing the current position of the presentity. It
is however the notifier's own decision when to send NOTIFY messages
and what content to include in the NOTIFY body.
A Location Presence Agent (LPA) is co-located with the Presence User
Agent (PUA) and therefore has direct access to any positioning
mechanism that is integrated in the terminal that runs the PUA and
the LPA (e.g. a GPS module). A LPA SHOULD be used to generate
location presence events that use data from a terminal built-in
positioning mechanism. Thus filter documents can effectively be used
to reduce the rate of notifications.
A notifier that does not want to reveal its location to the
subscriber MAY send an empty PIDF-LO 'location-info' element.
A notifier that wants to send a fake notification MAY send a
'containment' element with the containment status 'undefined'.
A notifier MAY send a partial containment notification, meaning that
the containment state is not listed for all requested areas.
5.8. Subscriber processing of NOTIFY requests
This document does not specify any additional processing requirements
for NOTIFY requests at the subscriber.
5.9. Handling of forked requests
Like RFC 3856 [4] this specification only allows a single dialog to
be constructed as a result of emitting an initial SUBSCRIBE request.
This guarantees that only a single PA is generating notifications for
Pailer Expires September 21, 2007 [Page 22]
Internet-Draft Locpres Event Package March 2007
a particular subscription to a particular presentity.
This specification defines a Location Presence Data Aggregator (LPDA)
that acts as a Presence Agent (PA) on behalf of the presentity. The
LPDA aggregates location presence data from different location data
sources.
5.10. Rate of notifications
A location presence event notifier SHOULD NOT generate notifications
for a single presentity at a rate of more than once every 5 seconds.
5.11. State Agents
A Presence Server as specified in RFC 3856 [4] is a PA that is not
co-located with a PUA and acts as a state agent, by aggregating
presence information from different PUA into one presence document.
This document specifies a Location Presence Data Aggregator (LPDA)
that acts as a Presence Server for location presence data. The LPDA
aggregates location presence data from different sources. A LPDA
MUST only aggregate location data from different positioning methods
and MUST indicate the positioning method in an PIDF-LO 'method'
element.
An initial SUBSCRIBE request towards the LPDA will establish a dialog
between the LPDA and the subscriber. If the LPDA wants to retrieve
location presence data from a LPA, it has to establish a another
dialog by sending a new SUBSCRIBE to the LPA. Section 6.1.1
'Aggregation, Authentication, and Authorization' for state agents in
RFC 3856 [4] also applies for this document.
5.12. Use of URIs to Retrieve State
A 'xlink:href' attribute in a 'gml:extentOf' element MAY be used in
subscription filters and in notifications, instead of giving a list
of coordinates that form a polygon.
Using 'xlink:href' references reduces message size and may be used to
increase privacy, if the given link is not publicly accessible.
Furthermore the subscriber may not be interested in the exact
location of the presentity, but rather in the logical containment
state regarding the referenced area.
Pailer Expires September 21, 2007 [Page 23]
Internet-Draft Locpres Event Package March 2007
6. Usage of Presence URIs
Presence URIs shall be processed and used as specified in RFC 3856
[4].
7. Example Message Flow
The examples in this sections illustrate the usage of the location
presence event package.
When the value of the Content-Length header field is "..." this means
that the value should be whatever the computed length of the body is.
The following example flow shows a simple location presence fetch
operation.
Watcher LPA
| F1 SUBSCRIBE |
|----------------->|
| F2 200 OK |
|<-----------------|
| |
| F3 NOTIFY |
|<-----------------|
| F4 200 OK |
|----------------->|
F1 SUBSCRIBE watcher -> LPA
SUBSCRIBE sip:marco@tuwien.ac.at SIP/2.0
Via: SIP/2.0/TCP watcherhost.a1.net;branch=z9hG4bK-8529-1-0
From: "Rudolf" ;tag=1
To: "Marco"
Call-ID: 1-8529@watcherhost.a1.net
CSeq: 1 SUBSCRIBE
Contact: sip:rudolf@watcherhost.a1.net
Max-Forwards: 70
Subject: Location Presence Test
Event: locpres
Accept: application/location-presence-pidf+xml
Expires: 0
Content-Length: 0
F2 200 OK LPA -> watcher
Pailer Expires September 21, 2007 [Page 24]
Internet-Draft Locpres Event Package March 2007
SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.a1.net;branch=z9hG4bK-8529-1-0
From: "Rudolf" ;tag=1
To: "Marco" ;tag=1
Call-ID: 1-8529@watcherhost.a1.net
CSeq: 1 SUBSCRIBE
Event: locpres
Expires: 0
Contact:
Content-Length: 0
F3 NOTIFY LPA -> watcher
NOTIFY sip:rudolf@watcherhost.a1.net SIP/2.0
Via: SIP/2.0/TCP tuwien.ac.at
From: "Marco" ;tag=1
To: "Rudolf" ;tag=1
Call-ID: 1-8529@watcherhost.a1.net
CSeq: 1 NOTIFY
Event: locpres
Subscription-State: terminated;reason=timeout
Contact:
Content-Type: application/location-presence-pidf+xml
Content-Length: ...
48.208481 16.372601
false
Pailer Expires September 21, 2007 [Page 25]
Internet-Draft Locpres Event Package March 2007
GPS
F4 200 OK watcher -> LPA
SIP/2.0 200 OK
Via: SIP/2.0/TCP tuwien.ac.at
From: "Marco" ;tag=1
To: "Rudolf" ;tag=1
Call-ID: 1-8529@watcherhost.a1.net
CSeq: 1 NOTIFY
Content-Length: 0
The following example message flow shows a subscription for location
presence containment state. Notice that the actual geometry of the
watched region is only refered to by a URL.
Watcher LPA
| F1 SUBSCRIBE |
|----------------->|
| F2 200 OK |
|<-----------------|
| |
| F3 NOTIFY |
|<-----------------|
| F4 200 OK |
|----------------->|
F1 SUBSCRIBE watcher -> LPA
SUBSCRIBE sip:marco@tuwien.ac.at SIP/2.0
Via: SIP/2.0/TCP watcherhost.a1.net;branch=z9hG4bK-22943-1-0
From: "Rudolf" ;tag=1
To: "Marco"
Call-ID: 1-22943@watcherhost.a1.net
CSeq: 1 SUBSCRIBE
Contact: sip:rudolf@watcherhost.a1.net
Max-Forwards: 70
Subject: Location Presence Test
Event: locpres
Accept: application/location-presence-pidf+xml
Expires: 0
Pailer Expires September 21, 2007 [Page 26]
Internet-Draft Locpres Event Package March 2007
Content-Length: ...
F2 200 OK LPA -> watcher
SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.a1.net;branch=z9hG4bK-22943-1-0
From: "Rudolf" ;tag=1
To: "Marco" ;tag=1
Call-ID: 1-22943@watcherhost.a1.net
CSeq: 1 SUBSCRIBE
Event: locpres
Expires: 0
Contact:
Content-Length: 0
F3 NOTIFY LPA -> watcher
NOTIFY sip:rudolf@watcherhost.a1.net SIP/2.0
Via: SIP/2.0/TCP tuwien.ac.at
From: "Marco" ;tag=1
To: "Rudolf" ;tag=1
Call-ID: 1-22943@watcherhost.a1.net
CSeq: 1 NOTIFY
Event: locpres
Subscription-State: terminated;reason=timeout
Contact:
Content-Type: application/location-presence-pidf+xml
Content-Length: ...
false
F4 200 OK watcher -> LPA
SIP/2.0 200 OK
Via: SIP/2.0/TCP tuwien.ac.at
From: "Marco" ;tag=1
To: "Rudolf" ;tag=1
Call-ID: 1-22943@watcherhost.a1.net
CSeq: 1 NOTIFY
Content-Length: 0
8. Security Considerations
Location information provides considerable value to information and
communication services. On the other hand, users are concerned about
revealing their position data to others, especially to un-trusted
third party applications. Furthermore, most countries have legal
restrictions that regulate processing of personal data and the
protection of privacy in electronic communications. It is of utmost
importance that the users can control who gets access to their
location data and that the transport in the network of such sensitive
data is protected by strong security mechanisms.
Pailer Expires September 21, 2007 [Page 28]
Internet-Draft Locpres Event Package March 2007
These security and privacy considerations are covered by the general
presence specification and any implementation of this document MUST
follow the security considerations in RFC 3856 [4].
9. IANA Considerations
9.1. Location Presence Event Package
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [3]. The following is
the information required for such a registration:
Package Name: locpres
Published Document: please assign
Person to Contact: Rudolf Pailer, r.pailer@a1.net
9.2. MIME Registration for application/location-presence-pidf+xml
MIME media type name: application
MIME subtype name: application/location-presence-pidf+xml
Required parameters: none.
Optional parameters: none.
Encoding considerations: Same as for XML.
Security considerations: see Section 8
Applications which use this media: The application/ location-
presence-pidf+xml application subtype supports the exchange of
location information inside presence documents.
Additional Information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
Pailer Expires September 21, 2007 [Page 29]
Internet-Draft Locpres Event Package March 2007
9.3. MIME Registration for application/
location-presence-delta-filter+xml
[Note to the editor: this application type is an updated version of
application/location-delta-filter+xml defined in [19]].
MIME media type name: application
MIME subtype name: application/location-presence-delta-filter+xml
Required parameters: none.
Optional parameters: none.
Encoding considerations: Same as for XML.
Security considerations: see Section 8
Applications which use this media: The application/ location-
presence-delta-filter+xml application subtype supports the exchange
of filters to throttle asynchronous notifications of location
information.
Additional Information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-presence-filter
[Note to the editor: this schema URN refers to an updated version of
the filter schema defined in [19]].
This section registers a new XML namespace, as per the guidelines in
[12].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:location-presence-filter.
Registrant Contact: IETF, GEOPRIV working group,
, as delegated by the IESG .
Pailer Expires September 21, 2007 [Page 30]
Internet-Draft Locpres Event Package March 2007
XML:
BEGIN
Location Presence Filter Namespace
Namespace for PIDF-LO Location Presence Filters
urn:ietf:params:xml:ns:location-presence-filter
See RFCXXXX.
END
9.5. Schema Registration For location-presence-filter
[Note to the editor: this schema is an updated version of the filter
schema defined in [19]].
This specification registers a schema, as per the guidelines in [12].
URI: please assign
Registrant Contact: IETF, GEOPRIV working group,
, as delegated by the IESG .
XML: see Appendix A.1.1
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:containment
[Note to the editor: this schema URN was originally defined in [19]].
This section registers a new XML namespace, as per the guidelines in
[12].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:geopriv10:containment.
Pailer Expires September 21, 2007 [Page 31]
Internet-Draft Locpres Event Package March 2007
Registrant Contact: IETF, GEOPRIV working group,
, as delegated by the IESG .
XML:
BEGIN
PIDF-LO Location Containment Namespace
Namespace for PIDF-LO location containment elements
urn:ietf:params:xml:ns:pidf:geopriv10:containment
See RFCXXXX.
END
9.7. Schema Registration For containment
[Note to the editor: this schema was originally defined in [19]].
This specification registers a schema, as per the guidelines in [12].
URI: please assign
Registrant Contact: IETF, GEOPRIV working group,
, as delegated by the IESG .
XML: see Appendix A.2.1
10. Contributors
The following people have contributed to this work:
Florian WEGSCHEIDER
mobilkom austria AG
Obere Doneustrasse 29
A-1020 Vienna, Austria
mailto:f.wegscheider@mobilkom.at
Sandford BESSLER
Pailer Expires September 21, 2007 [Page 32]
Internet-Draft Locpres Event Package March 2007
Telecommunications Research Center Vienna (ftw.)
Obere Donaustrasse 29
Donau City Strasse 1
A-1220 Vienna, Austria
mailto:bessler@ftw.at
Joachim FABINI
Institute of Broadband Communications
Vienna University of Technology
Favoritenstrasse 9/E388
A-1040 Vienna, Austria
mailto:Joachim.Fabini@tuwien.ac.at
Marco HAPPENHOFER
Institute of Broadband Communications
Vienna University of Technology
Favoritenstrasse 9/E388
A-1040 Vienna, Austria
mailto:Marco.Happenhofer@tuwien.ac.at
11. Acknowledgements
Part of this work has been performed within the project "SIMS-
Services in the IP Multimedia Subsystem" at the Telecommunications
Research Center Vienna (http://www.ftw.at) and has been funded in the
framework of the Austrian Kplus Competence Center Programme.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[5] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", RFC 4079, July 2005.
Pailer Expires September 21, 2007 [Page 33]
Internet-Draft Locpres Event Package March 2007
[6] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information
Data Format (PIDF)", RFC 4480, July 2006.
[7] 3GPP, "Location Services (LCS); Service description; Stage 1",
3GPP TS 22.071 3.5.0, March 2004.
[8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[10] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[11] "OpenGIS Geography Markup Language (GML) Implementation
Specification, OGC 03-105r1", 02 2004.
[12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[13] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
12.2. Informative References
[14] "OpenGIS Geography Markup Language (GML) Encoding
Specification, OGC 02-023r4", 12 2002.
[15] OGC, "Definition identifier URNs in OGC namespace, OGC Best
Practices Paper 06-023r1", 08 2006.
[16] EPSG, "EPSG Geodetic Parameter Dataset, version 6.11_2",
10 2006.
[17] Thomson, M., "Geodetic Shapes for the Representation of
Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03
(work in progress), December 2006.
[18] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-05 (work in progress),
October 2006.
[19] Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in PIDF-LO",
Pailer Expires September 21, 2007 [Page 34]
Internet-Draft Locpres Event Package March 2007
draft-mahy-geopriv-loc-filters-01 (work in progress),
March 2006.
Appendix A. Filtering and Reporting Location Notifications in PIDF-LO
documents (Normative)
This specification uses XML schemas proposed in the Internet Draft
[19] that has expired in September 2006, but can still be seen at 'ht
tp://www3.ietf.org/proceedings/06jul/IDs/
draft-ietf-geopriv-loc-filters-00.txt'. In order to remove the
dependency on an expired draft, this appendix lists the used XML
schemas.
A.1. Location Presence Filter Format
The granularity of notifications necessary for various geographic
location applications varies dramatically. The subscriber should be
able to get asynchronous notifications with appropriate granularity
and accuracy, without having to poll or flood the network with
notifications which are not important to the application.
Notifications should only happen when the notification would be
considered an interesting event to the subscriber. This section
defines an XML filter format to describe interesting conditions or
events.
This document also defines a MIME type for this location filter
format: application/location-presence-filter+xml.
This document defines the following as an initial list of Interesting
Events:
1. the resource moves more than a specific distance horizontally or
vertically since the last notification
2. the resource exceeds a specific speed
3. the resource enters or exits one or more GML objects (for
example, a polygon) included or referenced in the filter.
The filter format starts with a top-level XML element called
"", which contains one or more filter events. The
semantics of multiple elements inside a location-filter is a logical
OR. In other words, if any of the individual filter events occurs,
the event satisfies the location-filter and triggers a notification.
The "movedHoriz" and "movedVert" filter events each indicate a
minimum horizontal motion or vertical distance (respectively) that
Pailer Expires September 21, 2007 [Page 35]
Internet-Draft Locpres Event Package March 2007
the resource must have moved from the location of the resource when
the last notification was sent in order to trigger this event. The
default unit of measurement for these events is meters.
Similarly, the "speedExceeds" filter event indicates a minimum
horizontal speed of the resource before the "speedExceeds" event is
triggered. The default unit of measurement for these events is
meters per second.
The "valueChanges" filter event contains a string which is
interpreted as an XPath expression evaluated within the context of
the location-info element of the PIDF-LO document which would be
generated by the notification. The XPath expression MUST evaluate to
only a single Xpath node.
Finally, the "enterOrExit" filter event is satisfied when the
resource enters or exits a specified location. The original draft
types the "enterOrExit" element as a GML feature. This was
considered to be too restrictive and complicated, as it requires from
the subscriber and the notifier to agree on a not further specified
GML application schema. The "enterOrExit" element in this document
may contain any XML element. For a subscription with the content-
type 'application/location-presence-filter+xml', the "enterOrExit"
element MUST contain a 'gml:extentOf' element. In most cases
subscribers that use location filters based on "enterOrExit" events
are especially interested in the resource's relationship to those
locations. Consequently, the notifier SHOULD include a "containment"
element for each location mentioned in the location-filter which has
changed its containment properties with respect to the resource since
the last notification.
A.1.1. Location Presence Filter Schema
The following XML document defines the location presence filter
schema.
Pailer Expires September 21, 2007 [Page 36]
Internet-Draft Locpres Event Package March 2007
Pailer Expires September 21, 2007 [Page 37]
Internet-Draft Locpres Event Package March 2007
A.2. Containment
This section defines a schema for describing the resource's location
relative to a region or list of regions which might contain the
resource. (These regions can be defined dynamically in an
"enterOrExit" element in a subscription filter, or defined on the
notifier using some out-of-band mechanism.) The "pidfResource"
element is placed inside the location-info element in a PIDF-LO
document. The pidfResource element can contain zero or more
"containment" elements. Each containment element has a GML Feature
sub-element (of type "FeaturePropertyType") and a mandatory attribute
which specifies if the PIDF resource is inside or outside of the
feature, or if the position of the resource with respect to the
region or region list is undefined.
If the subscriber is not authorized to know the relative position,
the notifier MUST NOT reveal this private information. The
RECOMMENDED way to prevent the subscriber from seeing private
location data of this type is to return a containment element whose
position attribute is "undefined". Note that in some cases, the
containment information may be more interesting than the actual raw
location. It is not necessary to convey a concrete geo location in a
PIDF-LO if the subscriber is only interested in or authorized to see
the containment status.
A.2.1. Containment Schema
Pailer Expires September 21, 2007 [Page 38]
Internet-Draft Locpres Event Package March 2007
The following XML document defines the containment schema.
Author's Address
Rudolf Pailer
mobilkom austria AG
Obere Donaustrasse 29
Vienna A-1020
Austria
Phone: +43-664-3316983
Email: r.pailer@a1.net
Pailer Expires September 21, 2007 [Page 39]
Internet-Draft Locpres Event Package March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Pailer Expires September 21, 2007 [Page 40]