GEOPRIV R. Mahy Internet-Draft Plantronics Intended status: Standards Track B. Rosen, Ed. Expires: January 14, 2010 NeuStar H. Tschofenig Nokia Siemens Networks July 13, 2009 A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO) draft-ietf-geopriv-loc-filters-04.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 January 14, 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 January 14, 2010 [Page 1] Internet-Draft Location Event Filters July 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". The resulting location information is conveyed in existing location formats wrapped in the Presence Information Document Format (PIDF-LO). Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 5 3.2. Changes in Speed . . . . . . . . . . . . . . . . . . . . . 5 3.3. Changes in Value . . . . . . . . . . . . . . . . . . . . . 6 3.4. Enter or Exit a Region . . . . . . . . . . . . . . . . . . 7 4. Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.1. Content-type registration for 'application/location-delta-filter+xml' . . . . . . . . . 12 7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13 7.3. Schema Registration For location-filter . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informational References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Mahy, et al. Expires January 14, 2010 [Page 2] Internet-Draft Location Event Filters July 2009 1. 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]. Mahy, et al. Expires January 14, 2010 [Page 3] Internet-Draft Location Event Filters July 2009 2. Introduction Conveying location in PIDF-LO [RFC4119] bodies is described in [I-D.ietf-sip-location-conveyance]. Asynchronous notification of location information is unfortunately 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. The mechanism described in this document defines filters as 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 section of this document defines an extension to [RFC4661]'s TriggerType element to describe interesting conditions or events. The terminal elements in this format are utilizing Geographic Markup Language (GML) [GML] data types and civic address elements. This document also defines a MIME type for this location filter format, namely 'application/location-delta-filter+xml'. This document defines the following as an initial list of events that could be interesting to a subscriber: 1. the Target moves more than a specified distance horizontally or vertically since the last notification 2. the Target exceeds a specified speed 3. the Target enters or exits one or more GML objects (for example, a set of 2-dimensional or 3-dimensional regions) included or referenced in the filter. 4. one or more of the values of the specified address labels has changed for the location of the Target (for example, the value of the civic address element has changed from 'California' to 'Nevada') Mahy, et al. Expires January 14, 2010 [Page 4] Internet-Draft Location Event Filters July 2009 3. Filter Definitions 3.1. Horizontal and Vertical Movement Changes in the position of the Target require extensions to the functionality of RFC 4661 and a simplying assumption. The former aspect refers to the need to enhance the capability to extract a value from inside an XML element, in our example from the element, which describes the user's location. Regarding the latter aspect we assume that the user's location information of any shape and uncertainty is converted into a point before the comparison regarding the movement with the previously notified location takes place. The example shown in Figure 1 references the latitude value (using the "gml:pos[1]" notation) and the 'by' attribute of the element indicates the desired change that triggers a notification to be sent. /pidf:presence/pidf:device/gp:geopriv/ gp:location-info/gml:Point/gml:pos[1] Figure 1: Movement Filter Example 3.2. Changes in Speed 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. Mahy, et al. Expires January 14, 2010 [Page 5] Internet-Draft Location Event Filters July 2009 Figure 2 shows an example for a trigger that fires when the speed of the Target changes by 20 meters per second. /pidf:presence/pidf:tuple/pidf:status/ gp:geopriv/gp:location-info/dyn:Dynamic/dyn:speed Figure 2: Speed Change Example 3.3. Changes in Value Changes in values, for example related to civic location information, can be provided by the base functionality offered with RFC 4661. Figure 3 shows an example where a notification is sent when the civic address tokens A1, A2, A3, or PC change. Mahy, et al. Expires January 14, 2010 [Page 6] Internet-Draft Location Event Filters July 2009 /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/cl:civilAddress/cl:A1 /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/cl:civilAddress/cl:A2 /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/cl:civilAddress/cl:A3 /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/ gp:location-info/cl:civilAddress/cl:PC Figure 3: Speed Change Example 3.4. Enter or Exit a Region The condition is satisfied when the Target enters or exits a named 2-dimensional or 3-dimensional region described by a polygon (as defined in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section 5.2.3 of [RFC5491]). Figure 4 and Figure 5 shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle and by a 3d polygon. Mahy, et al. Expires January 14, 2010 [Page 7] Internet-Draft Location Event Filters July 2009 42.5463 -73.2512 850.24 Figure 4: (2D) Filter Example 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 5: (3D) Filter Example Mahy, et al. Expires January 14, 2010 [Page 8] Internet-Draft Location Event Filters July 2009 4. Rate Control The throttle mechanisms [I-D.ietf-sipcore-event-rate-control] can be used to control the rate of notifications. The "throttle", "force" and "average" settings can filter notications by time. Mahy, et al. Expires January 14, 2010 [Page 9] Internet-Draft Location Event Filters July 2009 5. XML Schema Figure 6: XML Schema Mahy, et al. Expires January 14, 2010 [Page 10] Internet-Draft Location Event Filters July 2009 6. Security Considerations Location information is typically very privacy sensitive. As such, notifications MUST be encrypted and integrity protected. Additional privacy and security considerations are discussed in detail in [RFC5491]. Mahy, et al. Expires January 14, 2010 [Page 11] Internet-Draft Location Event Filters July 2009 7. IANA Considerations 7.1. Content-type registration for 'application/ location-delta-filter+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023]. MIME media type name: application MIME subtype name: location-delta-filter+xml Mandatory parameters: none Optional parameters: charset; Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2. Security considerations: See the "Security Considerations" section in this document. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] Applications which use this media type: This content type supports the exchange of filters to throttle asynchronous notifications of location information. Additional information: Magic Number: N/A File Extension: N/A Macintosh file type code: N/A Personal and email address for further information: Brian Rosen, br@brianrosen.net Mahy, et al. Expires January 14, 2010 [Page 12] Internet-Draft Location Event Filters July 2009 Intended usage: LIMITED USE Author: This specification is a work item of the IETF GEOPRIV working group, with mailing list address . Change controller: The IESG 7.2. 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: The URI for this namespace is 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 Mahy, et al. Expires January 14, 2010 [Page 13] Internet-Draft Location Event Filters July 2009 7.3. Schema Registration For location-filter This specification registers a schema, as per the guidelines in [RFC3688]. URI: please assign. Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). XML: The XML can be found as the sole content of Section 5. Mahy, et al. Expires January 14, 2010 [Page 14] Internet-Draft Location Event Filters July 2009 8. Acknowledgments Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for their comments. Mahy, et al. Expires January 14, 2010 [Page 15] Internet-Draft Location Event Filters July 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-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-06 (work in progress), June 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. [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- 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. Mahy, et al. Expires January 14, 2010 [Page 16] Internet-Draft Location Event Filters July 2009 9.2. Informational References [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-13 (work in progress), March 2009. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Mahy, et al. Expires January 14, 2010 [Page 17] Internet-Draft Location Event Filters July 2009 Authors' Addresses Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA USA Email: rohan@ekabal.com Brian Rosen (editor) 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 January 14, 2010 [Page 18]