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 15, 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.

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
2.  Introduction
3.  Filter Definitions
    3.1.  Horizontal and Vertical Movement
    3.2.  Changes in Speed
    3.3.  Changes in Value
    3.4.  Enter or Exit a Region
4.  Rate Control
5.  XML Schema
6.  Security Considerations
7.  IANA Considerations
    7.1.  Content-type registration for 'application/location-delta-filter+xml'
    7.2.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter
    7.3.  Schema Registration For location-filter
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informational References
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Introduction

Conveying location in PIDF-LO (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119] bodies is described in [I‑D.ietf‑sip‑location‑conveyance] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.). 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] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.), 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] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.)'s TriggerType element to describe interesting conditions or events. The terminal elements in this format are utilizing Geographic Markup Language (GML) (OpenGIS, “Open Geography Markup Language (GML) Implementation Specification,” January 2003.) [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 <A1> civic address element has changed from 'California' to 'Nevada')

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 <pos> 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 (Movement Filter Example) references the latitude value (using the "gml:pos[1]" notation) and the 'by' attribute of the <changed> element indicates the desired change that triggers a notification to be sent.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="pidf"
              urn="urn:ietf:params:xml:ns:pidf"/>
        <ns-binding prefix="gp"
              urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
        <ns-binding prefix="dyn"
              urn="http://www.opengis.net/gml"/>
    </ns-bindings>
    <filter id="123" uri="sip:presentity@example.com">
        <trigger>
            <changed by="100">
                /pidf:presence/pidf:device/gp:geopriv/
                 gp:location-info/gml:Point/gml:pos[1]
            </changed>
        </trigger>
    </filter>
</filter-set>

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] (Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, “Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO),” March 2010.), which extends the PIDF-LO with support for spatial orientation, speed, heading, and acceleration.

Figure 2 (Speed Change Example) shows an example for a trigger that fires when the speed of the Target changes by 20 meters per second.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="pidf"
            urn="urn:ietf:params:xml:ns:pidf"/>
        <ns-binding prefix="gp"
            urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
        <ns-binding prefix="dyn"
            urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
    </ns-bindings>
    <filter id="123" uri="sip:presentity@example.com">
        <trigger>
            <changed by="3">
                /pidf:presence/pidf:tuple/pidf:status/
                 gp:geopriv/gp:location-info/dyn:Dynamic/dyn:speed
            </changed>
        </trigger>
    </filter>
</filter-set>

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 (Speed Change Example) shows an example where a notification is sent when the civic address tokens A1, A2, A3, or PC change.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="pidf"
              urn="urn:ietf:params:xml:ns:pidf"/>
        <ns-binding prefix="gp"
              urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
        <ns-binding prefix="cl"
              urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
    </ns-bindings>
    <filter id="123" uri="sip:presentity@example.com">
        <trigger>
            <changed>
                /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
                 gp:location-info/cl:civilAddress/cl:A1
            </changed>
            <changed>
                /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
                 gp:location-info/cl:civilAddress/cl:A2
            </changed>
            <changed>
                /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
                 gp:location-info/cl:civilAddress/cl:A3
            </changed>
            <changed>
                /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/
                 gp:location-info/cl:civilAddress/cl:PC
            </changed>
        </trigger>
    </filter>
</filter-set>

3.4.  Enter or Exit a Region

The <enterOrExit> 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] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.)), or a circle (as defined in Section 5.2.3 of [RFC5491] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 2009.)).

Figure 4 (<enterOrExit> (2D) Filter Example) and Figure 5 (<enterOrExit> (3D) Filter Example) 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.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set
    xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
    xmlns:gml="http://www.opengis.net/gml"
    xmlns:gs="http://www.opengis.net/pidflo/1.0">

    <filter id="123" uri="sip:presentity@example.com">
        <con:enterOrExit>
            <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                <gml:pos>42.5463 -73.2512</gml:pos>
                <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                    850.24
                </gs:radius>
            </gs:Circle>
        </con:enterOrExit>
    </filter>
</filter-set>

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:con="urn:ietf:params:xml:ns:pidf:geopriv10:containment"
    xmlns:gml="http://www.opengis.net/gml">

    <filter id="123" uri="sip:presentity@example.com">
        <con:enterOrExit>
            <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                <gml:exterior>
                    <gml:LinearRing>
                        <gml:posList>
                        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
                    </gml:posList>
                    </gml:LinearRing>
                </gml:exterior>
            </gml:Polygon>
        </con:enterOrExit>
    </filter>
</filter-set>

4.  Rate Control

The throttle mechanisms [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,” February 2010.) can be used to control the rate of notifications. The "throttle", "force" and "average" settings can filter notications by time.

5.  XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    targetNamespace="urn:ietf:params:xml:ns:location-filter"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:gml="http://www.opengis.net/gml">

    <!-- This element is an child element of the RFC 4661
            <filter> element.
       -->
    <xs:element name="enterOrExit" type="gml:FeaturePropertyType"/>
</xs:schema>

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] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations,” March 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] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) and guidelines in RFC 3023 [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

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] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.), 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

Intended usage:

LIMITED USE

Author:

This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org>.

Change controller:

The IESG <iesg@ietf.org>

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] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

The URI for this namespace is urn:ietf:params:xml:ns:location-filter.

Registrant Contact:

IETF, GEOPRIV working group, <geopriv@ietf.org>, as delegated by the IESG <iesg@ietf.org>.

XML:

BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type"
     content="text/html;charset=iso-8859-1"/>
  <title>Location Filter Namespace</title>
</head>
<body>
  <h1>Namespace for PIDF-LO Location Filters</h1>
  <h2>urn:ietf:params:xml:ns:location-filter</h2>
  <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END

7.3.  Schema Registration For location-filter

This specification registers a schema, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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 (XML Schema).

8.  Acknowledgments

Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for their comments.

9.  References

9.1. Normative References

9.2. Informational References

Authors' Addresses