One document matched: draft-ietf-geopriv-loc-filters-05.txt
Differences from draft-ietf-geopriv-loc-filters-04.txt
GEOPRIV R. Mahy
Internet-Draft Plantronics
Intended status: Standards Track B. Rosen, Ed.
Expires: January 28, 2010 NeuStar
H. Tschofenig
Nokia Siemens Networks
July 27, 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-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.
Mahy, et al. Expires January 28, 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. 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 . . . . . . . . . . . . . . . 6
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 8
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 14
6.2. Schema Registration For location-filter . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informational References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Mahy, et al. Expires January 28, 2010 [Page 2]
Internet-Draft Location Event Filters July 2009
1. 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 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.
Mahy, et al. Expires January 28, 2010 [Page 3]
Internet-Draft Location Event Filters July 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].
Mahy, et al. Expires January 28, 2010 [Page 4]
Internet-Draft Location Event Filters July 2009
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>
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.
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 January 28, 2010 [Page 5]
Internet-Draft Location Event Filters July 2009
<?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>
Figure 2: Speed Change Example
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 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>
Figure 3: Speed Change Example
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]), or a circle (as defined in Section
Mahy, et al. Expires January 28, 2010 [Page 6]
Internet-Draft Location Event Filters July 2009
5.2.3 of [RFC5491]).
Figure 4 shows filter examples whereby a notification is sent when
the Target enters or exits an area described by a circle and Figure 5
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>
Figure 4: <enterOrExit> Circle Filter Example
Mahy, et al. Expires January 28, 2010 [Page 7]
Internet-Draft Location Event Filters July 2009
<?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>
Figure 5: <enterOrExit> Polygon Filter Example
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".
Mahy, et al. Expires January 28, 2010 [Page 8]
Internet-Draft Location Event Filters July 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 <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:
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 <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
Mahy, et al. Expires January 28, 2010 [Page 9]
Internet-Draft Location Event Filters July 2009
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 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>
Figure 6: <locationType> Filter Example
Mahy, et al. Expires January 28, 2010 [Page 10]
Internet-Draft Location Event Filters July 2009
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"/>
Mahy, et al. Expires January 28, 2010 [Page 11]
Internet-Draft Location Event Filters July 2009
<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>
Figure 7: XML Schema
Mahy, et al. Expires January 28, 2010 [Page 12]
Internet-Draft Location Event Filters July 2009
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].
Mahy, et al. Expires January 28, 2010 [Page 13]
Internet-Draft Location Event Filters July 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, <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].
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 January 28, 2010 [Page 14]
Internet-Draft Location Event Filters July 2009
XML: The XML can be found as the sole content of Section 4.
Mahy, et al. Expires January 28, 2010 [Page 15]
Internet-Draft Location Event Filters July 2009
7. Contributors
We would like to thank Martin Thomson and James Polk for their
contributions to this document.
Mahy, et al. Expires January 28, 2010 [Page 16]
Internet-Draft Location Event Filters July 2009
8. Acknowledgments
Thanks to Allan Thomson, James Winterbottom, Richard Barnes and
Alissa Cooper for their comments.
Mahy, et al. Expires January 28, 2010 [Page 17]
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,
<http://www.opengis.org/techno/implementation.htm>.
[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.
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 28, 2010 [Page 18]
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 28, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-21 22:07:24 |