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]