[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
PROPOSED STANDARD
Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 6447 Individual
Category: Standards Track B. Rosen
ISSN: 2070-1721 NeuStar
H. Tschofenig
Nokia Siemens Networks
January 2012
Filtering Location Notifications in
the Session Initiation Protocol (SIP)
Abstract
This document describes filters that limit asynchronous location
notifications to compelling events. These filters are 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).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6447.
Mahy, et al. Standards Track [Page 1]
RFC 6447 Location Filters January 2012
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 5
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Mahy, et al. Standards Track [Page 2]
RFC 6447 Location Filters January 2012
1. Introduction
Conveying location information encapsulated with a Presence
Information Data Format Location Object (PIDF-LO) [RFC4119] document
within SIP is described in [SIP-LOC]. An alternative signaling
approach to location conveyance, which uses asynchronous
communication, is available with the SIP event notification
mechanisms (see RFC 3265 [RFC3265]). This approach conveys location
information in PIDF-LO format using the presence event package
[RFC3856]. This document focuses on the event notification paradigm.
Determining when to send event notifications with location
information is technically more challenging than deciding when to
send other categories of notifications, since location may be
measured as a continuous gradient. Unlike notifications using
discrete-valued quantities, it is difficult to know when a change in
location is sufficiently large to warrant a notification. Event
notifications [RFC3265] can be used with filters (see RFC 4661
[RFC4661]) that allow 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
replaced with a newer filter or until the subscription itself is
terminated.
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 being flooded with a large number of
notifications that are not important to the application.
This document defines new event filters and describes others using
existing mechanisms that may be relevant to a subscriber in the
context of location filtering. Based on the functionality defined in
this document, notifications can be provided in the following cases:
1. the Target moves more than a specified distance since the last
notification (see Section 3.1).
2. the Target exceeds a specified speed (see Section 3.2).
3. the Target enters or exits a 2-dimensional region, described by a
circle or a polygon (see Section 3.4).
4. one or more of the values of the specified civic location have
changed for the location of the Target (see Section 3.3). For
example, the value of the civic address '<A1>' element has
changed from 'California' to 'Nevada'.
Mahy, et al. Standards Track [Page 3]
RFC 6447 Location Filters January 2012
5. the type of location information requested (see Section 3.5)
changes, for example, from civic to geodetic location or vice
versa.
6. a certain amount of time passes (see Section 3.6).
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 [RFC6280].
3. Filter Definitions
This specification builds on a number of other specifications, as
noted in Section 1. In order to reduce the number of options (and
thereby decrease the chance of interoperability problems), the
functionality described in the following sub-sections of [RFC4661]
MUST be implemented: the <ns-bindings> element (see Section 3.3 of
[RFC4661]); the <filter> element (Section 3.4 of [RFC4661]); and the
<trigger> element (Section 3.6 of [RFC4661]), except for the <added>
and <removed> sub-elements.
3.1. Movement
The <moved> element MUST contain a value in meters indicating the
minimum distance that the resource must have moved from the location
of the resource since the last notification was sent in order to
trigger this event. The distance MUST be measured in meters
absolutely from the point of the last notification, and must include
vertical movement. The <moved> element MUST NOT appear more than
once as a child element of the <filter> element.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>
Figure 1: Movement Filter Example
Mahy, et al. Standards Track [Page 4]
RFC 6447 Location Filters January 2012
3.2. Speed Changes
Speed changes can be filtered by combining functionality from RFC
4661 with the PIDF-LO extensions for spatial orientation, speed,
heading, and acceleration defined in [RFC5962]. The value of the
<speed> element from [RFC5962] MUST be defined in meters per second.
Note that the condition could be met by a change in any axis,
including altitude.
Figure 2 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>
Figure 2: Speed Change Example
An implementation MUST support <ns-bindings> to replace the namespace
prefix. The XPath expression MUST start with a '//' followed by a
single element. No other form of XPath expression is supported. The
<changed> 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 <changed> element.
The following example illustrates a filter that triggers when the
Target's location changes from 'FR' (France) to some other country.
Mahy, et al. Standards Track [Page 5]
RFC 6447 Location Filters January 2012
<?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 from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
Figure 3: Element Value Change Example (Country Change)
At times when it is desirable to know if any one element of a list of
CAtypes changes, then they have to be put into separate <changes>
filters to ensure the subscriber is notified when any of the element
values change. Figure 4 shows such an example that illustrates the
difference.
Mahy, et al. Standards Track [Page 6]
RFC 6447 Location Filters January 2012
(A change in value of ANY of the five tokens triggers an event.)
<?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:country</changed>
</trigger>
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 4: Element Value Change Example
Finally, Figure 5 shows an example where a notification is sent when
the civic address tokens A3 and PC change (BOTH elements must change
in order to let the <trigger> element evaluate to TRUE).
Mahy, et al. Standards Track [Page 7]
RFC 6447 Location Filters January 2012
(Only a change in BOTH tokens triggers an event.)
<?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:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 5: Element Value Change Example
Note: The civic address tokens country, A1, A2, ..., A6 are
hierarchical. It is likely that a change in one civic address token
therefore leads to changes of tokens lower in the hierarchy, e.g., a
change in A3 ('city or town') may cause a change in A4, A5, and A6.
An implementation MUST support <ns-bindings> to replace the namespace
prefix. The XPath expression MUST start with a '//' followed by a
single element. No other form of XPath expression is supported. No
other variant is supported. The <changed> element comes with a few
attributes and the 'by', 'to', and 'from' attribute MUST be
implemented to support this specification.
3.4. Entering or Exiting a Region
The <enterOrExit> condition is satisfied when the Target enters or
exits a 2-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]). The <enterOrExit> element MUST contain either a
polygon or a circle as a child element. The <enterOrExit> element
MUST NOT have more than one polygon and/or circle.
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. The confidence that the location
is within the region, plus the confidence that the location is
Mahy, et al. Standards Track [Page 8]
RFC 6447 Location Filters January 2012
outside the region is limited to the confidence of the location. The
total confidence depends on the confidence in the location, which is
always less than 100% (95% is recommended in [RFC5491]). The benefit
of this is that notifications are naturally limited: small movements
(relative to the uncertainty of the location) at the borders of the
region do not trigger notifications.
Figure 6 shows filter examples whereby a notification is sent when
the Target enters or exits an area described by a circle, and
Figure 7 describes an area using a polygon.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="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">
<trigger>
<lf: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>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 6: <enterOrExit> Circle Filter Example
Mahy, et al. Standards Track [Page 9]
RFC 6447 Location Filters January 2012
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 7: <enterOrExit> Polygon Filter Example
3.5. Location Type
The <locationType> element MAY be included as a child element of the
<what> element. 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 location information in
all forms available to it.
Mahy, et al. Standards Track [Page 10]
RFC 6447 Location Filters January 2012
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 Notifier returns also depends 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".
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.
If the <locationType> element is absent, a value of "any" MUST be
assumed as the default.
The Notifier SHOULD provide civic and geodetic location information
in the response in the same order in which they were included in the
"locationType" element in the request, if both were explicitly
requested. 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)
The default value of "false" for the 'exact' attribute 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.
An example is shown in Figure 8 that utilizes the <locationType>
element with the 'exact' attribute.
Mahy, et al. Standards Track [Page 11]
RFC 6447 Location Filters January 2012
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true">
geodetic
</lf:locationType>
</what>
</filter>
</filter-set>
Figure 8: <locationType> Filter Example
3.6. Rate Control
[RFC6446] extends the SIP events framework by defining three Event
header field parameters that allow a subscriber to set a minimum, a
maximum, and an adaptive minimum of event notifications generated by
the notifier. This allows a subscriber to have overall control over
the stream of notifications, for example to avoid being flooded. Two
of the parameters, namely "min-rate" (which specifies a minimum
notification rate per second) and "max-rate" (which specifies a
maximum notification rate per second) are used by this document.
Only the implementation of these two attributes is required from the
attributes defined in [RFC6446]. Whenever the time since the most
recent notification exceeds the interval corresponding to 1 / "min-
rate", the current state would be sent in its entirety, just like
after a subscription refresh.
A notifier is required to send a NOTIFY request immediately after
creation of a subscription. If state is not available at that time,
then the NOTIFY request may be sent with no content. A separate
NOTIFY containing location is subsequently generated so that the rate
of notification since the last NOTIFY falls between "min-rate" and
"max-rate". 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. Standards Track [Page 12]