[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-mahy-geopriv-loc-filters) 00
01 02 03 04 05 06 07 08 09 10 11 RFC 6447
GEOPRIV R. Mahy
Internet-Draft Individual
Intended status: Standards Track B. Rosen
Expires: July 1, 2010 NeuStar
H. Tschofenig
Nokia Siemens Networks
December 28, 2009
Filtering Location Notifications in the Session Initiation Protocol
(SIP)
draft-ietf-geopriv-loc-filters-09.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
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Mahy, et al. Expires July 1, 2010 [Page 1]
Internet-Draft Location Filters December 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 17
6.2. Schema Registration For location-filter . . . . . . . . . 17
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Mahy, et al. Expires July 1, 2010 [Page 2]
Internet-Draft Location Filters December 2009
1. Introduction
Conveying location information encapsulated with a PIDF-LO [RFC4119]
document within SIP is described in
[I-D.ietf-sipcore-location-conveyance]. An alternative signaling
approach, which uses asynchronous communication, is available with
the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This
document focuses on the event notification paradigm. Event
notifications are technical more complex since location may be
measured as a continuous gradient and unlike notifications using
discrete-valued quantities, it is difficult to know when a change in
location is large enough to warrant a notification. Event
notifications [RFC3265] can be used with filters (see RFC 4661
[RFC4661]) that allows the number of notifications to be reduced.
The mechanism described in this document defines an extension to RFC
4661 [RFC4661], which limits location notification to events that are
of relevance to the subscriber. These filters persist until they are
changed with a replacement filter.
The frequency of notifications necessary for various geographic
location applications varies dramatically. The subscriber should be
able to get asynchronous notifications with appropriate frequency and
granularity, without having to issue a large number of notifications
that are not important to the application.
This document defines a new event filters and describes others using
existing mechanisms that may be relevant to a subscriber in the
context of location filtering:
1. the Device moves more than a specified distance since the last
notification (see Section 3.1).
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
polygon (see Section 3.4).
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
example, the value of the <A1> civic address element has changed
from 'California' to 'Nevada'.
5. the type of location information being requested (see
Section 3.5).
6. the rate at which location information delivery is desired (see
Section 3.6).
Mahy, et al. Expires July 1, 2010 [Page 3]
Internet-Draft Location Filters December 2009
This document builds on the presence event package [RFC3856], i.e. an
existing event package for communicating location information inside
the PIDF-LO.
Mahy, et al. Expires July 1, 2010 [Page 4]
Internet-Draft Location Filters December 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses terminology from [I-D.ietf-geopriv-arch].
Mahy, et al. Expires July 1, 2010 [Page 5]
Internet-Draft Location Filters December 2009
3. Filter Definitions
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
thereby decrease the chance of interoperability problems), the
functionality of [RFC4661] listed in the sub-sections below MUST be
implemented, namely the <ns-bindings> (see Section 3.3 of [RFC4661]),
the <filter> (Section 3.4 of [RFC4661]), and the <trigger> (Section
3.6 of [RFC4661] excluding the functionality of the <added> and
<removed> element).
3.1. Movement
The <moved> element MUST contain a value in meters indicates the
minimum distance that the resource must have moved from the location
of the resource since the last notification was sent in order to
trigger this event. The distance MUST be measured in meters
absolutely from the point of last notification. The <moved> element
MUST NOT appear more than once as a child element of the <filter>
element.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>
Figure 1: Movement Filter Example
3.2. Speed Changes
Speed changes can be filtered with the help of RFC 4661 and the
functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which
extends the PIDF-LO with support for spatial orientation, speed,
heading, and acceleration. The value of <speed> in
[I-D.singh-geopriv-pidf-lo-dynamic] and MUST be defined in meters per
second.
Figure 2 shows an example for a trigger that fires when the speed of
the Target changes by 3 meters per second.
Mahy, et al. Expires July 1, 2010 [Page 6]
Internet-Draft Location Filters December 2009
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed by="3">
//dyn:speed
</changed>
</trigger>
</filter>
</filter-set>
Figure 2: Speed Change Example
An implementation MUST support the functionality as shown in Figure 2
with <ns-bindings> replacing the prefix. No other variant is
supported. The <changed> element comes with a few attributes but
only the 'by' attribute MUST be implemented by this specification.
3.3. Element Value Changes
Changes in values, for example related to civic location information,
is provided by the base functionality offered with RFC 4661 utilizing
the <changed> element.
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
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.
Mahy, et al. Expires July 1, 2010 [Page 7]
Internet-Draft Location Filters December 2009
<?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>
<changed>//ca:A2</changed>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 3: Speed Change Example
The following example illustrates a filter that triggers when the
Target's location changes from 'FR' (France) to some other country.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
Figure 4: Speed Change Example (Country Change)
An implementation MUST support the functionality as shown in Figure 3
with <ns-bindings> replacing the prefix. No other variant is
supported. The <changed> element comes with a few attributes and the
'by', 'to' and 'from' attribute MUST be implemented to support this
specification.
3.4. Entering or Exiting a Region
The <enterOrExit> condition is satisfied when the Target enters or
exits a named 2-dimensional region described by a polygon (as defined
in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section
Mahy, et al. Expires July 1, 2010 [Page 8]
Internet-Draft Location Filters December 2009
5.2.3 of [RFC5491]). The <enterOrExit> element MUST contain either a
polygon or a circle as a child element. The <enterOrExit> element
MUST NOT have more than one polygon and/or circle.
If the Target was previously outside the region, the notifier sends a
notification when the Target's location is within the region with at
least 50% confidence. Similarly, when a Target starts within the
region, a notification is sent when the Target's location moves
outside the region with at least 50% confidence.
Note that having 50% confidence that the Target is inside the area
does not correspond to 50% outside. Confidence that the location is
within the region, plus confidence that the location is outside the
region cannot be 100%. The total confidence depends on the
confidence in the original location, which is always less than 100%
(95% is recommended in [RFC5491]). The benefit of this is that
notifications are naturally limited: small movements at the borders
of the region do not trigger notifications.
Figure 5 shows filter examples whereby a notification is sent when
the Target enters or exits an area described by a circle and Figure 6
describes an area using a polygon.
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Mahy, et al. Expires July 1, 2010 [Page 9]
Internet-Draft Location Filters December 2009
Figure 5: <enterOrExit> Circle Filter Example
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 6: <enterOrExit> Polygon Filter Example
3.5. Location Type
The <locationType> element MAY be included as a child element of the
<what> element and it contains a list of location information types
that are requested by the subscriber. The following list describes
the possible values:
Mahy, et al. Expires July 1, 2010 [Page 10]
Internet-Draft Location Filters December 2009
any: The Notifier SHOULD attempt to provide LI in all forms
available to it.
geodetic: The Notifier SHOULD return a location by value in the form
of a geodetic location.
civic: The Notifier SHOULD return a location by value in the form of
a civic address.
The Notifier SHOULD return the requested location type or types. The
location types the Notifier returns also depends on the setting of
the optional 'exact' attribute. If the 'exact' attribute is set to
"true" then the Notifier MUST return either the requested location
type or no location information. The 'exact' attribute does not
apply (is ignored) for a request for a location type of "any".
In the case of a request for specific locationType(s) and the 'exact'
attribute is "false", the Notifier MAY provide additional location
types, or it MAY provide alternative types if the request cannot be
satisfied for a requested location type.
If the <locationType> element is absent, a value of "any" MUST be
assumed as the default.
The Notifier SHOULD provide location in the response in the same
order in which they were included in the "locationType" element in
the request. Indeed, the primary advantage of including specific
location types in a request when the 'exact' attribute is set to
"false" is to ensure that one receives the available locations in a
specific order. For example, a subscription for "civic" (with the
'exact' attribute set to "false") could yield any of the following
location types in the response:
o civic
o civic, geodetic
o geodetic (only if civic is not available)
The default value of "false" for the 'exact' attribute allows the
Notifier the option of returning something beyond what is specified,
such as a set of location URIs when only a civic location was
requested.
An example is shown in Figure 7 that utilizes the <locationType>
element with the 'exact' and the 'responseTime' attribute.
Mahy, et al. Expires July 1, 2010 [Page 11]
Internet-Draft Location Filters December 2009
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true"> geodetic
</lf:locationType>
</what>
</filter>
</filter-set>
Figure 7: <locationType> Filter Example
3.6. Rate Control
[I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP
events framework defining the following three "Event" header field
parameters that allow a subscriber to set a minimum, a maximum and an
average rate of event notifications generated by the notifier. This
document makes use of two of the parameters, namely "min-interval"
(which specifies a minimum notification time period between two
notifications, in seconds) and "max-interval" (which specifies a
maximum notification time period between two notifications, in
seconds.). 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
most recent notification exceeds the value in the "max-interval"
parameter, the current state would be sent in its entirety, just like
after a subscription refresh.
If complete state is not immediately available, then an empty NOTIFY
is sent immediately and subsequently a separate NOTIFY containing
location is generated some time between the time included in 'min-
interval' and the time in 'max-interval'. An important use case for
location based applications focuses on the behavior of the initial
NOTIFY message(s) and the information it returns, for example in case
of emergency call routing. When an initial NOTIFY is transmitted it
might not include complete state.
Mahy, et al. Expires July 1, 2010 [Page 12]
Internet-Draft Location Filters December 2009
Subscriber Notifier
|---SUBSCRIBE(1)--->| Request state subscription
|<-------200--------| Acknowledge subscription
|<-----NOTIFY(2)----| Return current state information
|-------200(3)----->|
|<-----NOTIFY(4)----| Return current state information
|--------200------->|
Figure 8: SUBSCRIBE/NOTIFY with Rate Control
Figure 8 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE
message (1) has filters attached and contains a 'max-interval' rate
control parameter. In certain situations it is important to obtain
some amount of location information within a relatively short and
pre-defined period of time even if the obtained location information
contains a high amount of uncertainty and location information with
less uncertainty at a later point in time. An example is emergency
call routing where a emergency services routing proxy may need to
obtain location information suitable for routing rather quickly and
subsequently a Public Safety Answering Point requests location
information for dispatch.
To obtain location information in a timely fashion using the
SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial
SUBSCRIBE contains a 'max-interval' rate control parameter (with a
small value) that is in a later message updated to a more sensible
value. The 'max-interval' for this first request is therefore much
lower than thereafter. Updating the 'max-interval' for the
subscription can be performed in the 200 response (see message 3) to
the NOTIFY that contains state. Depending on the value in the 'max-
interval' parameter the Notifier may create a NOTIFY message (see
message 2) immediately in response 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).
Mahy, et al. Expires July 1, 2010 [Page 13]
Internet-Draft Location Filters December 2009
4. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="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:gml="http://www.opengis.net/gml">
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="moved" type="filter:movedType"/>
<xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="locationType" type="filter:locationTypeType"/>
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="filter:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
Mahy, et al. Expires July 1, 2010 [Page 14]
Internet-Draft Location Filters December 2009
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Figure 9: XML Schema
Mahy, et al. Expires July 1, 2010 [Page 15]
Internet-Draft Location Filters December 2009
5. Security Considerations
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
[RFC3265], defining the SUBSCRIBE/NOTIFY messages.
o the presence event package, described in RFC 3856 [RFC3856], which
is a concrete instantiation of the general event notification
framework.
o the filter framework, described in RFC 4661 [RFC4661], to offer
the ability to reduce the amount of notifications being sent.
Finally, this document indirectly (via the SIP presence event
package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the
XML container that carries location information.
Each of these documents listed above comes with a security
consideration section but the security and privacy aspects are best
covered by the SIP presence event package, see Section 9 of
[RFC3856], and with the GEOPRIV architectural description found in
[I-D.ietf-geopriv-arch].
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
more recent work around HELD context
[I-D.winterbottom-geopriv-held-context]. Although
[I-D.ietf-geopriv-policy] defines a standardized format for
geolocation authorization policies it does not define specific
policies for controlling filters.
The functionality described in this document extends the filter
framework with location specific filters. Local policies might be
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.
Mahy, et al. Expires July 1, 2010 [Page 16]
Internet-Draft Location Filters December 2009
6. IANA Considerations
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:location-filter
Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>,
as delegated by the IESG <iesg@ietf.org>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Location Filter Namespace</title>
</head>
<body>
<h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
6.2. Schema Registration For location-filter
This specification registers a schema, as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:location-filter
Registrant Contact: IETF, GEOPRIV Working Group
(geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).
Mahy, et al. Expires July 1, 2010 [Page 17]
Internet-Draft Location Filters December 2009
XML: The XML can be found as the sole content of Section 4.
Mahy, et al. Expires July 1, 2010 [Page 18]
Internet-Draft Location Filters December 2009
7. Contributors
We would like to thank Martin Thomson and James Polk for their
contributions to this document.
Mahy, et al. Expires July 1, 2010 [Page 19]
Internet-Draft Location Filters December 2009
8. Acknowledgments
Thanks to Richard Barnes and Alissa Cooper, Carl Reed, Adam Roach,
Allan Thomson, James Winterbottom for their comments.
Mahy, et al. Expires July 1, 2010 [Page 20]
Internet-Draft Location Filters December 2009
9. References
9.1. Normative References
[GML] OpenGIS, "Open Geography Markup Language (GML)
Implementation Specification", OpenGIS OGC 02-023r4,
January 2003,
<http://www.opengis.org/techno/implementation.htm>.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress),
October 2009.
[I-D.ietf-sipcore-event-rate-control]
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for
Notification Rate Control",
draft-ietf-sipcore-event-rate-control-01 (work in
progress), November 2009.
[I-D.singh-geopriv-pidf-lo-dynamic]
Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress),
August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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
Event Notification", RFC 3265, June 2002.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
Mahy, et al. Expires July 1, 2010 [Page 21]
Internet-Draft Location Filters December 2009
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661,
September 2006.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
9.2. Informational References
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress),
July 2009.
[I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-01 (work in
progress), July 2009.
[I-D.winterbottom-geopriv-held-context]
Winterbottom, J., Tschofenig, H., and M. Thomson,
"Location URI Contexts in HTTP-Enabled Location Delivery
(HELD)", draft-winterbottom-geopriv-held-context-05 (work
in progress), October 2009.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
Mahy, et al. Expires July 1, 2010 [Page 22]
Internet-Draft Location Filters December 2009
Authors' Addresses
Rohan Mahy
Individual
Email: rohan@ekabal.com
Brian Rosen
NeuStar
470 Conrad Dr.
Mars, PA 16046
US
Phone: +1 724 382 1051
Email: br@brianrosen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Mahy, et al. Expires July 1, 2010 [Page 23]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/