draft-ietf-geopriv-loc-filters-10.txt   draft-ietf-geopriv-loc-filters-11.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: September 7, 2010 NeuStar Expires: September 28, 2010 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
March 6, 2010 March 27, 2010
Filtering Location Notifications in the Session Initiation Protocol Filtering Location Notifications in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-geopriv-loc-filters-10.txt 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, 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 September 7, 2010. This Internet-Draft will expire on September 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . 9 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 10
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 14
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 18 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 19
6.2. Schema Registration For location-filter . . . . . . . . . 18 6.2. Schema Registration For location-filter . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informational References . . . . . . . . . . . . . . . . . 23 9.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Conveying location information encapsulated with a PIDF-LO [RFC4119] Conveying location information encapsulated with a Presence
document within SIP is described in Information Data Format Location Object (PIDF-LO) [RFC4119] document
[I-D.ietf-sipcore-location-conveyance]. An alternative signaling within SIP is described in [I-D.ietf-sipcore-location-conveyance].
approach, which uses asynchronous communication, is available with An alternative signaling approach to location conveyance, which uses
the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This asynchronous communication, is available with the SIP event
document focuses on the event notification paradigm. Event notification mechanisms (see RFC 3265 [RFC3265]). This document
notifications are technical more complex since location may be focuses on the event notification paradigm. Event notifications are
measured as a continuous gradient and unlike notifications using technically more complex since location may be measured as a
discrete-valued quantities, it is difficult to know when a change in continuous gradient and unlike notifications using discrete-valued
location is large enough to warrant a notification. Event quantities, it is difficult to know when a change in location is
notifications [RFC3265] can be used with filters (see RFC 4661 large enough to warrant a notification. Event notifications
[RFC4661]) that allows the number of notifications to be reduced. [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that
The mechanism described in this document defines an extension to RFC allow the number of notifications to be reduced. The mechanism
4661 [RFC4661], which limits location notification to events that are described in this document defines an extension to RFC 4661
of relevance to the subscriber. These filters persist until they are [RFC4661], which limits location notification to events that are of
changed with a replacement filter. relevance to the subscriber. These filters persist until they are
changed with a replacement filter or when the subscription itself is
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 having to issue a large number of notifications granularity, without being flooded with a large number of
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 a 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: context of location filtering. Based on the functionality defined in
this document notifications can be provided in the following cases:
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 (see Section 3.1). notification (see Section 3.1).
2. the Device exceeds a specified speed (see Section 3.2). 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 (see Section 3.4). 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 (see Section 3.3). For changed for the location of the Device (see Section 3.3). For
example, the value of the <A1> civic address element has changed example, the value of the <A1> civic address element has changed
from 'California' to 'Nevada'. from 'California' to 'Nevada'.
5. the type of location information being requested (see 5. the type of location information being requested (see
Section 3.5). Section 3.5).
6. the rate at which location information delivery is desired (see 6. a certain amount of time passes (see Section 3.6).
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.
existing event package for communicating location information inside an existing event package for communicating location information
the PIDF-LO. 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 [I-D.ietf-geopriv-arch].
3. Filter Definitions 3. Filter Definitions
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. Note that the condition could be met by a change trigger this event. The distance MUST be measured in meters
in any axis including altitude. The distance MUST be measured in absolutely from the point of last notification, and must include
meters absolutely from the point of last notification. The <moved> vertical movement. The <moved> element MUST NOT appear more than
element MUST NOT appear more than once as a child element of the once as a child element of the <filter> element.
<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>
skipping to change at page 7, line 22 skipping to change at page 7, line 22
<trigger> <trigger>
<changed by="3"> <changed by="3">
//dyn:speed //dyn:speed
</changed> </changed>
</trigger> </trigger>
</filter> </filter>
</filter-set> </filter-set>
Figure 2: Speed Change Example Figure 2: Speed Change Example
An implementation MUST support the functionality as shown in Figure 2 An implementation MUST support <ns-bindings> to replace the namespace
with <ns-bindings> replacing the prefix. No other variant is prefix. The XPath expression MUST start with a '//' followed by a
supported. The <changed> element comes with a few attributes but single element. No other form of XPath expression is supported. The
only the 'by' attribute MUST be implemented by this specification. <changed> element comes with a few attributes but 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 four must change in address tokens A1, A2, A3, and PC change (all four must change in
order to let the <trigger> element evaluate to TRUE). 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>//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: Element Value Change Example Figure 3: Element Value Change Example
In times where it is desireable to know if any one element of a list 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
of CAtypes changes, then they have to be put into separate <changes> of 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 you are notified when any of the element values
change. Figure 4 shows such an example that illustrates the 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.)
<?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>
</trigger>
<trigger>
<changed>//ca:A1</changed> <changed>//ca:A1</changed>
</trigger> </trigger>
<trigger> <trigger>
<changed>//ca:A2</changed> <changed>//ca:A2</changed>
</trigger> </trigger>
<trigger> <trigger>
<changed>//ca:A3</changed> <changed>//ca:A3</changed>
</trigger> </trigger>
<trigger> <trigger>
<changed>//ca:PC</changed> <changed>//ca:PC</changed>
skipping to change at page 9, line 23 skipping to change at page 10, line 5
</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 5: Element Value 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 <ns-bindings> to replace the namespace
with <ns-bindings> replacing the prefix. No other variant is prefix. The XPath expression MUST start with a '//' followed by a
supported. The <changed> element comes with a few attributes and the single element. No other form of XPath expression is supported. No
'by', 'to' and 'from' attribute MUST be implemented to support this other variant is supported. The <changed> element comes with a few
specification. attributes and the 'by', 'to' and 'from' attribute MUST be
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 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 contain either a 5.2.3 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.
skipping to change at page 9, line 51 skipping to change at page 10, line 34
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
at the borders of the region do not trigger notifications. (relative to the uncertainty of the location) at the borders of the
region do not trigger notifications.
Figure 6 shows filter examples whereby a notification is sent when 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 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"
skipping to change at page 13, line 32 skipping to change at page 14, line 32
[I-D.ietf-sipcore-event-rate-control] extends the SIP events [I-D.ietf-sipcore-event-rate-control] extends the SIP events
framework by 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
allows a subscriber to have overall control over the stream of allows a subscriber to have overall control over the stream of
notifications, for example to avoid being flooded. Two of the notifications, for example to avoid being flooded. Two of the
parameters, namely "min-interval" (which specifies a minimum parameters, namely "min-interval" (which specifies a minimum
notification time period between two notifications, in seconds) and notification time period between two notifications, in seconds) and
"max-interval" (which specifies a maximum notification time period "max-interval" (which specifies a maximum notification time period
between two notifications, in seconds.) are used by this document. between two notifications, in seconds.) are used by this document.
The implementation of only these two attributes is required from the Only the implementation of these two attributes is required from the
complete set of attributes defined in 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, the current state would be
parameter, 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.
If complete state is not immediately available, then an empty NOTIFY A notifier is required to send a NOTIFY request immediately after
is sent immediately and subsequently a separate NOTIFY containing creation of a subscription. If state is not available at that time,
location is generated some time between the time included in 'min- then the NOTIFY request may be sent with no content. A separate
interval' and the time in 'max-interval'. An important use case for NOTIFY containing location is subsequently generated some time
location based applications focuses on the behavior of the initial between the time included in 'min-interval' and the time in 'max-
NOTIFY message(s) and the information it returns, for example in case interval'. An important use case for location based applications
of emergency call routing. When an initial NOTIFY is transmitted it focuses on the behavior of the initial NOTIFY message(s) and the
might not include complete state. information it returns, for example in case 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)--->| Create subscription (w/small value
|<-------200--------| Acknowledge subscription |<-------200--------| for min-interval and max-interval)
|<-----NOTIFY(2)----| Return current state information |<-----NOTIFY(2)----| Return initial notify with no state
|-------200(3)----->| |--------200------->|
|<-----NOTIFY(4)----| Return current state information |<-----NOTIFY(3)----| Return full state (between min-interval
|--------200------->| |--------200------->| and max-interval)
|---SUBSCRIBE(4)--->| Update subscription (to update
|<-------200--------| min-interval and max-interval)
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 '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.
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 contains a 'max-interval' rate control parameter (with a
small value) that is in a later message updated to a more sensible small value) that is in a later message updated to a more sensible
value. The 'max-interval' for this first request is therefore much value. This provides equivalent functionality to the 'responseTime'
lower than thereafter. Updating the 'max-interval' for the attribute in Section 6.1 of
subscription can be performed in the 200 response (see message 3) to [I-D.ietf-geopriv-http-location-delivery]. The 'max-interval' for
the NOTIFY that contains state. Depending on the value in the 'max- this first request is therefore much lower than thereafter. Updating
interval' parameter the Notifier may create a NOTIFY message (see the 'max-interval' for the subscription can be performed in the 200
message 2) immediately in response to the SUBSCRIBE that might be response (see message 3) to the NOTIFY that contains state.
empty in case no location information is available at this point in Depending on the value in the 'max-interval' parameter the Notifier
time. The desired location information may then arrive in the may create a NOTIFY message (see message 2) immediately in response
subsequent NOTIFY message (see message 4). to the SUBSCRIBE that might be empty in case no location information
is available at this point in time. The desired location information
may then arrive in the subsequent NOTIFY message (see 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 21, line 8 skipping to change at page 22, line 8
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 and Alissa Cooper, Randall Gellens, Carl
Reed, Adam Roach, Allan Thomson, James Winterbottom for their Reed, Ben Campbell, Adam Roach, Allan Thomson, James Winterbottom for
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,
skipping to change at page 22, line 32 skipping to change at page 23, line 32
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-03 (work in draft-ietf-sipcore-event-rate-control-03 (work in
progress), February 2010. 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-09 (work in progress),
August 2009. March 2010.
[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
Types", RFC 3023, January 2001.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661, for Event Notification Filtering", RFC 4661,
September 2006. September 2006.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
 End of changes. 29 change blocks. 
99 lines changed or deleted 115 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/