A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)
draft-ietf-geopriv-loc-filters-05.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 28, 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.  Introduction
2.  Terminology
3.  Filter Definitions
    3.1.  Movement
    3.2.  Speed Changes
    3.3.  Element Value Changes
    3.4.  Entering or Exiting a Region
    3.5.  Location Type
4.  XML Schema
5.  Security Considerations
6.  IANA Considerations
    6.1.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter
    6.2.  Schema Registration For location-filter
7.  Contributors
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informational References
§  Authors' Addresses

1.  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 document defines the following as an initial list of events that are relevant to a subscriber:

1. the Target moves more than a specified distance since the last notification
2. the Target exceeds a specified speed
3. the Target 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 Target. For example, the value of the <A1> civic address element has changed from 'California' to 'Nevada'.
5. the type of location information being requested.

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

3.  Filter Definitions

3.1.  Movement

The <moved> 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 <moved> element MUST only appear once as a child element of <filter>.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set
    xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:ext="urn:ietf:params:xml:ns:location-filter">
    <filter id="123" uri="sip:presentity@example.com">
        <ext:moved>300</ext:moved>
    </filter>
</filter-set>

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] (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 3 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="dyn"
            urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
    </ns-bindings>
    <filter id="123" uri="sip:presentity@example.com">
        <trigger>
            <changed by="3">
              //dyn:speed
            </changed>
        </trigger>
    </filter>
</filter-set>

3.3.  Element Value Changes

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="ca"
            urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
    </ns-bindings>
    <filter id="123" uri="sip:presentity@example.com">
        <trigger>
            <changed>//ca:A1</changed>
            <changed>//ca:A2</changed>
            <changed>//ca:A3</changed>
            <changed>//ca:PC</changed>
        </trigger>
    </filter>
</filter-set>

3.4.  Entering or Exiting a Region

The <enterOrExit> 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] (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> Circle Filter Example) shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle and Figure 5 (<enterOrExit> Polygon Filter Example) describes an area using a polygon.

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

    <filter id="123" uri="sip:presentity@example.com">
        <ext: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>
        </ext:enterOrExit>
    </filter>
</filter-set>

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

    <filter id="123" uri="sip:presentity@example.com">
        <ext: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>
        </ext:enterOrExit>
    </filter>
</filter-set>

3.5.  Location Type

The <locationType> element MAY be included as a child element of the <filter> 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 provide an error response. The 'exact' attribute does not apply (is ignored) for a request for a location type of "any".

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 <locationType> 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:

• civic
• civic, geodetic
• 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 <locationType> element MAY carry the 'exact' attribute. When the 'exact' attribute is set to "true", it indicates to the Notifier that the contents of the <locationType> 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.

The <locationType> element MAY carry another attribute, the 'responseTime' attribute, to provide a time value indicating to the Notifier how long the Subscriber is prepared to wait for a response or a purpose for which the Subscriber needs the location. The former functionality is more useful for a single SUBSCRIBE / NOTIFY interaction.

In the case of emergency services, the purpose of obtaining the location information could be either for routing a call to the appropriate Public Safety Answering Point (PSAP) or indicating the location to which responders should be dispatched. The values defined for the purpose, "emergencyRouting" and "emergencyDispatch", will likely be governed by jurisdictional policies, and should be configurable on the Notifier.

The time value in the 'responseTime' attribute is expressed as a non- negative integer in units of milliseconds. The time value is indicative only and the Notifier is under no obligation to strictly adhere to the time limit implied; any enforcement of the time limit is left to the requesting Subscriber. The Notifier provides the most accurate location information that can be determined within the specified interval for the specific service.

The Notifier may use the value of the time in the 'responseTime' attribute as input when selecting the method of location determination, where multiple such methods exist. If the 'responseTime' attribute is absent, then the Notifier should return the most precise location information it is capable of determining, with the time interval being implementation dependent.

An example is shown in Figure 6 (<locationType> Filter Example) that utilizes the <locationType> element with the 'exact' and the 'responseTime' attribute.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set
    xmlns="urn:ietf:params:xml:ns:simple-filter"
    xmlns:ext="urn:ietf:params:xml:ns:location-filter">
    <filter id="123" uri="sip:presentity@example.com">
        <ext:locationType exact="true" responseTime="emergencyRouting">
              geodetic
        </ext:locationType>
    </filter>
</filter-set>

4.  XML Schema

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

    <!-- These elements are child elements of the RFC 4661
         <filter> element.
    -->

    <xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>

    <xs:element name="moved" type="filter:movedType"/>

    <xs:complexType name="movedType">
       <xs:simpleContent>
          <xs:extension base="xs:double">
            <xs:anyAttribute namespace="##any" processContents="lax"/>
          </xs:extension>
       </xs:simpleContent>
    </xs:complexType>

    <xs:element name="locationType" type="filter:locationTypeType"/>

    <xs:simpleType name="locationTypeBase">
        <xs:union>
            <xs:simpleType>
                <xs:restriction base="xs:token">
                    <xs:enumeration value="any"/>
                </xs:restriction>
            </xs:simpleType>
            <xs:simpleType>
                <xs:restriction base="filter:locationTypeList">
                    <xs:minLength value="1"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:union>
    </xs:simpleType>

    <xs:simpleType name="locationTypeList">
        <xs:list>
            <xs:simpleType>
                <xs:restriction base="xs:token">
                    <xs:enumeration value="civic"/>
                    <xs:enumeration value="geodetic"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:list>
    </xs:simpleType>

    <xs:complexType name="locationTypeType">
        <xs:simpleContent>
            <xs:extension base="filter:locationTypeBase">
                <xs:attribute name="exact" type="xs:boolean"
                    use="optional" default="false"/>
                <xs:attribute name="responseTime"
                    type="filter:responseTimeType"
                    use="optional"/>
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>

    <xs:simpleType name="responseTimeType">
        <xs:union>
            <xs:simpleType>
                <xs:restriction base="xs:token">
                    <xs:enumeration value="emergencyRouting"/>
                    <xs:enumeration value="emergencyDispatch"/>
                </xs:restriction>
            </xs:simpleType>
            <xs:simpleType>
                <xs:restriction base="xs:nonNegativeInteger">
                    <xs:minInclusive value="0"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:union>
    </xs:simpleType>

</xs:schema>

5.  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.).

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

URI:

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

6.2.  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: urn:ietf:params:xml:schema:location-filter

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

7.  Contributors

We would like to thank Martin Thomson and James Polk for their contributions to this document.

8.  Acknowledgments

Thanks to Allan Thomson, James Winterbottom, Richard Barnes and Alissa Cooper for their comments.

9.  References

9.1. Normative References

9.2. Informational References

Authors' Addresses