[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                                               Plantronics
Intended status: Standards Track                           B. Rosen, Ed.
Expires: March 19, 2010                                          NeuStar
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                      September 15, 2009


 A Document Format for Filtering and Reporting Location Notications in
   the Presence Information Document Format Location Object (PIDF-LO)
                 draft-ietf-geopriv-loc-filters-06.txt

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 March 19, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Mahy, et al.             Expires March 19, 2010                 [Page 1]


Internet-Draft           Location Event Filters           September 2009


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".  The
   resulting location information is conveyed in existing location
   formats wrapped in the Presence Information Document Format
   (PIDF-LO).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Filter Definitions . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Movement . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Speed Changes  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Element Value Changes  . . . . . . . . . . . . . . . . . .  6
     3.4.  Entering or Exiting a Region . . . . . . . . . . . . . . .  6
     3.5.  Location Type  . . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Rate Control . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 15
     6.2.  Schema Registration For location-filter  . . . . . . . . . 15
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informational References . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21


















Mahy, et al.             Expires March 19, 2010                 [Page 2]


Internet-Draft           Location Event Filters           September 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]) 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
   a change in location is large enough to warrant a notification.  RFC
   3265 can be used with so-called 'filters' (see RFC 4661 [RFC4661])
   that 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.

   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 the following list of events that may be
   relevant to a subscriber:

   1.  the Device moves more than a specified distance since the last
       notification

   2.  the Device exceeds a specified speed

   3.  the Device enters or exits a region (described by a circle or a
       polygon)

   4.  one or more of the values of the specified address labels have
       changed for the location of the Device.  For example, the value
       of the <A1> civic address element has changed from 'California'
       to 'Nevada'.

   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.




Mahy, et al.             Expires March 19, 2010                 [Page 3]


Internet-Draft           Location Event Filters           September 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 March 19, 2010                 [Page 4]


Internet-Draft           Location Event Filters           September 2009


3.  Filter Definitions

3.1.  Movement

   The <moved> element with a value in meters indicates the minimum
   distance that the resource must have moved from the location of the
   resource when the last notification was sent in order to trigger this
   event.  The distance is measured in meters absolutely from the point
   of last notification rather than in terms of cumulative motion.  The
   <moved> element MUST only appear once as a child element of <filter>.


   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set
       xmlns="urn:ietf:params:xml:ns:simple-filter"
       xmlns:ext="urn:ietf:params:xml:ns:location-filter">
       <filter id="123" uri="sip:presentity@example.com">
           <ext:moved>300</ext:moved>
       </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.

   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 March 19, 2010                 [Page 5]


Internet-Draft           Location Event Filters           September 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

3.3.  Element Value Changes

   Changes in values, for example related to civic location information,
   can be provided by the base functionality offered with RFC 4661.
   Figure 3 shows an example where a notification is sent when the civic
   address tokens A1, A2, A3, or PC change.


   <?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

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 March 19, 2010                 [Page 6]


Internet-Draft           Location Event Filters           September 2009


   5.2.3 of [RFC5491]).

   Figure 4 shows filter examples whereby a notification is sent when
   the Target enters or exits an area described by a circle and Figure 5
   describes an area using a polygon.


   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set
       xmlns="urn:ietf:params:xml:ns:simple-filter"
       xmlns:ext="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">
           <ext: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>
           </ext:enterOrExit>
       </filter>
   </filter-set>

               Figure 4: <enterOrExit> Circle Filter Example
























Mahy, et al.             Expires March 19, 2010                 [Page 7]


Internet-Draft           Location Event Filters           September 2009


   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
       xmlns:ext="urn:ietf:params:xml:ns:location-filter"
       xmlns:gml="http://www.opengis.net/gml">

       <filter id="123" uri="sip:presentity@example.com">
           <ext:enterOrExit>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                   <gml:exterior>
                       <gml:LinearRing>
                           <gml:posList>
                           43.311 -73.422 43.111 -73.322
                           43.111 -73.222 43.311 -73.122
                           43.411 -73.222 43.411 -73.322
                           43.311 -73.422
                       </gml:posList>
                       </gml:LinearRing>
                   </gml:exterior>
               </gml:Polygon>
           </ext:enterOrExit>
       </filter>
   </filter-set>

              Figure 5: <enterOrExit> Polygon Filter Example

3.5.  Location Type

   The <locationType> element MAY be included as a child element of the
   <filter> 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 LIS returns also depend 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 provide an error response.  The 'exact' attribute does not
   apply (is ignored) for a request for a location type of "any".




Mahy, et al.             Expires March 19, 2010                 [Page 8]


Internet-Draft           Location Event Filters           September 2009


   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.  The "SHOULD"-strength
   requirements on this parameter for specific location types are
   included to allow for soft-failover.

   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)

   For the example above, if the 'exact' attribute was "true", then the
   only possible response is either a "civic" location or an error
   message.

   As stated above, the <locationType> element MAY carry the 'exact'
   attribute.  When the 'exact' attribute is set to "true", it indicates
   to the Notifier that the contents of the <locationType> element MUST
   be strictly followed.  The default value of "false" 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.  A value of "true" indicates that the Notifier MUST
   provide a location of the requested type or types or MUST provide an
   error.

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










Mahy, et al.             Expires March 19, 2010                 [Page 9]


Internet-Draft           Location Event Filters           September 2009


   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set
       xmlns="urn:ietf:params:xml:ns:simple-filter"
       xmlns:ext="urn:ietf:params:xml:ns:location-filter">
       <filter id="123" uri="sip:presentity@example.com">
           <ext:locationType exact="true">
                 geodetic
           </ext:locationType>
       </filter>
   </filter-set>

                  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



Mahy, et al.             Expires March 19, 2010                [Page 10]


Internet-Draft           Location Event Filters           September 2009


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




























Mahy, et al.             Expires March 19, 2010                [Page 11]


Internet-Draft           Location Event Filters           September 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">

      <!-- These elements are child elements of the RFC 4661
           <filter> element.
      -->

      <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"/>



Mahy, et al.             Expires March 19, 2010                [Page 12]


Internet-Draft           Location Event Filters           September 2009


                      <xs:enumeration value="geodetic"/>
                  </xs:restriction>
              </xs:simpleType>
          </xs:list>
      </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 8: XML Schema


































Mahy, et al.             Expires March 19, 2010                [Page 13]


Internet-Draft           Location Event Filters           September 2009


5.  Security Considerations

   This document builds on a number of specifications, 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  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.


















Mahy, et al.             Expires March 19, 2010                [Page 14]


Internet-Draft           Location Event Filters           September 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 March 19, 2010                [Page 15]


Internet-Draft           Location Event Filters           September 2009


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


















































Mahy, et al.             Expires March 19, 2010                [Page 16]


Internet-Draft           Location Event Filters           September 2009


7.  Contributors

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















































Mahy, et al.             Expires March 19, 2010                [Page 17]


Internet-Draft           Location Event Filters           September 2009


8.  Acknowledgments

   Thanks to Richard Barnes and Alissa Cooper, Adam Roach, Allan
   Thomson, James Winterbottom for their comments.















































Mahy, et al.             Expires March 19, 2010                [Page 18]


Internet-Draft           Location Event Filters           September 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-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]
              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.

   [RFC4661]  Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-



Mahy, et al.             Expires March 19, 2010                [Page 19]


Internet-Draft           Location Event Filters           September 2009


              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,
              "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,
              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 March 19, 2010                [Page 20]


Internet-Draft           Location Event Filters           September 2009


Authors' Addresses

   Rohan Mahy
   Plantronics
   345 Encincal Street
   Santa Cruz, CA
   USA

   Email: rohan@ekabal.com


   Brian Rosen (editor)
   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 March 19, 2010                [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/