GEOPRIV R. Mahy Internet-Draft Individual Intended status: Standards Track B. Rosen Expires: April 29, 2010 NeuStar H. Tschofenig Nokia Siemens Networks October 26, 2009 Filtering Location Notifications in the Session Initiation Protocol (SIP) draft-ietf-geopriv-loc-filters-07.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Mahy, et al. Expires April 29, 2010 [Page 1] Internet-Draft Location Filters October 2009 Abstract This document describes filters that limit asynchronous location notifications to compelling events, designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 7 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 11 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16 6.2. Schema Registration For location-filter . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informational References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Mahy, et al. Expires April 29, 2010 [Page 2] Internet-Draft Location Filters October 2009 1. Introduction Conveying location information encapsulated with a PIDF-LO [RFC4119] document within SIP is described in [I-D.ietf-sipcore-location-conveyance]. An alternative signaling approach, which uses asynchronous communication, is available with the SIP event notification mechanisms (see RFC 3265 [RFC3265]) and is used by this document. Unfortunately, it is more complex since many forms of location are measured as a continuous gradient. Unlike notifications using discret quantities, it is difficult to know when a change in location is large enough to warrant a notification. SIP events [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that allows the number of notifications to be reduced. The mechanism described in this document defines an extension to RFC 4661 [RFC4661], which limits location notification to events that are of relevance to the subscriber. These filters persist until they are changed with a replacement filter. The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without having to issue a large number of notifications that are not important to the application. This document defines a few new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering: 1. the Device moves more than a specified distance since the last notification 2. the Device exceeds a specified speed 3. the Device enters or exits a region (described by a circle or a polygon) 4. one or more of the values of the specified address labels have changed for the location of the Device. For example, the value of the civic address element has changed from 'California' to 'Nevada'. 5. the type of location information being requested. 6. the rate at which location information delivery is desired. This document builds on the presence event package [RFC3856], i.e. an existing event package for communicating location information inside the PIDF-LO. Mahy, et al. Expires April 29, 2010 [Page 3] Internet-Draft Location Filters October 2009 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document reuses terminology from [I-D.ietf-geopriv-arch]. Mahy, et al. Expires April 29, 2010 [Page 4] Internet-Draft Location Filters October 2009 3. Filter Definitions This specification builds on top of a number of other specifications, as noted in Section 1. In order to reduce the number of options (and thereby increase the chance of interoperability problems), only the functionality described in this document MUST be implemented. Only the functionality of [RFC4661] listed in the sub-sections below MUST be implemented, namely the (see Section 3.3 of [RFC4661]), the (Section 3.4 of [RFC4661]), and the (Section 3.6 of [RFC4661] excluding the functionality of the and element). 3.1. Movement The element with a value in meters indicates the minimum distance that the resource must have moved from the location of the resource when the last notification was sent in order to trigger this event. The distance is measured in meters absolutely from the point of last notification rather than in terms of cumulative motion. The element MUST only appear once as a child element of . 300 Figure 1: Movement Filter Example 3.2. Speed Changes Speed changes can be filtered with the help of RFC 4661 and the functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which extends the PIDF-LO with support for spatial orientation, speed, heading, and acceleration. The value of in [I-D.singh-geopriv-pidf-lo-dynamic] is defined in meters per second. This is the only supported measure and hence the value in the 'by' attribute MUST be expressed in meters per second. Figure 2 shows an example for a trigger that fires when the speed of the Target changes by 3 meters per second. Mahy, et al. Expires April 29, 2010 [Page 5] Internet-Draft Location Filters October 2009 //dyn:speed Figure 2: Speed Change Example An implementation MUST support the functionality as shown in Figure 2 with replacing the prefix. No other variant is supported. The element comes with a few attributes but only the 'by' attribute MUST be implemented by this specification. 3.3. Element Value Changes Changes in values, for example related to civic location information, is provided by the base functionality offered with RFC 4661 utilizing the element. Figure 3 shows an example where a notification is sent when the civic address tokens A1, A2, A3, or PC change (all 4 must change in order to let the element evaluate to TRUE). Mahy, et al. Expires April 29, 2010 [Page 6] Internet-Draft Location Filters October 2009 //ca:A1 //ca:A2 //ca:A3 //ca:PC Figure 3: Speed Change Example The following example illustrates a filter that triggers when the Target's location changes from 'FR' (France) to some other country. //ca:country Figure 4: Speed Change Example (Country Change) An implementation MUST support the functionality as shown in Figure 3 with replacing the prefix. No other variant is supported. The element comes with a few attributes and the 'by', 'to' and 'from' attribute MUST be implemented by this specification. 3.4. Entering or Exiting a Region The condition is satisfied when the Target enters or exits a named 2-dimensional region described by a polygon (as defined in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section Mahy, et al. Expires April 29, 2010 [Page 7] Internet-Draft Location Filters October 2009 5.2.3 of [RFC5491]). The element MUST have contain either a polygon or a circle as a child element. More than one a polygon and/or a circle as a child element of MUST NOT occur. If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence. Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. Confidence that the location is within the region, plus confidence that the location is outside the region cannot be 100%. The total confidence depends on the confidence in the original location, which is always less than 100% (95% is recommended in [RFC5491]). The benefit of this is that notifications are naturally limited: small movements at the borders of the region do not trigger notifications. Figure 5 shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle and Figure 6 describes an area using a polygon. 42.5463 -73.2512 850.24 Figure 5: Circle Filter Example Mahy, et al. Expires April 29, 2010 [Page 8] Internet-Draft Location Filters October 2009 43.311 -73.422 43.111 -73.322 43.111 -73.222 43.311 -73.122 43.411 -73.222 43.411 -73.322 43.311 -73.422 Figure 6: Polygon Filter Example 3.5. Location Type The element MAY be included as a child element of the element and it contains a list of location information types that are requested by the subscriber. The following list describes the possible values: any: The Notifier SHOULD attempt to provide LI in all forms available to it. geodetic: The Notifier SHOULD return a location by value in the form of a geodetic location. civic: The Notifier SHOULD return a location by value in the form of a civic address. The Notifier SHOULD return the requested location type or types. The location types the LIS returns also depend on the setting of the optional "exact" attribute. If the 'exact' attribute is set to "true" then the Notifier MUST return either the requested location type or no location information. The 'exact' attribute does not apply (is ignored) for a request for a location type of "any". Mahy, et al. Expires April 29, 2010 [Page 9] Internet-Draft Location Filters October 2009 In the case of a request for specific locationType(s) and the 'exact' attribute is false, the Notifier MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type. The "SHOULD"-strength requirements on this parameter for specific location types are included to allow for soft-failover. If the element is absent, a value of "any" MUST be assumed as the default. The Notifier SHOULD provide location in the response in the same order in which they were included in the "locationType" element in the request. Indeed, the primary advantage of including specific location types in a request when the 'exact' attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a subscription for "civic" (with the 'exact' attribute set to "false") could yield any of the following location types in the response: o civic o civic, geodetic o geodetic (only if civic is not available) For the example above, if the 'exact' attribute was "true", then the only possible response is either a "civic" location or an error message. As stated above, the element MAY carry the 'exact' attribute. When the 'exact' attribute is set to "true", it indicates to the Notifier that the contents of the element MUST be strictly followed. The default value of "false" allows the Notifier the option of returning something beyond what is specified, such as a set of location URIs when only a civic location was requested. A value of "true" indicates that the Notifier MUST provide a location of the requested type or types or MUST provide an error. An example is shown in Figure 7 that utilizes the element with the 'exact' and the 'responseTime' attribute. Mahy, et al. Expires April 29, 2010 [Page 10] Internet-Draft Location Filters October 2009 geodetic Figure 7: Filter Example 3.6. Rate Control [I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP events framework defining the following three "Event" header field parameters that allow a subscriber to set a minimum, a maximum and an average rate of event notifications generated by the notifier. This document makes use of two of the parameters to accomplish functionality equivalent to the 'responseTime' attribute used in HELD [I-D.ietf-geopriv-http-location-delivery], namely "min-interval" (which specifies a minimum notification time period between two notifications, in seconds) and "max-interval" (which specifies a maximum notification time period between two notifications, in seconds.). This specification only defines the semantic for these two attributes and requires implementation of these two from the set of attributes defined in [I-D.ietf-sipcore-event-rate-control]. Whenever the time since the most recent notification exceeds the value in the "max-interval" parameter, then the current state would be sent in its entirety, just like after a subscription refresh. If complete state is not immediately available, a NOTIFY containing state (i.e. location) is generated some time between the time included in 'min-interval' and the time in 'max-interval'. An important use case for location based applications focuses on the behavior of the initial NOTIFY message(s) and the information it returns, for example in case of emergency call routing. When an initial NOTIFY is transmitted it might not include complete state. Mahy, et al. Expires April 29, 2010 [Page 11] Internet-Draft Location Filters October 2009 Subscriber Notifier |---SUBSCRIBE(1)--->| Request state subscription |<-------200--------| Acknowledge subscription |<-----NOTIFY(2)----| Return current state information |-------200(3)----->| |<-----NOTIFY(4)----| Return current state information |--------200------->| Figure 8: SUBSCRIBE/NOTIFY with Rate Control Figure 8 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1) has filters attached and contains a 'max-interval' rate control parameter. In certain situations it is important to obtain some amount of location information within a relatively short and pre-defined period of time even if the obtained location information contains a high amount of uncertainty and location information with less uncertainty at a later point in time. An example is emergency call routing where a emergency services routing proxy may need to obtain location information suitable for routing rather quickly and subsequently a Public Safety Answering Point requests location information for dispatch. To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial SUBSCRIBE contains a 'max-interval' rate control parameter (with a small value) that is in a later message updated to a more sensible value. The 'max-interval' for this first request is therefore much lower than thereafter. Updating the 'max-interval' for the subscription can be performed in the 200 response (see message 3) to the NOTIFY that contains state. Depending on the value in the 'max- interval' parameter the Notifier may create a NOTIFY message (see message 2) immediately in response to the SUBSCRIBE that might be empty in case no location information is available at this point in time. The desired location information may then arrive in the subsequent NOTIFY message (see message 4). Mahy, et al. Expires April 29, 2010 [Page 12] Internet-Draft Location Filters October 2009 4. XML Schema Mahy, et al. Expires April 29, 2010 [Page 13] Internet-Draft Location Filters October 2009 Figure 9: XML Schema Mahy, et al. Expires April 29, 2010 [Page 14] Internet-Draft Location Filters October 2009 5. Security Considerations This document builds on a number of specifications, namely o the SIP event notification mechanism, described in RFC 3265 [RFC3265], defining the SUBSCRIBE/NOTIFY messages. o the presence event package, described in RFC 3856 [RFC3856], which is a concrete instantiation of the general event notification framework. o the filter framework, described in RFC 4661 [RFC4661], to offer the ability to reduce the amount of notifications being sent. Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the XML container that carries location information. Each of these documents listed above comes with a security consideration section but the security and privacy aspects are best covered by the SIP presence event package, see Section 9 of [RFC3856], and with the GEOPRIV architectural description found in [I-D.ietf-geopriv-arch]. The functionality for uploading authorization policies and other information that limit access to location information are provided by other protocols, such Common Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or more recent work around HELD context [I-D.winterbottom-geopriv-held-context]. The functionality described in this document extends the filter framework with location specific filters. Local policies might be associated with the usage of certain filter constructs and with the amount of notifications specific filter settings might cause. Although [I-D.ietf-geopriv-policy] defines a standardized format for authorization policies but it does not define specific policies for controlling filters specifically. Mahy, et al. Expires April 29, 2010 [Page 15] Internet-Draft Location Filters October 2009 6. IANA Considerations 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter This section registers a new XML namespace, as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:location-filter Registrant Contact: IETF, GEOPRIV working group, , as delegated by the IESG . XML: BEGIN Location Filter Namespace

Namespace for PIDF-LO Location Filters

urn:ietf:params:xml:ns:location-filter

See RFCXXXX.

END 6.2. Schema Registration For location-filter This specification registers a schema, as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:location-filter Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). Mahy, et al. Expires April 29, 2010 [Page 16] Internet-Draft Location Filters October 2009 XML: The XML can be found as the sole content of Section 4. Mahy, et al. Expires April 29, 2010 [Page 17] Internet-Draft Location Filters October 2009 7. Contributors We would like to thank Martin Thomson and James Polk for their contributions to this document. Mahy, et al. Expires April 29, 2010 [Page 18] Internet-Draft Location Filters October 2009 8. Acknowledgments Thanks to Richard Barnes and Alissa Cooper, Carl Reed, Adam Roach, Allan Thomson, James Winterbottom for their comments. Mahy, et al. Expires April 29, 2010 [Page 19] Internet-Draft Location Filters October 2009 9. References 9.1. Normative References [GML] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OpenGIS OGC 02-023r4, January 2003, . [I-D.ietf-geopriv-arch] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", draft-ietf-geopriv-arch-00 (work in progress), July 2009. [I-D.ietf-sipcore-event-rate-control] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control", draft-ietf-sipcore-event-rate-control-00 (work in progress), May 2009. [I-D.singh-geopriv-pidf-lo-dynamic] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress), August 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Mahy, et al. Expires April 29, 2010 [Page 20] Internet-Draft Location Filters October 2009 Requena, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", RFC 4661, September 2006. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. 9.2. Informational References [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009. [I-D.ietf-geopriv-policy] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-21 (work in progress), July 2009. [I-D.ietf-sipcore-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sipcore-location-conveyance-01 (work in progress), July 2009. [I-D.winterbottom-geopriv-held-context] Winterbottom, J., Tschofenig, H., and M. Thomson, "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", draft-winterbottom-geopriv-held-context-05 (work in progress), October 2009. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. Mahy, et al. Expires April 29, 2010 [Page 21] Internet-Draft Location Filters October 2009 Authors' Addresses Rohan Mahy Individual Email: rohan@ekabal.com Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 US Phone: +1 724 382 1051 Email: br@brianrosen.net Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Mahy, et al. Expires April 29, 2010 [Page 22]