draft-ietf-geopriv-loc-filters-11.txt   rfc6447.txt 
GEOPRIV R. Mahy Internet Engineering Task Force (IETF) R. Mahy
Internet-Draft Individual Request for Comments: 6447 Individual
Intended status: Standards Track B. Rosen Category: Standards Track B. Rosen
Expires: September 28, 2010 NeuStar ISSN: 2070-1721 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
March 27, 2010 January 2012
Filtering Location Notifications in the Session Initiation Protocol Filtering Location Notifications in
(SIP) the Session Initiation Protocol (SIP)
draft-ietf-geopriv-loc-filters-11.txt
Abstract Abstract
This document describes filters that limit asynchronous location This document describes filters that limit asynchronous location
notifications to compelling events, designed as an extension to RFC notifications to compelling events. These filters are designed as an
4661, an XML-based format for event notification filtering, and based extension to RFC 4661, an XML-based format for event notification
on RFC 3856, the SIP presence event package. The resulting location filtering, and based on RFC 3856, the SIP presence event package.
information is conveyed in existing location formats wrapped in the The resulting location information is conveyed in existing location
Presence Information Data Format Location Object (PIDF-LO). formats wrapped in the Presence Information Data Format Location
Object (PIDF-LO).
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 Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on September 28, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 5
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 10 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 14 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 19 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16
6.2. Schema Registration For location-filter . . . . . . . . . 19 6.2. Schema Registration for location-filter . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informational References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Conveying location information encapsulated with a Presence Conveying location information encapsulated with a Presence
Information Data Format Location Object (PIDF-LO) [RFC4119] document Information Data Format Location Object (PIDF-LO) [RFC4119] document
within SIP is described in [I-D.ietf-sipcore-location-conveyance]. within SIP is described in [SIP-LOC]. An alternative signaling
An alternative signaling approach to location conveyance, which uses approach to location conveyance, which uses asynchronous
asynchronous communication, is available with the SIP event communication, is available with the SIP event notification
notification mechanisms (see RFC 3265 [RFC3265]). This document mechanisms (see RFC 3265 [RFC3265]). This approach conveys location
focuses on the event notification paradigm. Event notifications are information in PIDF-LO format using the presence event package
technically more complex since location may be measured as a [RFC3856]. This document focuses on the event notification paradigm.
continuous gradient and unlike notifications using discrete-valued
quantities, it is difficult to know when a change in location is Determining when to send event notifications with location
large enough to warrant a notification. Event notifications information is technically more challenging than deciding when to
[RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that send other categories of notifications, since location may be
allow the number of notifications to be reduced. The mechanism measured as a continuous gradient. Unlike notifications using
described in this document defines an extension to RFC 4661 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 [RFC4661], which limits location notification to events that are of
relevance to the subscriber. These filters persist until they are relevance to the subscriber. These filters persist until they are
changed with a replacement filter or when the subscription itself is replaced with a newer filter or until the subscription itself is
terminated. terminated.
The frequency of notifications necessary for various geographic The frequency of notifications necessary for various geographic
location applications varies dramatically. The subscriber should be location applications varies dramatically. The subscriber should be
able to get asynchronous notifications with appropriate frequency and able to get asynchronous notifications with appropriate frequency and
granularity, without being flooded with a large number of granularity, without being flooded with a large number of
notifications that are not important to the application. notifications that are not important to the application.
This document defines a new event filters and describes others using This document defines new event filters and describes others using
existing mechanisms that may be relevant to a subscriber in the existing mechanisms that may be relevant to a subscriber in the
context of location filtering. Based on the functionality defined in context of location filtering. Based on the functionality defined in
this document notifications can be provided in the following cases: this document, notifications can be provided in the following cases:
1. the Device moves more than a specified distance since the last 1. the Target moves more than a specified distance since the last
notification (see Section 3.1). notification (see Section 3.1).
2. the Device exceeds a specified speed (see Section 3.2). 2. the Target exceeds a specified speed (see Section 3.2).
3. the Device enters or exits a region, described by a circle or a 3. the Target enters or exits a 2-dimensional region, described by a
polygon (see Section 3.4). circle or a polygon (see Section 3.4).
4. one or more of the values of the specified address labels have 4. one or more of the values of the specified civic location have
changed for the location of the Device (see Section 3.3). For changed for the location of the Target (see Section 3.3). For
example, the value of the <A1> civic address element has changed example, the value of the civic address '<A1>' element has
from 'California' to 'Nevada'. changed from 'California' to 'Nevada'.
5. the type of location information being requested (see 5. the type of location information requested (see Section 3.5)
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). 6. a certain amount of time passes (see Section 3.6).
This document builds on the presence event package [RFC3856], i. e.
an existing event package for communicating location information
inside the PIDF-LO.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses terminology from [I-D.ietf-geopriv-arch]. This document reuses terminology from [RFC6280].
3. Filter Definitions 3. Filter Definitions
This specification builds on top of a number of other specifications, This specification builds on a number of other specifications, as
as noted in Section 1. In order to reduce the number of options (and noted in Section 1. In order to reduce the number of options (and
thereby decrease the chance of interoperability problems), the thereby decrease the chance of interoperability problems), the
functionality of [RFC4661] listed in the sub-sections below MUST be functionality described in the following sub-sections of [RFC4661]
implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661]), MUST be implemented: the <ns-bindings> element (see Section 3.3 of
the <filter> (Section 3.4 of [RFC4661]), and the <trigger> (Section [RFC4661]); the <filter> element (Section 3.4 of [RFC4661]); and the
3.6 of [RFC4661] excluding the functionality of the <added> and <trigger> element (Section 3.6 of [RFC4661]), except for the <added>
<removed> element). and <removed> sub-elements.
3.1. Movement 3.1. Movement
The <moved> element MUST contain a value in meters indicates the The <moved> element MUST contain a value in meters indicating the
minimum distance that the resource must have moved from the location minimum distance that the resource must have moved from the location
of the resource since the last notification was sent in order to of the resource since the last notification was sent in order to
trigger this event. The distance MUST be measured in meters trigger this event. The distance MUST be measured in meters
absolutely from the point of last notification, and must include absolutely from the point of the last notification, and must include
vertical movement. The <moved> element MUST NOT appear more than vertical movement. The <moved> element MUST NOT appear more than
once as a child element of the <filter> element. once as a child element of the <filter> element.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set <filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"> xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<lf:moved>300</lf:moved> <lf:moved>300</lf:moved>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 1: Movement Filter Example Figure 1: Movement Filter Example
3.2. Speed Changes 3.2. Speed Changes
Speed changes can be filtered by combining functionality from RFC Speed changes can be filtered by combining functionality from RFC
4661 with the PIDF-LO extensions for spatial orientation, speed, 4661 with the PIDF-LO extensions for spatial orientation, speed,
heading, and acceleration defined in heading, and acceleration defined in [RFC5962]. The value of the
[I-D.singh-geopriv-pidf-lo-dynamic]. The value of the <speed> <speed> element from [RFC5962] MUST be defined in meters per second.
element from [I-D.singh-geopriv-pidf-lo-dynamic] MUST be defined in Note that the condition could be met by a change in any axis,
meters per second. Note that the condition could be met by a change including altitude.
in any axis including altitude.
Figure 2 shows an example for a trigger that fires when the speed of Figure 2 shows an example for a trigger that fires when the speed of
the Target changes by 3 meters per second. the Target changes by 3 meters per second.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="dyn" <ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/> urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings> </ns-bindings>
skipping to change at page 7, line 34 skipping to change at page 5, line 46
single element. No other form of XPath expression is supported. The single element. No other form of XPath expression is supported. The
<changed> element comes with a few attributes but only the 'by' <changed> element comes with a few attributes but only the 'by'
attribute MUST be implemented by this specification. attribute MUST be implemented by this specification.
3.3. Element Value Changes 3.3. Element Value Changes
Changes in values, for example related to civic location information, Changes in values, for example related to civic location information,
is provided by the base functionality offered with RFC 4661 utilizing is provided by the base functionality offered with RFC 4661 utilizing
the <changed> element. the <changed> element.
Figure 3 shows an example where a notification is sent when the civic The following example illustrates a filter that triggers when the
address tokens A1, A2, A3, and PC change (all four must change in Target's location changes from 'FR' (France) to some other country.
order to let the <trigger> element evaluate to TRUE).
(A change in ALL four tokens triggers an event.)
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="ca" <ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed>//ca:country</changed> <changed from="FR">//ca:country</changed>
<changed>//ca:A1</changed>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 3: Element Value Change Example Figure 3: Element Value Change Example (Country Change)
Note: The civic address tokens country, A1, A2, ..., A6 are
hierachical. It is likely that a change in one civic address token
therefore leads to changes of tokens lower in the hiearchy, e.g., a
change in A3 ('city or town') may cause a change in A4, A5, and A6.
In times where it is desirable to know if any one element of a list At times when it is desirable to know if any one element of a list of
of CAtypes changes, then they have to be put into separate <changes> CAtypes changes, then they have to be put into separate <changes>
filters to ensure you are notified when any of the element values filters to ensure the subscriber is notified when any of the element
change. Figure 4 shows such an example that illustrates the values change. Figure 4 shows such an example that illustrates the
difference. difference.
(A change in value of ANY of the four tokens triggers an event.) (A change in value of ANY of the five tokens triggers an event.)
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="ca" <ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed>//ca:country</changed> <changed>//ca:country</changed>
skipping to change at page 9, line 34 skipping to change at page 7, line 34
<changed>//ca:A3</changed> <changed>//ca:A3</changed>
</trigger> </trigger>
<trigger> <trigger>
<changed>//ca:PC</changed> <changed>//ca:PC</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 4: Element Value Change Example Figure 4: Element Value Change Example
The following example illustrates a filter that triggers when the Finally, Figure 5 shows an example where a notification is sent when
Target's location changes from 'FR' (France) to some other country. the civic address tokens A3 and PC change (BOTH elements must change
in order to let the <trigger> element evaluate to TRUE).
(Only a change in BOTH tokens triggers an event.)
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings> <ns-bindings>
<ns-binding prefix="ca" <ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings> </ns-bindings>
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<changed from="FR">//ca:country</changed> <changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 5: Element Value Change Example (Country Change) 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 An implementation MUST support <ns-bindings> to replace the namespace
prefix. The XPath expression MUST start with a '//' followed by a prefix. The XPath expression MUST start with a '//' followed by a
single element. No other form of XPath expression is supported. No single element. No other form of XPath expression is supported. No
other variant is supported. The <changed> element comes with a few other variant is supported. The <changed> element comes with a few
attributes and the 'by', 'to' and 'from' attribute MUST be attributes and the 'by', 'to', and 'from' attribute MUST be
implemented to support this specification. implemented to support this specification.
3.4. Entering or Exiting a Region 3.4. Entering or Exiting a Region
The <enterOrExit> condition is satisfied when the Target enters or The <enterOrExit> condition is satisfied when the Target enters or
exits a named 2-dimensional region described by a polygon (as defined exits a 2-dimensional region described by a polygon (as defined in
in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section Section 5.2.2 of [RFC5491]) or a circle (as defined in Section 5.2.3
5.2.3 of [RFC5491]). The <enterOrExit> element MUST contain either a of [RFC5491]). The <enterOrExit> element MUST contain either a
polygon or a circle as a child element. The <enterOrExit> element polygon or a circle as a child element. The <enterOrExit> element
MUST NOT have more than one polygon and/or circle. MUST NOT have more than one polygon and/or circle.
If the Target was previously outside the region, the notifier sends a If the Target was previously outside the region, the notifier sends a
notification when the Target's location is within the region with at notification when the Target's location is within the region with at
least 50% confidence. Similarly, when a Target starts within the least 50% confidence. Similarly, when a Target starts within the
region, a notification is sent when the Target's location moves region, a notification is sent when the Target's location moves
outside the region with at least 50% confidence. outside the region with at least 50% confidence.
Note that having 50% confidence that the Target is inside the area Note that having 50% confidence that the Target is inside the area
does not correspond to 50% outside. The confidence that the location does not correspond to 50% outside. The confidence that the location
is within the region, plus the confidence that the location is is within the region, plus the confidence that the location is
outside the region is limited to the confidence of the location. The outside the region is limited to the confidence of the location. The
total confidence depends on the confidence in the location, which is total confidence depends on the confidence in the location, which is
always less than 100% (95% is recommended in [RFC5491]). The benefit always less than 100% (95% is recommended in [RFC5491]). The benefit
of this is that notifications are naturally limited: small movements of this is that notifications are naturally limited: small movements
(relative to the uncertainty of the location) at the borders of the (relative to the uncertainty of the location) at the borders of the
region do not trigger notifications. region do not trigger notifications.
Figure 6 shows filter examples whereby a notification is sent when 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 the Target enters or exits an area described by a circle, and
describes an area using a polygon. Figure 7 describes an area using a polygon.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set <filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"> xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
skipping to change at page 12, line 44 skipping to change at page 10, line 44
</lf:enterOrExit> </lf:enterOrExit>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 7: <enterOrExit> Polygon Filter Example Figure 7: <enterOrExit> Polygon Filter Example
3.5. Location Type 3.5. Location Type
The <locationType> element MAY be included as a child element of the The <locationType> element MAY be included as a child element of the
<what> element and it contains a list of location information types <what> element. It contains a list of location information types
that are requested by the subscriber. The following list describes that are requested by the subscriber. The following list describes
the possible values: the possible values:
any: The Notifier SHOULD attempt to provide LI in all forms any: The Notifier SHOULD attempt to provide location information in
available to it. all forms available to it.
geodetic: The Notifier SHOULD return a location by value in the form geodetic: The Notifier SHOULD return a location by value in the form
of a geodetic location. of a geodetic location.
civic: The Notifier SHOULD return a location by value in the form of civic: The Notifier SHOULD return a location by value in the form of
a civic address. a civic address.
The Notifier SHOULD return the requested location type or types. The The Notifier SHOULD return the requested location type or types. The
location types the Notifier returns also depends on the setting of location types the Notifier returns also depends on the setting of
the optional 'exact' attribute. If the 'exact' attribute is set to the optional 'exact' attribute. If the 'exact' attribute is set to
"true" then the Notifier MUST return either the requested location "true", then the Notifier MUST return either the requested location
type or no location information. The 'exact' attribute does not type or no location information. The 'exact' attribute does not
apply (is ignored) for a request for a location type of "any". 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' In the case of a request for specific locationType(s) and the 'exact'
attribute is "false", the Notifier MAY provide additional location attribute is "false", the Notifier MAY provide additional location
types, or it MAY provide alternative types if the request cannot be types, or it MAY provide alternative types if the request cannot be
satisfied for a requested location type. satisfied for a requested location type.
If the <locationType> element is absent, a value of "any" MUST be If the <locationType> element is absent, a value of "any" MUST be
assumed as the default. assumed as the default.
The Notifier SHOULD provide location in the response in the same The Notifier SHOULD provide civic and geodetic location information
order in which they were included in the "locationType" element in in the response in the same order in which they were included in the
the request. Indeed, the primary advantage of including specific "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 location types in a request when the 'exact' attribute is set to
"false" is to ensure that one receives the available locations in a "false" is to ensure that one receives the available locations in a
specific order. For example, a subscription for "civic" (with the specific order. For example, a subscription for "civic" (with the
'exact' attribute set to "false") could yield any of the following 'exact' attribute set to "false") could yield any of the following
location types in the response: location types in the response:
o civic o civic
o civic, geodetic o civic, geodetic
o geodetic (only if civic is not available) o geodetic (only if civic is not available)
The default value of "false" for the 'exact' attribute allows the The default value of "false" for the 'exact' attribute allows the
Notifier the option of returning something beyond what is specified, Notifier the option of returning something beyond what is specified,
such as a set of location URIs when only a civic location was such as a set of location URIs when only a civic location was
requested. requested.
An example is shown in Figure 8 that utilizes the <locationType> An example is shown in Figure 8 that utilizes the <locationType>
element with the 'exact' and the 'responseTime' attribute. element with the 'exact' attribute.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<filter-set <filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"> xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<what> <what>
<lf:locationType exact="true"> <lf:locationType exact="true">
geodetic geodetic
</lf:locationType> </lf:locationType>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
Figure 8: <locationType> Filter Example Figure 8: <locationType> Filter Example
3.6. Rate Control 3.6. Rate Control
[I-D.ietf-sipcore-event-rate-control] extends the SIP events [RFC6446] extends the SIP events framework by defining three Event
framework by defining the following three "Event" header field header field parameters that allow a subscriber to set a minimum, a
parameters that allow a subscriber to set a minimum, a maximum and an maximum, and an adaptive minimum of event notifications generated by
average rate of event notifications generated by the notifier. This the notifier. This allows a subscriber to have overall control over
allows a subscriber to have overall control over the stream of the stream of notifications, for example to avoid being flooded. Two
notifications, for example to avoid being flooded. Two of the of the parameters, namely "min-rate" (which specifies a minimum
parameters, namely "min-interval" (which specifies a minimum notification rate per second) and "max-rate" (which specifies a
notification time period between two notifications, in seconds) and maximum notification rate per second) are used by this document.
"max-interval" (which specifies a maximum notification time period
between two notifications, in seconds.) are used by this document.
Only the implementation of these two attributes is required from the Only the implementation of these two attributes is required from the
attributes defined in [I-D.ietf-sipcore-event-rate-control]. attributes defined in [RFC6446]. Whenever the time since the most
Whenever the time since the most recent notification exceeds the recent notification exceeds the interval corresponding to 1 / "min-
value in the "max-interval" parameter, the current state would be rate", the current state would be sent in its entirety, just like
sent in its entirety, just like after a subscription refresh. after a subscription refresh.
A notifier is required to send a NOTIFY request immediately after A notifier is required to send a NOTIFY request immediately after
creation of a subscription. If state is not available at that time, creation of a subscription. If state is not available at that time,
then the NOTIFY request may be sent with no content. A separate then the NOTIFY request may be sent with no content. A separate
NOTIFY containing location is subsequently generated some time NOTIFY containing location is subsequently generated so that the rate
between the time included in 'min-interval' and the time in 'max- of notification since the last NOTIFY falls between "min-rate" and
interval'. An important use case for location based applications "max-rate". An important use case for location-based applications
focuses on the behavior of the initial NOTIFY message(s) and the focuses on the behavior of the initial NOTIFY message(s) and the
information it returns, for example in case of emergency call information it returns, for example in case of emergency call
routing. When an initial NOTIFY is transmitted it might not include routing. When an initial NOTIFY is transmitted, it might not include
complete state. complete state.
Subscriber Notifier Subscriber Notifier
|---SUBSCRIBE(1)--->| Create subscription (w/small value |---SUBSCRIBE(1)--->| Create subscription (w/large value
|<-------200--------| for min-interval and max-interval) |<-------200--------| for min-rate and max-rate)
|<-----NOTIFY(2)----| Return initial notify with no state |<-----NOTIFY(2)----| Return initial notify with no state
|--------200------->| |--------200------->|
|<-----NOTIFY(3)----| Return full state (between min-interval | ... |
|--------200------->| and max-interval) |<-----NOTIFY(3)----| Return full state (between min-rate
|---SUBSCRIBE(4)--->| Update subscription (to update |--------200------->| and max-rate)
|<-------200--------| min-interval and max-interval) |---SUBSCRIBE(4)--->| Update subscription (to update
|<-------200--------| min-rate and max-rate)
Figure 9: SUBSCRIBE/NOTIFY with Rate Control Figure 9: SUBSCRIBE/NOTIFY with Rate Control
Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE
message (1) has filters attached and contains a 'max-interval' rate message (1) has filters attached and contains a "min-rate" rate
control parameter. In certain situations it is important to obtain control parameter. In certain situations, it is important to obtain
some amount of location information within a relatively short and some amount of location information within a relatively short and
pre-defined period of time even if the obtained location information pre-defined period of time, even if the obtained location information
contains a high amount of uncertainty and location information with contains a high amount of uncertainty and location information with
less uncertainty at a later point in time. An example is emergency less uncertainty could be available at a later point in time. An
call routing where a emergency services routing proxy may need to example is emergency call routing where an emergency services routing
obtain location information suitable for routing rather quickly and proxy may need to obtain location information suitable for routing
subsequently a Public Safety Answering Point requests location rather quickly and subsequently a Public Safety Answering Point
information for dispatch. requests location information for dispatch.
To obtain location information in a timely fashion using the To obtain location information in a timely fashion using the
SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial
SUBSCRIBE contains a 'max-interval' rate control parameter (with a SUBSCRIBE contain a "min-rate" rate control parameter (with a large
small value) that is in a later message updated to a more sensible value, corresponding to a very short delay before the next
notification) that is updated in a later message to a more sensible
value. This provides equivalent functionality to the 'responseTime' value. This provides equivalent functionality to the 'responseTime'
attribute in Section 6.1 of attribute in Section 6.1 of [RFC5985]. The "min-rate" for this first
[I-D.ietf-geopriv-http-location-delivery]. The 'max-interval' for request is therefore much larger (much more rapid) than the updated
this first request is therefore much lower than thereafter. Updating "min-rate" value. Depending on the value in the "min-rate"
the 'max-interval' for the subscription can be performed in the 200 parameter, the Notifier may immediately send the initial NOTIFY
response (see message 3) to the NOTIFY that contains state. message (see message 2) without a body if no location information is
Depending on the value in the 'max-interval' parameter the Notifier available at this point in time. The desired location information
may create a NOTIFY message (see message 2) immediately in response may then arrive in the subsequent NOTIFY message (see message 3).
to the SUBSCRIBE that might be empty in case no location information Updating the "min-rate" for the subscription can be performed in the
is available at this point in time. The desired location information 200 response (see message 3) to the NOTIFY that contains location
may then arrive in the subsequent NOTIFY message (see message 4). state, or in a subsequent SUBSCRIBE request (as in message 4).
4. XML Schema 4. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:location-filter" targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:filter="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:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
skipping to change at page 18, line 7 skipping to change at page 15, line 18
use="optional" default="false"/> use="optional" default="false"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Figure 10: XML Schema Figure 10: XML Schema
5. Security Considerations 5. Security Considerations
This document specifies one piece, namely filters, utilized in larger This document specifies one element, namely filters, utilized in
system. As such, this document builds on a number of specifications larger systems. As such, this document builds on a number of
for the security of the complete solution, namely specifications for the security of the complete solution, namely
o the SIP event notification mechanism, described in RFC 3265 o the SIP event notification mechanism, described in RFC 3265
[RFC3265], defining the SUBSCRIBE/NOTIFY messages. [RFC3265], defining the SUBSCRIBE/NOTIFY messages.
o the presence event package, described in RFC 3856 [RFC3856], which o the presence event package, described in RFC 3856 [RFC3856], which
is a concrete instantiation of the general event notification is a concrete instantiation of the general event notification
framework. framework.
o the filter framework, described in RFC 4661 [RFC4661], to offer o the filter framework, described in RFC 4661 [RFC4661], to offer
the ability to reduce the amount of notifications being sent. the ability to reduce the amount of notifications being sent.
Finally, this document indirectly (via the SIP presence event Finally, this document indirectly (via the SIP presence event
package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the
XML container that carries location information. XML container that carries location information.
Each of these documents listed above comes with a security Each of the documents listed above comes with a Security
consideration section but the security and privacy aspects are best Considerations section but the security and privacy aspects are best
covered by the SIP presence event package, see Section 9 of covered by the SIP presence event package; see Section 9 of
[RFC3856], and with the GEOPRIV architectural description found in [RFC3856], and with the GEOPRIV architectural description found in
[I-D.ietf-geopriv-arch]. [RFC6280].
The functionality offered by authorization policies to limit access The functionality offered by authorization policies to limit access
to location information are provided by other protocols, such Common to location information is provided by other protocols, such as
Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or Common Policy [RFC4745], Geolocation Policy [GEO-POLICY], or more
more recent work around HELD context recent work around HTTP-Enabled Location Delivery (HELD) context
[I-D.winterbottom-geopriv-held-context]. Although [HELD]. Although [GEO-POLICY] defines a standardized format for
[I-D.ietf-geopriv-policy] defines a standardized format for geolocation authorization policies, it does not define specific
geolocation authorization policies it does not define specific
policies for controlling filters. policies for controlling filters.
The functionality described in this document extends the filter The functionality described in this document extends the filter
framework with location specific filters. Local policies might be framework with location-specific filters. Local policies might be
associated with the usage of certain filter constructs and with the associated with the usage of certain filter constructs and with the
amount of notifications specific filter settings might cause. amount of notifications that specific filter settings might cause.
Uploading filters have a significant effect on the ways in which the Uploading filters have a significant effect on the ways in which the
request is handled at a server. As a result, it is especially request is handled at a server. As a result, it is especially
important that messages containing this extension be authenticated important that messages containing this extension be authenticated
and authorised. RFC 4661 [RFC4661] discusses this security threat and authorized. RFC 4661 [RFC4661] discusses this security threat
and proposed authentication and authorization solutions applicable by and proposes authentication and authorization solutions applicable to
this specification. this specification.
6. IANA Considerations 6. IANA Considerations
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[RFC3688]. [RFC3688].
skipping to change at page 19, line 33 skipping to change at page 16, line 41
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Location Filter Namespace</title> <title>Location Filter Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for PIDF-LO Location Filters</h1> <h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2> <h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6447.txt">
RFC 6447</a>.</p>
</body> </body>
</html> </html>
END END
6.2. Schema Registration For location-filter 6.2. Schema Registration for location-filter
This specification registers a schema, as per the guidelines in This specification registers a schema, as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:location-filter URI: urn:ietf:params:xml:schema:location-filter
Registrant Contact: IETF, GEOPRIV Working Group Registrant Contact: IETF, GEOPRIV Working Group
(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). (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: The XML can be found as the sole content of Section 4.
7. Contributors 7. Contributors
We would like to thank Martin Thomson and James Polk for their We would like to thank Martin Thomson and James Polk for their
contributions to this document. contributions to this document.
8. Acknowledgments 8. Acknowledgments
Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl Thanks to Richard Barnes, Alissa Cooper, Randall Gellens, Carl Reed,
Reed, Ben Campbell, Adam Roach, Allan Thomson, James Winterbottom for Ben Campbell, Adam Roach, Allan Thomson, and James Winterbottom for
their comments. their comments.
Furthermore, we would like to thank Alexey Melnikov for his IESG Furthermore, we would like to thank Alexey Melnikov for his IESG
review comments. review comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[GML] OpenGIS, "Open Geography Markup Language (GML) [GML] OpenGIS, "Open Geography Markup Language (GML)
Implementation Specification", OpenGIS OGC 02-023r4, Implementation Specification", OpenGIS OGC 02-023r4,
January 2003, January 2003,
<http://www.opengis.org/techno/implementation.htm>. <http://www.opengis.org/techno/implementation.htm>.
[I-D.ietf-geopriv-arch] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Requirement Levels", BCP 14, RFC 2119, March 1997.
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress),
October 2009.
[I-D.ietf-sipcore-event-rate-control] [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Event Notification", RFC 3265, June 2002.
Protocol (SIP) Event Notification Extension for
Notification Rate Control",
draft-ietf-sipcore-event-rate-control-03 (work in
progress), February 2010.
[I-D.singh-geopriv-pidf-lo-dynamic] [RFC3856] Rosenberg, J., "A Presence Event Package for the
Schulzrinne, H., Singh, V., Tschofenig, H., and M. Session Initiation Protocol (SIP)", RFC 3856,
Thomson, "Dynamic Extensions to the Presence Information August 2004.
Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-09 (work in progress),
March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Requirement Levels", BCP 14, RFC 2119, March 1997. Format", RFC 4119, December 2005.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J.
Event Notification", RFC 3265, June 2002. Costa-Requena, "An Extensible Markup Language (XML)-
Based Format for Event Notification Filtering",
RFC 4661, September 2006.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig,
Initiation Protocol (SIP)", RFC 3856, August 2004. "GEOPRIV Presence Information Data Format Location
Object (PIDF-LO) Usage Clarification, Considerations,
and Recommendations", RFC 5491, March 2009.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Format", RFC 4119, December 2005. Thomson, "Dynamic Extensions to the Presence
Information Data Format Location Object (PIDF-LO)",
RFC 5962, September 2010.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Requena, "An Extensible Markup Language (XML)-Based Format Tschofenig, H., and H. Schulzrinne, "An Architecture
for Event Notification Filtering", RFC 4661, for Location and Location Privacy in Internet
September 2006. Applications", BCP 160, RFC 6280, July 2011.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Presence Information Data Format Location Object (PIDF-LO) Protocol (SIP) Event Notification Extension for
Usage Clarification, Considerations, and Recommendations", Notification Rate Control", RFC 6446, January 2012.
RFC 5491, March 2009.
9.2. Informational References 9.2. Informative References
[I-D.ietf-geopriv-http-location-delivery] [GEO-POLICY] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Morris, J., and M. Thomson, "Geolocation Policy: A
"HTTP Enabled Location Delivery (HELD)", Document Format for Expressing Privacy Preferences for
draft-ietf-geopriv-http-location-delivery-16 (work in Location Information", Work in Progress, October 2011.
progress), August 2009.
[I-D.ietf-geopriv-policy] [HELD] Winterbottom, J., Tschofenig, H., and M. Thomson,
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., "Location URI Contexts in HTTP-Enabled Location
and J. Polk, "Geolocation Policy: A Document Format for Delivery (HELD)", Work in Progress, October 2009.
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress),
January 2010.
[I-D.ietf-sipcore-location-conveyance] [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
Polk, J. and B. Rosen, "Location Conveyance for the RFC 3688, January 2004.
Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-02 (work in
progress), February 2010.
[I-D.winterbottom-geopriv-held-context] [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar,
Winterbottom, J., Tschofenig, H., and M. Thomson, J., Polk, J., and J. Rosenberg, "Common Policy: A
"Location URI Contexts in HTTP-Enabled Location Delivery Document Format for Expressing Privacy Preferences",
(HELD)", draft-winterbottom-geopriv-held-context-05 (work RFC 4745, February 2007.
in progress), October 2009.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
January 2004. RFC 5985, September 2010.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [SIP-LOC] Polk, J., Rosen, B., and J. Peterson, "Location
Polk, J., and J. Rosenberg, "Common Policy: A Document Conveyance for the Session Initiation Protocol", Work
Format for Expressing Privacy Preferences", RFC 4745, in Progress, September 2011.
February 2007.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Individual Individual
Email: rohan@ekabal.com EMail: rohan@ekabal.com
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net EMail: br@brianrosen.net
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 84 change blocks. 
273 lines changed or deleted 246 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/