draft-ietf-geopriv-loc-filters-05.txt   draft-ietf-geopriv-loc-filters-06.txt 
GEOPRIV R. Mahy GEOPRIV R. Mahy
Internet-Draft Plantronics Internet-Draft Plantronics
Intended status: Standards Track B. Rosen, Ed. Intended status: Standards Track B. Rosen, Ed.
Expires: January 28, 2010 NeuStar Expires: March 19, 2010 NeuStar
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 27, 2009 September 15, 2009
A Document Format for Filtering and Reporting Location Notications in A Document Format for Filtering and Reporting Location Notications in
the Presence Information Document Format Location Object (PIDF-LO) the Presence Information Document Format Location Object (PIDF-LO)
draft-ietf-geopriv-loc-filters-05.txt draft-ietf-geopriv-loc-filters-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 28, 2010. This Internet-Draft will expire on March 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 6 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 6
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 8
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 14 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 15
6.2. Schema Registration For location-filter . . . . . . . . . 14 6.2. Schema Registration For location-filter . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informational References . . . . . . . . . . . . . . . . . 18 9.2. Informational References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Conveying location in PIDF-LO [RFC4119] bodies is described in Conveying location information encapsulated with a PIDF-LO [RFC4119]
[I-D.ietf-sip-location-conveyance]. Asynchronous notification of document within SIP is described in
location information is unfortunately more complex since many forms [I-D.ietf-sipcore-location-conveyance]. An alternative signaling
of location are measured as a continuous gradient. Unlike approach, which uses asynchronous communication, is available with
the SIP event notification mechanisms (see RFC 3265 [RFC3265]) and is
used by this document. Unfortunately, it is more complex since many
forms of location are measured as a continuous gradient. Unlike
notifications using discret quantities, it is difficult to know when notifications using discret quantities, it is difficult to know when
a change in location is large enough to warrant a notification. The a change in location is large enough to warrant a notification. RFC
mechanism described in this document defines filters as an extension 3265 can be used with so-called 'filters' (see RFC 4661 [RFC4661])
to RFC 4661 [RFC4661], which limits location notification to events that allow the number of notifications to be reduced. The mechanism
that are of relevance to the subscriber. These filters persist until described in this document defines an extension to RFC 4661
they are changed with a replacement filter. [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 The frequency of notifications necessary for various geographic
location applications varies dramatically. The subscriber should be location applications varies dramatically. The subscriber should be
able to get asynchronous notifications with appropriate frequency and able to get asynchronous notifications with appropriate frequency and
granularity, without having to issue a large number of notifications granularity, without having to issue a large number of notifications
that are not important to the application. that are not important to the application.
This document defines the following as an initial list of events that This document defines the following list of events that may be
are relevant to a subscriber: relevant to a subscriber:
1. the Target moves more than a specified distance since the last 1. the Device moves more than a specified distance since the last
notification notification
2. the Target exceeds a specified speed 2. the Device exceeds a specified speed
3. the Target enters or exits a region (described by a circle or a 3. the Device enters or exits a region (described by a circle or a
polygon) polygon)
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 Target. For example, the value changed for the location of the Device. For example, the value
of the <A1> civic address element has changed from 'California' of the <A1> civic address element has changed from 'California'
to 'Nevada'. to 'Nevada'.
5. the type of location information being requested. 5. the type of location information being requested.
6. the rate at which location information delivery is desired.
This document builds on the presence event package' [RFC3856], i.e.
an existing event package for communicating location information
inside the PIDF-LO.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses terminology from [I-D.ietf-geopriv-arch].
3. Filter Definitions 3. Filter Definitions
3.1. Movement 3.1. Movement
The <moved> element with a value in meters indicates the minimum The <moved> element with a value in meters indicates the minimum
distance that the resource must have moved from the location of the distance that the resource must have moved from the location of the
resource when the last notification was sent in order to trigger this resource when the last notification was sent in order to trigger this
event. The distance is measured in meters absolutely from the point event. The distance is measured in meters absolutely from the point
of last notification rather than in terms of cumulative motion. The of last notification rather than in terms of cumulative motion. The
<moved> element MUST only appear once as a child element of <filter>. <moved> element MUST only appear once as a child element of <filter>.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
As stated above, the <locationType> element MAY carry the 'exact' As stated above, the <locationType> element MAY carry the 'exact'
attribute. When the 'exact' attribute is set to "true", it indicates attribute. When the 'exact' attribute is set to "true", it indicates
to the Notifier that the contents of the <locationType> element MUST to the Notifier that the contents of the <locationType> element MUST
be strictly followed. The default value of "false" allows the be strictly followed. The default value of "false" allows the
Notifier the option of returning something beyond what is specified, Notifier the option of returning something beyond what is specified,
such as a set of location URIs when only a civic location was such as a set of location URIs when only a civic location was
requested. A value of "true" indicates that the Notifier MUST requested. A value of "true" indicates that the Notifier MUST
provide a location of the requested type or types or MUST provide an provide a location of the requested type or types or MUST provide an
error. error.
The <locationType> element MAY carry another attribute, the
'responseTime' attribute, to provide a time value indicating to the
Notifier how long the Subscriber is prepared to wait for a response
or a purpose for which the Subscriber needs the location. The former
functionality is more useful for a single SUBSCRIBE / NOTIFY
interaction.
In the case of emergency services, the purpose of obtaining the
location information could be either for routing a call to the
appropriate Public Safety Answering Point (PSAP) or indicating the
location to which responders should be dispatched. The values
defined for the purpose, "emergencyRouting" and "emergencyDispatch",
will likely be governed by jurisdictional policies, and should be
configurable on the Notifier.
The time value in the 'responseTime' attribute is expressed as a non-
negative integer in units of milliseconds. The time value is
indicative only and the Notifier is under no obligation to strictly
adhere to the time limit implied; any enforcement of the time limit
is left to the requesting Subscriber. The Notifier provides the most
accurate location information that can be determined within the
specified interval for the specific service.
The Notifier may use the value of the time in the 'responseTime'
attribute as input when selecting the method of location
determination, where multiple such methods exist. If the
'responseTime' attribute is absent, then the Notifier should return
the most precise location information it is capable of determining,
with the time interval being implementation dependent.
An example is shown in Figure 6 that utilizes the <locationType> An example is shown in Figure 6 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:ext="urn:ietf:params:xml:ns:location-filter"> xmlns:ext="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com"> <filter id="123" uri="sip:presentity@example.com">
<ext:locationType exact="true" responseTime="emergencyRouting"> <ext:locationType exact="true">
geodetic geodetic
</ext:locationType> </ext:locationType>
</filter> </filter>
</filter-set> </filter-set>
Figure 6: <locationType> Filter Example Figure 6: <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 to accomplish
functionality equivalent to the 'responseTime' attribute used in HELD
[I-D.ietf-geopriv-http-location-delivery], namely "min-interval"
(which specifies a minimum notification time period between two
notifications, in seconds) and "max-interval" (which specifies a
maximum notification time period between two notifications, in
seconds.). Whenever the time since the most recent notification
exceeds the value in the "max-interval" parameter, then the current
state would be sent in its entirety, just like after a subscription
refresh.
If complete state is not immediately available, a NOTIFY containing
state (i.e. 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.
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 7: SUBSCRIBE/NOTIFY with Rate Control
Figure 7 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 withy
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).
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">
<!-- These elements are child elements of the RFC 4661 <!-- These elements are child elements of the RFC 4661
skipping to change at page 12, line 15 skipping to change at page 13, line 15
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
<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:attribute name="responseTime"
type="filter:responseTimeType"
use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="responseTimeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="emergencyRouting"/>
<xs:enumeration value="emergencyDispatch"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema> </xs:schema>
Figure 7: XML Schema Figure 8: XML Schema
5. Security Considerations 5. Security Considerations
Location information is typically very privacy sensitive. As such, This document builds on a number of specifications, namely
notifications MUST be encrypted and integrity protected.
Additional privacy and security considerations are discussed in o the SIP event notification mechanism, described in RFC 3265
detail in [RFC5491]. [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 PIDF-LO, described in RFC 4119 [RFC4119], as the XML container
that carries location information. PIDF payloads are exchanged
via the presence event package and the location object extension
of it provides the necessary functionality for this document.
o the filter framework, described in RFC 4661 [RFC4661], to offer
the ability to reduce the amount of notifications being sent.
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 for uploading
authorization policies and other information that 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]. 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.
6. IANA Considerations 6. IANA Considerations
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:location-filter URI: urn:ietf:params:xml:ns:location-filter
skipping to change at page 17, line 7 skipping to change at page 18, 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 Allan Thomson, James Winterbottom, Richard Barnes and Thanks to Richard Barnes and Alissa Cooper, Adam Roach, Allan
Alissa Cooper for their comments. Thomson, James Winterbottom for their comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[GML] OpenGIS, "Open Geography Markup Language (GML) [GML] OpenGIS, "Open Geography Markup Language (GML)
Implementation Specification", OpenGIS OGC 02-023r4, Implementation Specification", OpenGIS OGC 02-023r4,
January 2003, January 2003,
<http://www.opengis.org/techno/implementation.htm>. <http://www.opengis.org/techno/implementation.htm>.
[I-D.ietf-geopriv-arch]
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-00 (work in progress), July 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-00 (work in
progress), May 2009.
[I-D.singh-geopriv-pidf-lo-dynamic] [I-D.singh-geopriv-pidf-lo-dynamic]
Schulzrinne, H., Singh, V., Tschofenig, H., and M. Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-06 (work in progress), draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress),
June 2009. August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
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 [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 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. 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.
9.2. Informational References 9.2. Informational References
[I-D.ietf-sip-location-conveyance] [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 Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sipcore-location-conveyance-01 (work in
March 2009. progress), July 2009.
[I-D.winterbottom-geopriv-held-context]
Winterbottom, J., Tschofenig, H., and M. Thomson,
"Establishing Location URI Contexts using HTTP-Enabled
Location Delivery (HELD)",
draft-winterbottom-geopriv-held-context-04 (work in
progress), April 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.
[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.
Authors' Addresses Authors' Addresses
Rohan Mahy Rohan Mahy
Plantronics Plantronics
345 Encincal Street 345 Encincal Street
Santa Cruz, CA Santa Cruz, CA
USA USA
Email: rohan@ekabal.com Email: rohan@ekabal.com
 End of changes. 30 change blocks. 
93 lines changed or deleted 185 lines changed or added

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