GEOPRIV                                                          R. Mahy
Internet-Draft                                                Individual
Intended status: Standards Track                                B. Rosen
Expires: September 7, 28, 2010                                      NeuStar
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                          March 6, 27, 2010

  Filtering Location Notifications in the Session Initiation Protocol


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 7, 28, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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 . . . . . . . . . . . . . . .  9 10
     3.5.  Location Type  . . . . . . . . . . . . . . . . . . . . . . 11 12
     3.6.  Rate Control . . . . . . . . . . . . . . . . . . . . . . . 13 14
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18 19
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 18 19
     6.2.  Schema Registration For location-filter  . . . . . . . . . 18 19
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22 23
     9.2.  Informational References . . . . . . . . . . . . . . . . . 23 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 25

1.  Introduction

   Conveying location information encapsulated with a PIDF-LO Presence
   Information Data Format Location Object (PIDF-LO) [RFC4119] document
   within SIP is described in [I-D.ietf-sipcore-location-conveyance].
   An alternative signaling
   approach, approach to location conveyance, 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
   technically 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
   allow 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. filter or when the subscription itself is

   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 being flooded with 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: 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
       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  a certain amount of time passes (see Section 3.6).

   This document builds on the presence event package [RFC3856], i.e. i. e.
   an existing event package for communicating location information
   inside the PIDF-LO.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document reuses terminology from [I-D.ietf-geopriv-arch].

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.  Note that the condition could be met by a change
   in any axis including altitude.  The distance MUST be measured in meters
   absolutely from the point of last notification. notification, and must include
   vertical movement.  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 id="123" uri="">

                     Figure 1: Movement Filter Example

3.2.  Speed Changes

   Speed changes can be filtered by combining functionality from RFC
   4661 with the PIDF-LO extensions for spatial orientation, speed,
   heading, and acceleration defined in
   [I-D.singh-geopriv-pidf-lo-dynamic].  The value of the <speed>
   element from [I-D.singh-geopriv-pidf-lo-dynamic] MUST be defined in
   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
   the Target changes by 3 meters per second.

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
           <ns-binding prefix="dyn"
       <filter id="123" uri="">
               <changed by="3">

                      Figure 2: Speed Change Example

   An implementation MUST support the functionality as shown in Figure 2
   with <ns-bindings> replacing to replace the namespace
   prefix.  The XPath expression MUST start with a '//' followed by a
   single element.  No other variant form of XPath expression 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 and PC change (all four must change in
   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"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
           <ns-binding prefix="ca"
       <filter id="123" uri="">

                  Figure 3: Element Value Change Example

   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 desireable desirable 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

   (A change in value of ANY of the four tokens triggers an event.)

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
           <ns-binding prefix="ca"
       <filter id="123" uri="">

                  Figure 4: Element Value 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-binding prefix="ca"
       <filter id="123" uri="">
               <changed from="FR">//ca:country</changed>

          Figure 5: Element Value Change Example (Country Change)

   An implementation MUST support the functionality as shown in Figure 3
   with <ns-bindings> replacing to replace the namespace
   prefix.  The XPath expression MUST start with a '//' followed by a
   single element.  No other form of XPath expression is supported.  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
   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.  The confidence that the location
   is within the region, plus the confidence that the location is
   outside the region is limited to the confidence of the location.  The
   total confidence depends on the confidence in the location, which is
   always less than 100% (95% is recommended in [RFC5491]).  The benefit
   of this is that notifications are naturally limited: small movements
   (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
   the Target enters or exits an area described by a circle and Figure 7
   describes an area using a polygon.

   <?xml version="1.0" encoding="UTF-8"?>

       <filter id="123" uri="">
                       <gml:pos>42.5463 -73.2512</gml:pos>

               Figure 6: <enterOrExit> Circle Filter Example

   <?xml version="1.0" encoding="UTF-8"?>

       <filter id="123" uri="">
                   <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                               <gml:pos>43.311 -73.422</gml:pos>
                               <gml:pos>43.111 -73.322</gml:pos>
                               <gml:pos>43.111 -73.222</gml:pos>
                               <gml:pos>43.311 -73.122</gml:pos>
                               <gml:pos>43.411 -73.222</gml:pos>
                               <gml:pos>43.411 -73.322</gml:pos>
                               <gml:pos>43.311 -73.422</gml:pos>

              Figure 7: <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:

   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

   An example is shown in Figure 8 that utilizes the <locationType>
   element with the 'exact' and the 'responseTime' attribute.

   <?xml version="1.0" encoding="UTF-8"?>
       <filter id="123" uri="">
               <lf:locationType exact="true">

                  Figure 8: <locationType> Filter Example

3.6.  Rate Control

   [I-D.ietf-sipcore-event-rate-control] extends the SIP events
   framework by 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
   allows a subscriber to have overall control over the stream of
   notifications, for example to avoid being flooded.  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.) are used by this document.
   Only 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.

   A notifier is required to send a NOTIFY request immediately after
   creation of a subscription.  If complete state is not immediately available, available at that time,
   then an empty the NOTIFY
   is request may be sent immediately and subsequently a with no content.  A separate
   NOTIFY containing location is subsequently generated some time
   between the time included in 'min-
   interval' 'min-interval' and the time in 'max-interval'. '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     Create subscription (w/small value
       |<-------200--------|     Acknowledge subscription         for min-interval and max-interval)
       |<-----NOTIFY(2)----|     Return current initial notify with no state information
       |<-----NOTIFY(3)----|     Return current full state information (between min-interval
       |--------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 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.  This provides equivalent functionality to the 'responseTime'
   attribute in Section 6.1 of
   [I-D.ietf-geopriv-http-location-delivery].  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' '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

  <?xml version="1.0" encoding="UTF-8"?>

      <xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>

      <xs:element name="moved" type="filter:movedType"/>

      <xs:complexType name="movedType">
            <xs:extension base="xs:double">
              <xs:anyAttribute namespace="##any" processContents="lax"/>

      <xs:element name="locationType" type="filter:locationTypeType"/>

      <xs:simpleType name="locationTypeBase">
                  <xs:restriction base="xs:token">
                      <xs:enumeration value="any"/>
                  <xs:restriction base="filter:locationTypeList">
                      <xs:minLength value="1"/>

      <xs:simpleType name="locationTypeList">
                  <xs:restriction base="xs:token">
                      <xs:enumeration value="civic"/>
                      <xs:enumeration value="geodetic"/>


      <xs:complexType name="locationTypeType">
                <xs:extension base="filter:locationTypeBase">
                    <xs:attribute name="exact" type="xs:boolean"
                        use="optional" default="false"/>

                           Figure 10: XML Schema

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

   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

   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.

6.  IANA Considerations

6.1.  URN Sub-Namespace Registration for

   This section registers a new XML namespace, as per the guidelines in

   URI:  urn:ietf:params:xml:ns:location-filter

   Registrant Contact:  IETF, GEOPRIV working group, <>,
      as delegated by the IESG <>.


   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
   <html xmlns="">
     <meta http-equiv="content-type"
     <title>Location Filter Namespace</title>
     <h1>Namespace for PIDF-LO Location Filters</h1>
     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>

6.2.  Schema Registration For location-filter

   This specification registers a schema, as per the guidelines in

      URI: urn:ietf:params:xml:schema:location-filter

      Registrant Contact: IETF, GEOPRIV Working Group
      (, as delegated by the IESG (

      XML: The XML can be found as the sole content of Section 4.

7.  Contributors

   We would like to thank Martin Thomson and James Polk for their
   contributions to this document.

8.  Acknowledgments

   Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl
   Reed, Ben Campbell, 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.1.  Normative References

   [GML]      OpenGIS, "Open Geography Markup Language (GML)
              Implementation Specification", OpenGIS OGC 02-023r4,
              January 2003,

              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.

              Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
              Protocol (SIP) Event Notification Extension for
              Notification Rate Control",
              draft-ietf-sipcore-event-rate-control-03 (work in
              progress), February 2010.

              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-09 (work in progress),
              August 2009.
              March 2010.

   [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.

   [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

              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.

              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),
              January 2010.

              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sipcore-location-conveyance-02 (work in
              progress), February 2010.

              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.

Authors' Addresses

   Rohan Mahy


   Brian Rosen
   470 Conrad Dr.
   Mars, PA  16046

   Phone: +1 724 382 1051

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445