draft-ietf-geopriv-loc-filters-07.txt   draft-ietf-geopriv-loc-filters-08.txt 
GEOPRIV R. Mahy GEOPRIV R. Mahy
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: April 29, 2010 NeuStar Expires: May 12, 2010 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
October 26, 2009 November 8, 2009
Filtering Location Notifications in the Session Initiation Protocol Filtering Location Notifications in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-geopriv-loc-filters-07.txt draft-ietf-geopriv-loc-filters-08.txt
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, 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on May 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes filters that limit asynchronous location described in the BSD License.
notifications to compelling events, 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).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 7 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 17
6.2. Schema Registration For location-filter . . . . . . . . . 16 6.2. Schema Registration For location-filter . . . . . . . . . 17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informational References . . . . . . . . . . . . . . . . . 21 9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Conveying location information encapsulated with a PIDF-LO [RFC4119] Conveying location information encapsulated with a PIDF-LO [RFC4119]
document within SIP is described in document within SIP is described in
[I-D.ietf-sipcore-location-conveyance]. An alternative signaling [I-D.ietf-sipcore-location-conveyance]. An alternative signaling
approach, which uses asynchronous communication, is available with approach, which uses asynchronous communication, is available with
the SIP event notification mechanisms (see RFC 3265 [RFC3265]) and is the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This
used by this document. Unfortunately, it is more complex since many document focuses on the event notification paradigm. Event
forms of location are measured as a continuous gradient. Unlike notifications are technical more complex since location may be
notifications using discret quantities, it is difficult to know when measured as a continuous gradient and unlike notifications using
a change in location is large enough to warrant a notification. SIP discrete-valued quantities, it is difficult to know when a change in
events [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) location is large enough to warrant a notification. Event
that allows the number of notifications to be reduced. The mechanism notifications [RFC3265] can be used with filters (see RFC 4661
described in this document defines an extension to RFC 4661 [RFC4661]) that allows the number of notifications to be reduced.
[RFC4661], which limits location notification to events that are of The mechanism described in this document defines an extension to RFC
relevance to the subscriber. These filters persist until they are 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. changed with a replacement filter.
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 having to issue a large number of notifications granularity, without having to issue a large number of notifications
that are not important to the application. that are not important to the application.
This document defines a few new event filters and describes others This document defines a new event filters and describes others using
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: context of location filtering:
1. the Device moves more than a specified distance since the last 1. the Device moves more than a specified distance since the last
notification notification (see Section 3.1).
2. the Device exceeds a specified speed 2. the Device exceeds a specified speed (see Section 3.2).
3. the Device enters or exits a region (described by a circle or a 3. the Device enters or exits a region, described by a circle or a
polygon) 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 address labels have
changed for the location of the Device. For example, the value changed for the location of the Device (see Section 3.3). For
of the <A1> civic address element has changed from 'California' example, the value of the <A1> civic address element has changed
to 'Nevada'. from 'California' to 'Nevada'.
5. the type of location information being requested. 5. the type of location information being requested (see
Section 3.5).
6. the rate at which location information delivery is desired. 6. the rate at which location information delivery is desired (see
Section 3.6).
This document builds on the presence event package [RFC3856], i.e. an This document builds on the presence event package [RFC3856], i.e. an
existing event package for communicating location information inside existing event package for communicating location information inside
the PIDF-LO. 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 [I-D.ietf-geopriv-arch].
3. Filter Definitions 3. Filter Definitions
This specification builds on top of a number of other specifications, This specification builds on top of a number of other specifications,
as noted in Section 1. In order to reduce the number of options (and as noted in Section 1. In order to reduce the number of options (and
thereby increase the chance of interoperability problems), only the thereby decrease the chance of interoperability problems), the
functionality described in this document MUST be implemented. Only functionality of [RFC4661] listed in the sub-sections below MUST be
the functionality of [RFC4661] listed in the sub-sections below MUST implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661]),
be implemented, namely the <ns-bindings> (see Section 3.3 of the <filter> (Section 3.4 of [RFC4661]), and the <trigger> (Section
[RFC4661]), the <filter> (Section 3.4 of [RFC4661]), and the 3.6 of [RFC4661] excluding the functionality of the <added> and
<trigger> (Section 3.6 of [RFC4661] excluding the functionality of <removed> element).
the <added> and <removed> element).
3.1. Movement 3.1. Movement
The <moved> element with a value in meters indicates the minimum The <moved> element MUST contain a value in meters indicates the
distance that the resource must have moved from the location of the minimum distance that the resource must have moved from the location
resource when the last notification was sent in order to trigger this of the resource since the last notification was sent in order to
event. The distance is measured in meters absolutely from the point trigger this event. The distance MUST be measured in meters
of last notification rather than in terms of cumulative motion. The absolutely from the point of last notification. The <moved> element
<moved> element MUST only appear once as a child element of <filter>. MUST NOT appear more than 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">
<lf:moved>300</lf:moved> <lf:moved>300</lf:moved>
</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 with the help of RFC 4661 and the Speed changes can be filtered with the help of RFC 4661 and the
functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which
extends the PIDF-LO with support for spatial orientation, speed, extends the PIDF-LO with support for spatial orientation, speed,
heading, and acceleration. The value of <speed> in heading, and acceleration. The value of <speed> in
[I-D.singh-geopriv-pidf-lo-dynamic] is defined in meters per second. [I-D.singh-geopriv-pidf-lo-dynamic] and MUST be defined in meters per
This is the only supported measure and hence the value in the 'by' second.
attribute MUST be expressed in meters per second.
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 6, line 35 skipping to change at page 7, line 35
only the 'by' attribute MUST be implemented by this specification. only the 'by' 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 Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change (all 4 must change in order address tokens A1, A2, A3, or PC change (all 4 must change in order
to let the <trigger> element evaluate to TRUE). to let the <trigger> element evaluate to TRUE). In times where it is
desireable to know if any one individual of a list of CAtypes change,
then they have to be put into separate <changes> filters to ensure
you are notified when any of the element values change.
<?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:A1</changed> <changed>//ca:A1</changed>
skipping to change at page 7, line 44 skipping to change at page 8, line 44
<changed from="FR">//ca:country</changed> <changed from="FR">//ca:country</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 4: Speed Change Example (Country Change) Figure 4: Speed Change Example (Country Change)
An implementation MUST support the functionality as shown in Figure 3 An implementation MUST support the functionality as shown in Figure 3
with <ns-bindings> replacing the prefix. No other variant is with <ns-bindings> replacing the prefix. No other variant is
supported. The <changed> element comes with a few attributes and the supported. The <changed> element comes with a few attributes and the
'by', 'to' and 'from' attribute MUST be implemented by this 'by', 'to' and 'from' attribute MUST be implemented to support this
specification. 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 named 2-dimensional region described by a polygon (as defined
in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section
5.2.3 of [RFC5491]). The <enterOrExit> element MUST have contain 5.2.3 of [RFC5491]). The <enterOrExit> element MUST contain either a
either a polygon or a circle as a child element. More than one a polygon or a circle as a child element. The <enterOrExit> element
polygon and/or a circle as a child element of <enterOrExit> MUST NOT MUST NOT have more than one polygon and/or circle.
occur.
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. Confidence that the location is does not correspond to 50% outside. Confidence that the location is
within the region, plus confidence that the location is outside the within the region, plus confidence that the location is outside the
skipping to change at page 9, line 13 skipping to change at page 10, line 13
Figure 5: <enterOrExit> Circle Filter Example Figure 5: <enterOrExit> Circle Filter Example
<?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"
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">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<lf:enterOrExit> <lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:lferior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
43.311 -73.422 43.111 -73.322 <gml:pos>43.111 -73.322</gml:pos> <!--F-->
43.111 -73.222 43.311 -73.122 <gml:pos>43.111 -73.222</gml:pos> <!--E-->
43.411 -73.222 43.411 -73.322 <gml:pos>43.311 -73.122</gml:pos> <!--D-->
43.311 -73.422 <gml:pos>43.411 -73.222</gml:pos> <!--C-->
</gml:posList> <gml:pos>43.411 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</lf:enterOrExit> </lf:enterOrExit>
</filter> </filter>
</filter-set> </filter-set>
Figure 6: <enterOrExit> Polygon Filter Example Figure 6: <enterOrExit> Polygon Filter Example
3.5. Location Type 3.5. Location Type
skipping to change at page 9, line 47 skipping to change at page 10, line 48
any: The Notifier SHOULD attempt to provide LI in all forms any: The Notifier SHOULD attempt to provide LI in all forms
available to it. 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 LIS returns also depend on the setting of the location types the Notifier returns also depends on the setting of
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. The "SHOULD"-strength satisfied for a requested location type.
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 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 location in the response in the same
order in which they were included in the "locationType" element in order in which they were included in the "locationType" element in
the request. Indeed, the primary advantage of including specific the request. 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)
For the example above, if the 'exact' attribute was "true", then the The default value of "false" for the 'exact' attribute allows 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, 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. A value of "true" indicates that the Notifier MUST requested.
provide a location of the requested type or types or MUST provide an
error.
An example is shown in Figure 7 that utilizes the <locationType> An example is shown in Figure 7 that utilizes the <locationType>
element with the 'exact' and the 'responseTime' attribute. element with the 'exact' and the 'responseTime' 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">
<lf:locationType exact="true"> <lf:locationType exact="true">
skipping to change at page 11, line 24 skipping to change at page 12, line 11
</filter-set> </filter-set>
Figure 7: <locationType> Filter Example Figure 7: <locationType> Filter Example
3.6. Rate Control 3.6. Rate Control
[I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP [I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP
events framework defining the following three "Event" header field events framework defining the following three "Event" header field
parameters that allow a subscriber to set a minimum, a maximum and an parameters that allow a subscriber to set a minimum, a maximum and an
average rate of event notifications generated by the notifier. This average rate of event notifications generated by the notifier. This
document makes use of two of the parameters to accomplish document makes use of two of the parameters, namely "min-interval"
functionality equivalent to the 'responseTime' attribute used in HELD
[I-D.ietf-geopriv-http-location-delivery], namely "min-interval"
(which specifies a minimum notification time period between two (which specifies a minimum notification time period between two
notifications, in seconds) and "max-interval" (which specifies a notifications, in seconds) and "max-interval" (which specifies a
maximum notification time period between two notifications, in maximum notification time period between two notifications, in
seconds.). This specification only defines the semantic for these seconds.). The implementation of only these two attributes is
two attributes and requires implementation of these two from the set required from the complete set of attributes defined in
of attributes defined in [I-D.ietf-sipcore-event-rate-control]. [I-D.ietf-sipcore-event-rate-control]. Whenever the time since the
Whenever the time since the most recent notification exceeds the most recent notification exceeds the value in the "max-interval"
value in the "max-interval" parameter, then the current state would parameter, the current state would be sent in its entirety, just like
be sent in its entirety, just like after a subscription refresh. after a subscription refresh.
If complete state is not immediately available, a NOTIFY containing If complete state is not immediately available, then an empty NOTIFY
state (i.e. location) is generated some time between the time is sent immediately and subsequently a separate NOTIFY containing
included in 'min-interval' and the time in 'max-interval'. An location is generated some time between the time included in 'min-
important use case for location based applications focuses on the interval' and the time in 'max-interval'. An important use case for
behavior of the initial NOTIFY message(s) and the information it location based applications focuses on the behavior of the initial
returns, for example in case of emergency call routing. When an NOTIFY message(s) and the information it returns, for example in case
initial NOTIFY is transmitted it might not include complete state. of emergency call routing. When an initial NOTIFY is transmitted it
might not include complete state.
Subscriber Notifier Subscriber Notifier
|---SUBSCRIBE(1)--->| Request state subscription |---SUBSCRIBE(1)--->| Request state subscription
|<-------200--------| Acknowledge subscription |<-------200--------| Acknowledge subscription
|<-----NOTIFY(2)----| Return current state information |<-----NOTIFY(2)----| Return current state information
|-------200(3)----->| |-------200(3)----->|
|<-----NOTIFY(4)----| Return current state information |<-----NOTIFY(4)----| Return current state information
|--------200------->| |--------200------->|
Figure 8: SUBSCRIBE/NOTIFY with Rate Control Figure 8: SUBSCRIBE/NOTIFY with Rate Control
skipping to change at page 15, line 7 skipping to change at page 16, line 7
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 9: XML Schema Figure 9: XML Schema
5. Security Considerations 5. Security Considerations
This document builds on a number of specifications, namely This document specifies one piece, namely filters, utilized in larger
system. As such, this document builds on a number of 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 these documents listed above comes with a security
consideration section but the security and privacy aspects are best consideration 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]. The functionality for uploading [I-D.ietf-geopriv-arch].
authorization policies and other information that limit access to
location information are provided by other protocols, such Common The functionality offered by authorization policies to limit access
to location information are provided by other protocols, such Common
Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or
more recent work around HELD context more recent work around HELD context
[I-D.winterbottom-geopriv-held-context]. The functionality described [I-D.winterbottom-geopriv-held-context]. Although
in this document extends the filter framework with location specific [I-D.ietf-geopriv-policy] defines a standardized format for
filters. Local policies might be associated with the usage of geolocation authorization policies it does not define specific
certain filter constructs and with the amount of notifications policies for controlling filters.
specific filter settings might cause.
Although [I-D.ietf-geopriv-policy] defines a standardized format for The functionality described in this document extends the filter
authorization policies but it does not define specific policies for framework with location specific filters. Local policies might be
controlling filters specifically. associated with the usage of certain filter constructs and with the
amount of notifications specific filter settings might cause.
Uploading filters have a significant effect on the ways in which the
request is handled at a server. As a result, it is especially
important that messages containing this extension be authenticated
and authorised. RFC 4661 [RFC4661] discusses this security threat
and proposed authentication and authorization solutions applicable by
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].
URI: urn:ietf:params:xml:ns:location-filter URI: urn:ietf:params:xml:ns:location-filter
skipping to change at page 20, line 18 skipping to change at page 21, line 18
[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] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-00 (work in progress), July 2009. draft-ietf-geopriv-arch-01 (work in progress),
October 2009.
[I-D.ietf-sipcore-event-rate-control] [I-D.ietf-sipcore-event-rate-control]
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for Protocol (SIP) Event Notification Extension for
Notification Rate Control", Notification Rate Control",
draft-ietf-sipcore-event-rate-control-00 (work in draft-ietf-sipcore-event-rate-control-00 (work in
progress), May 2009. progress), May 2009.
[I-D.singh-geopriv-pidf-lo-dynamic] [I-D.singh-geopriv-pidf-lo-dynamic]
Schulzrinne, H., Singh, V., Tschofenig, H., and M. Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress), draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress),
August 2009. August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
skipping to change at page 21, line 24 skipping to change at page 22, line 26
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), draft-ietf-geopriv-policy-21 (work in progress),
July 2009. July 2009.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-01 (work in draft-ietf-sipcore-location-conveyance-01 (work in
progress), July 2009. progress), July 2009.
[I-D.winterbottom-geopriv-held-context] [I-D.winterbottom-geopriv-held-context]
 End of changes. 37 change blocks. 
133 lines changed or deleted 140 lines changed or added

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