draft-ietf-geopriv-loc-filters-09.txt   draft-ietf-geopriv-loc-filters-10.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: July 1, 2010 NeuStar Expires: September 7, 2010 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
December 28, 2009 March 6, 2010
Filtering Location Notifications in the Session Initiation Protocol Filtering Location Notifications in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-geopriv-loc-filters-09.txt draft-ietf-geopriv-loc-filters-10.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, designed as an extension to RFC
4661, an XML-based format for event notification filtering, and based 4661, an XML-based format for event notification filtering, and based
on RFC 3856, the SIP presence event package. The resulting location on RFC 3856, the SIP presence event package. The resulting location
information is conveyed in existing location formats wrapped in the information is conveyed in existing location formats wrapped in the
Presence Information Data Format Location Object (PIDF-LO). Presence Information Data Format Location Object (PIDF-LO).
skipping to change at page 1, line 45 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 July 1, 2010. This Internet-Draft will expire on September 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 9
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 13
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 17 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 18
6.2. Schema Registration For location-filter . . . . . . . . . 17 6.2. Schema Registration For location-filter . . . . . . . . . 18
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informational References . . . . . . . . . . . . . . . . . 22 9.2. Informational References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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]). This the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This
document focuses on the event notification paradigm. Event document focuses on the event notification paradigm. Event
notifications are technical more complex since location may be notifications are technical more complex since location may be
skipping to change at page 6, line 21 skipping to change at page 6, line 21
implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661]), implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661]),
the <filter> (Section 3.4 of [RFC4661]), and the <trigger> (Section the <filter> (Section 3.4 of [RFC4661]), and the <trigger> (Section
3.6 of [RFC4661] excluding the functionality of the <added> and 3.6 of [RFC4661] excluding the functionality of the <added> and
<removed> element). <removed> element).
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 indicates 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. Note that the condition could be met by a change
absolutely from the point of last notification. The <moved> element in any axis including altitude. The distance MUST be measured in
MUST NOT appear more than once as a child element of the <filter> meters absolutely from the point of last notification. The <moved>
element. element 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">
<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 with the help of RFC 4661 and the Speed changes can be filtered by combining functionality from RFC
functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which 4661 with the PIDF-LO extensions for spatial orientation, speed,
extends the PIDF-LO with support for spatial orientation, speed, heading, and acceleration defined in
heading, and acceleration. The value of <speed> in [I-D.singh-geopriv-pidf-lo-dynamic]. The value of the <speed>
[I-D.singh-geopriv-pidf-lo-dynamic] and MUST be defined in meters per element from [I-D.singh-geopriv-pidf-lo-dynamic] MUST be defined in
second. meters per second. Note that the condition could be met by a change
in any axis including altitude.
Figure 2 shows an example for a trigger that fires when the speed of 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 7, line 34
supported. The <changed> element comes with a few attributes but supported. The <changed> element comes with a few attributes but
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 four must change in
to let the <trigger> element evaluate to TRUE). In times where it is order to let the <trigger> element evaluate to TRUE).
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>
<changed>//ca:A2</changed> <changed>//ca:A2</changed>
<changed>//ca:A3</changed> <changed>//ca:A3</changed>
<changed>//ca:PC</changed> <changed>//ca:PC</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 3: Speed Change Example Figure 3: Element Value Change Example
In times where it is desireable to know if any one element of a list
of CAtypes changes, then they have to be put into separate <changes>
filters to ensure you are notified when any of the element values
change. Figure 4 shows such an example that illustrates the
difference.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 4: Element Value Change Example
The following example illustrates a filter that triggers when the The following example illustrates a filter that triggers when the
Target's location changes from 'FR' (France) to some other country. Target's location changes from 'FR' (France) to some other country.
<?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 from="FR">//ca:country</changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 4: Speed Change Example (Country Change) Figure 5: Element Value 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 to support 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
skipping to change at page 9, line 15 skipping to change at page 9, line 45
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. Confidence that the location is does not correspond to 50% outside. The confidence that the location
within the region, plus confidence that the location is outside the is within the region, plus the confidence that the location is
region cannot be 100%. The total confidence depends on the outside the region is limited to the confidence of the location. The
confidence in the original location, which is always less than 100% total confidence depends on the confidence in the location, which is
(95% is recommended in [RFC5491]). The benefit of this is that always less than 100% (95% is recommended in [RFC5491]). The benefit
notifications are naturally limited: small movements at the borders of this is that notifications are naturally limited: small movements
of the region do not trigger notifications. at the borders of the region do not trigger notifications.
Figure 5 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 6 the Target enters or exits an area described by a circle and Figure 7
describes an area using a polygon. 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">
skipping to change at page 10, line 4 skipping to change at page 10, line 31
<gml:pos>42.5463 -73.2512</gml:pos> <gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius <gs:radius
uom="urn:ogc:def:uom:EPSG::9001"> uom="urn:ogc:def:uom:EPSG::9001">
850.24 850.24
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</lf:enterOrExit> </lf:enterOrExit>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 5: <enterOrExit> Circle Filter Example
Figure 6: <enterOrExit> Circle Filter Example
<?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">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<trigger> <trigger>
<lf:enterOrExit> <lf:enterOrExit>
skipping to change at page 10, line 40 skipping to change at page 11, line 39
<gml:pos>43.311 -73.422</gml:pos> <gml:pos>43.311 -73.422</gml:pos>
<!--A--> <!--A-->
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</lf:enterOrExit> </lf:enterOrExit>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 6: <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 and 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 LI in all forms
available to it. available to it.
skipping to change at page 11, line 49 skipping to change at page 12, line 46
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 7 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' 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">
<what> <what>
<lf:locationType exact="true"> geodetic <lf:locationType exact="true">
geodetic
</lf:locationType> </lf:locationType>
</what> </what>
</filter> </filter>
</filter-set> </filter-set>
Figure 7: <locationType> Filter Example Figure 8: <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] extends the SIP events
events framework defining the following three "Event" header field framework by 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, namely "min-interval" allows a subscriber to have overall control over the stream of
(which specifies a minimum notification time period between two notifications, for example to avoid being flooded. Two of the
notifications, in seconds) and "max-interval" (which specifies a parameters, namely "min-interval" (which specifies a minimum
maximum notification time period between two notifications, in notification time period between two notifications, in seconds) and
seconds.). The implementation of only these two attributes is "max-interval" (which specifies a maximum notification time period
required from the complete set of attributes defined in between two notifications, in seconds.) are used by this document.
The implementation of only these two attributes is required from the
complete set of attributes defined in
[I-D.ietf-sipcore-event-rate-control]. Whenever the time since the [I-D.ietf-sipcore-event-rate-control]. Whenever the time since the
most recent notification exceeds the value in the "max-interval" most recent notification exceeds the value in the "max-interval"
parameter, the current state would be sent in its entirety, just like parameter, the current state would be sent in its entirety, just like
after a subscription refresh. after a subscription refresh.
If complete state is not immediately available, then an empty NOTIFY If complete state is not immediately available, then an empty NOTIFY
is sent immediately and subsequently a separate NOTIFY containing is sent immediately and subsequently a separate NOTIFY containing
location is generated some time between the time included in 'min- location is generated some time between the time included in 'min-
interval' and the time in 'max-interval'. An important use case for interval' and the time in 'max-interval'. An important use case for
location based applications focuses on the behavior of the initial location based applications focuses on the behavior of the initial
skipping to change at page 13, line 13 skipping to change at page 14, line 13
might not include complete state. 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 9: SUBSCRIBE/NOTIFY with Rate Control
Figure 8 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 'max-interval' 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 at a later point in time. An example is emergency
call routing where a emergency services routing proxy may need to call routing where a emergency services routing proxy may need to
obtain location information suitable for routing rather quickly and obtain location information suitable for routing rather quickly and
subsequently a Public Safety Answering Point requests location subsequently a Public Safety Answering Point requests location
information for dispatch. information for dispatch.
skipping to change at page 15, line 17 skipping to change at page 16, line 17
<xs:complexType name="locationTypeType"> <xs:complexType name="locationTypeType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="filter:locationTypeBase"> <xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean" <xs:attribute name="exact" type="xs:boolean"
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 10: XML Schema
5. Security Considerations 5. Security Considerations
This document specifies one piece, namely filters, utilized in larger This document specifies one piece, namely filters, utilized in larger
system. As such, this document builds on a number of specifications system. As such, this document builds on a number of specifications
for the security of the complete solution, namely 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.
skipping to change at page 20, line 7 skipping to change at page 21, line 7
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, Carl Reed, Adam Roach, Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl
Allan Thomson, James Winterbottom for their comments. Reed, Adam Roach, Allan Thomson, James Winterbottom for their
comments.
Furthermore, we would like to thank Alexey Melnikov for his IESG
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>.
skipping to change at page 21, line 25 skipping to change at page 22, line 25
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-01 (work in progress), draft-ietf-geopriv-arch-01 (work in progress),
October 2009. 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-01 (work in draft-ietf-sipcore-event-rate-control-03 (work in
progress), November 2009. progress), February 2010.
[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.
skipping to change at page 22, line 28 skipping to change at page 23, line 28
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. January 2010.
[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-02 (work in
progress), July 2009. progress), February 2010.
[I-D.winterbottom-geopriv-held-context] [I-D.winterbottom-geopriv-held-context]
Winterbottom, J., Tschofenig, H., and M. Thomson, Winterbottom, J., Tschofenig, H., and M. Thomson,
"Location URI Contexts in HTTP-Enabled Location Delivery "Location URI Contexts in HTTP-Enabled Location Delivery
(HELD)", draft-winterbottom-geopriv-held-context-05 (work (HELD)", draft-winterbottom-geopriv-held-context-05 (work
in progress), October 2009. in progress), October 2009.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
 End of changes. 28 change blocks. 
68 lines changed or deleted 105 lines changed or added

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