Internet DRAFT - draft-winterbottom-sip-location-package

draft-winterbottom-sip-location-package






SIP                                                      J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: January 8, 2009                                   H. Tschofenig
                                                  Nokia Siemens Networks
                                                            July 7, 2008


     A Session Initiation Protocol (SIP) Event Package for Location
                              Information
             draft-winterbottom-sip-location-package-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 January 8, 2009.















Winterbottom, et al.     Expires January 8, 2009                [Page 1]

Internet-Draft           Location Event Package                July 2008


Abstract

   This document specifies a SIP event package allowing allowing a
   location receiptient to subscribe for location information when
   provided a location URI using the sip, sips, or pres URI schemes.
   The notification that results from the subscription is either the
   location of the Target or an error.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol Interaction . . . . . . . . . . . . . . . . . . . . .  6
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  8
   5.  Event Package details  . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Event Package Name . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Event Package Parameters . . . . . . . . . . . . . . . . . 10
     5.3.  Accept Header Value  . . . . . . . . . . . . . . . . . . . 10
     5.4.  Subscription Duration  . . . . . . . . . . . . . . . . . . 10
     5.5.  Forked SUBSCRIBE Requests  . . . . . . . . . . . . . . . . 10
     5.6.  Subscribing for Location Information . . . . . . . . . . . 11
       5.6.1.  SUBSCRIBE Message Body . . . . . . . . . . . . . . . . 11
     5.7.  Location Notification  . . . . . . . . . . . . . . . . . . 12
       5.7.1.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . 12
       5.7.2.  Rate of Notifications  . . . . . . . . . . . . . . . . 12
     5.8.  State Agents . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  HELD Error Token Registration  . . . . . . . . . . . . . . 20
     9.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:loc-event . . . . . . . . . . . . . 20
     9.3.  XML Schema Registration  . . . . . . . . . . . . . . . . . 21
     9.4.  MIME Media Type Registration for
           'application/loc-event+xml'  . . . . . . . . . . . . . . . 21
     9.5.  Event Package Registration . . . . . . . . . . . . . . . . 22
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Subscription Examples . . . . . . . . . . . . . . . . 27
     A.1.  Requesting a Quality of Position . . . . . . . . . . . . . 27
     A.2.  Inclusion of Mahy Loc-Filters  . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31



Winterbottom, et al.     Expires January 8, 2009                [Page 2]

Internet-Draft           Location Event Package                July 2008


   Intellectual Property and Copyright Statements . . . . . . . . . . 32


















































Winterbottom, et al.     Expires January 8, 2009                [Page 3]

Internet-Draft           Location Event Package                July 2008


1.  Introduction

   Location information is generally recognized as being a subset of
   presence as described in [RFC4079].  It is also recognized that
   location information is most readily available from the local access
   network serving a specific end-device.  The node in a local access
   network responsible for determining and desseminating an end-point's
   location is referred to as a location information server (LIS).
   Where the LIS is capable of supporting SIP SUBSCRIBE and NOTIFY
   messages [RFC3265] for the dissemination of location information it
   becomes a limited capability presence server.  To support this
   limited capability a new SIP event package is defined specifically
   for the subscription to, and notification of, a Target's physical
   location.

   This document proposes the usage of the Session Initiation Protocol
   (SIP) [RFC3261] as a location dereference protocol.  This is
   accomplished by defining a new subscription event package as
   described in RFC3265 [RFC3265].

   This event package is based on the concept of a location information
   server (LIS), which resides in the same access network as a Target.
   the LIS is capable of accepting subscriptions, storing subscription
   state, and generating notifications either periodically or when the
   LIS detects changes in a Target's physical location.

   The event package defines a simple but extensible XML schema which
   allows a location recipient to subscribe to a LIS for a Target's
   location information.  A base set of subscription criteria are
   defined in an XML schema.  Extensions points are provided in the
   schema so that additional criteria can be specified for future
   application requirements.

   How the location recipient learns the location URI is out of scope
   for this document.  The specification relies of existing SIP,
   presence, and georpiv mechansisms for the authentication of location
   recipients and the application of these mechanisms is deemed out of
   scope for this specification.  Existing presence and location
   authorization policies such as those described in common policy
   [RFC4745] and geolocation policy [I-D.ietf-geopriv-policy] are
   assumed to be in place.  Alternatively, specific constraints attached
   to the location URI itself, such as those described in
   [I-D.winterbottom-geopriv-held-context] are assumed to exist.








Winterbottom, et al.     Expires January 8, 2009                [Page 4]

Internet-Draft           Location Event Package                July 2008


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

   The terms Location Recipient and Target are used as defined in
   [RFC3693]

   The term location information (LIS) is used throughout this document
   as defined in [I-D.ietf-geopriv-l7-lcp-ps].  A presence server that
   distributes physical location to watchers may also be regarded as a
   LIS in the terms of reference for this document.






































Winterbottom, et al.     Expires January 8, 2009                [Page 5]

Internet-Draft           Location Event Package                July 2008


3.  Protocol Interaction

   Using a location URI that provides a Target's location to a recipient
   directly from the LIS is often preferable and more effient than
   requiring location information originate from the LIS and traverse
   the Target end-point before reaching the location recipient.  This is
   especially true in environments where the Target can move and change
   points of network attachment without an interuption in service.  The
   merits and requirements of using a location URI are addressed in
   detail in the location by reference requirements document
   [I-D.ietf-geopriv-lbyr-requirements].

   Location configuration protocols, such as HELD, provide an end-point
   the ability to request a location URI that they can distribute to
   external entities and applications for the purpose of later location
   retrival.  A scheme for dereferencing HELD URIs is described in
   [I-D.winterbottom-geopriv-deref-protocol].  This specification
   describes a location information event package that an application or
   entity can use this to request location information directly from a
   LIS or presence server using SIP.

   The SIP subscription functionality is described in [RFC3265], along
   with general guidelines for defining new event packages for which
   subscriptions can be made.  This specification defines a new event
   package that allows a recipient to specifically subscribe for
   location information.  The event package consists of an XML schema
   that is included in the body of the SIP subscribe message, and a new
   subscribe event header.  Both the schema and the subscribe event
   header are registered with IANA in Section 9.  The general context
   and model for location subscription is shown in Figure 1.





















Winterbottom, et al.     Expires January 8, 2009                [Page 6]

Internet-Draft           Location Event Package                July 2008


                              +-----------+
  +------------+              | Location  |                +-----------+
  | End Device |              |Information|                | Location  |
  |  (Target)  |              |  Server   |                | Recipient |
  +-----+------+              +----+------+                +-----+-----+
        |                          |                             |
     +--+--------------------------+--+                          |
     |  |                          |  |                          |
     |  |===locationRequest(URI)==>0  |                          |
     |  |                          |  | Location                 |
     |  |                          |  | Configuration            |
     |  0<==locationResponse(URI)==|  | Protocol                 |
     |  |                          |  |                          |
     +--+--------------------------+--+                          |
        |                          |                             |
        |                          |                             |
        |~~~~~~~~~~~~Location Conveyance (URI)~~~~~~~~~~~~~~~~~~>0
        |                          |                             |
        |                       +--+-----------------------------+--+
        |                       |  |                             |  |
        |        Location       |  0<======SUBSCRIBE(loc)========|  |
        |        Event          |  |                             |  |
        |        Package        |  |========NOTIFY(PIDF-LO)=====>0  |
        |                       |  |========NOTIFY(PIDF-LO)=====>0  |
        |                       |  |========NOTIFY(PIDF-LO)=====>0  |
        |                       +--+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+--+
        |                          |                             |
        |                          |                             |

                         Figure 1: Context Diagram





















Winterbottom, et al.     Expires January 8, 2009                [Page 7]

Internet-Draft           Location Event Package                July 2008


4.  Overview of Operation

   In this section, an overview of the operation of this event package
   is presented.  In order to provide clarity on this package the
   overview describes behavior that is documented in part here, partly
   in the SIP event framework [RFC3265], and in the SIP specification
   [RFC3261].  However, the detailed semantics of this package require
   the reader to be familiar with SIP events and the SIP specification
   itself.

   When an entity, the subscriber, wishes to learn about the location
   from some user, it creates a SUBSCRIBE request.  This request
   identifies the desired Target in the Request-URI, using a SIP URI,
   SIPS URI [RFC3261] or a presence (pres) URI [RFC3859].  The SUBSCRIBE
   request is carried along SIP proxies as any other SIP request would
   be and eventually arrives at a LIS, which will generate a response to
   the request.

   The LIS first authenticates the subscription, then authorizes it.
   The means for authorization are outside the scope of this protocol.
   If authorized, a 200 OK response is returned followed immediately by
   a NOTFIY message containing the location of the target.  If
   authorization could not be obtained at this time, the subscription is
   considered "terminated" with a reason code of "rejected" and a
   $quot;403 Forbidden" response is returned.  Periodicially, or as the
   location of the Target changes, the LIS generates and sends NOTIFY
   messages containing the location information to all subscribers with
   authorized subscriptions.  Changes in the state of the subscription
   itself can also trigger NOTIFY messages; that state is carried in the
   Subscription-State header field of the NOTIFY, and would typically
   indicate whether the subscription is active or terminated.  No
   pending state for location information is considered.

   The SUBSCRIBE message establishes a "dialog" with the LIS.  A dialog
   is defined in RFC 3261 [RFC3261], and it represents the SIP state
   between a pair of entities to facilitate peer-to-peer message
   exchanges.  This state includes the sequence numbers for messages in
   both directions (SUBSCRIBE from the subscriber, NOTIFY from the LIS),
   in addition to a route set and remote target URI.  The route set is a
   list of SIP (or SIPS) URIs which identify SIP proxy servers that are
   to be visited along the path of SUBSCRIBE refreshes or NOTIFY
   requests.  The remote target URI is the SIP or SIPS URI that
   identifies the target of the message - the subscriber, in the case of
   NOTIFY, or the LIS, in the case of a SUBSCRIBE refresh.

   The subscription persists for a duration that is negotiated as part
   of the initial SUBSCRIBE.  The subscriber will need to refresh the
   subscription before its expiration, if they wish to retain the



Winterbottom, et al.     Expires January 8, 2009                [Page 8]

Internet-Draft           Location Event Package                July 2008


   subscription.  This is accomplished by sending a SUBSCRIBE refresh
   within the same dialog established by the initial SUBSCRIBE.  This
   SUBSCRIBE is nearly identical to the initial one, but contains a tag
   in the To header field and a higher CSeq header field value.

   The subscriber can terminate the subscription by sending a SUBSCRIBE,
   within the dialog, with an Expires header field (which indicates
   duration of the subscription) value of zero.  This causes an
   immediate termination of the subscription.  A NOTIFY request is then
   generated by the LIS with the most recent location information for
   the Target.

   The LIS can terminate the subscription at any time.  To do so, it
   sends a NOTIFY request with a Subscription-State header field with a
   value of "terminated".  A reason parameter is also supplied which
   provides the reason for the termination.



































Winterbottom, et al.     Expires January 8, 2009                [Page 9]

Internet-Draft           Location Event Package                July 2008


5.  Event Package details

5.1.  Event Package Name

   A SIP subscription specifies precisely which event or set events
   (event package) the subscriber is interested in being notified about.
   This specification deals with subscription for location information
   and specifies a new event package excplicitly for this purpose.  The
   SIP event notification specification [RFC3265] stipulates that a new
   event package requires the registration of a new "Event" header token
   so that a subscriber can explcitly subscribe for these events.  This
   specification defines the "loc-event" Event header token, and
   registers it in Section 9.  All subscriptions for location
   information are expected to use this Event header token.

5.2.  Event Package Parameters

   The SIP event framework allows event packages to define additional
   parameters carried in the Event header field.  This package,
   presence, does not define any additional parameters.

5.3.  Accept Header Value

   The Accept header in the SUBSCRIBE indicates to the LIS what type of
   information the location recipient is expecting.  This event package
   requires that the Accept header bet set to "application/held+xml".
   The rationale for resuing the HELD MIME type in the NOTIFY message is
   provide in Section 5.7.1.

5.4.  Subscription Duration

   Default is 24 hours.  If the URI was generated using HELD Context
   management or some other policy-based mechansism then the LIS MUST
   provide and expires value that is equal to or less than the expiry
   time of the specified in the policy.

   Very short subscription times will be treated as though they are
   immediate notification requests.  Assuming that the subscription is
   accepted, the LIS will respond with the fastest location that it is
   able to provide.

5.5.  Forked SUBSCRIBE Requests

   This event package does not support forked SUBSCRIBE requests.







Winterbottom, et al.     Expires January 8, 2009               [Page 10]

Internet-Draft           Location Event Package                July 2008


5.6.  Subscribing for Location Information

5.6.1.  SUBSCRIBE Message Body

   The characteristics of the subscription are defined in the XML schema
   which is conveyed from the subscriber to the LIS in the body of the
   SUBSCRIBE message.  A new MIME type of application/loc-event+xml is
   defined for use with this schema and it is registered in Section 9.

   The schema is broken into two parts, a "what" part, and a "when"
   part.  The "what" part defines what the subscriber requires, and the
   "when" part defines when the LIS should send it.  These two
   components are described in more detail below.

5.6.1.1.  What

   The "what" part of the location subscription comprises of two basic
   components.  A location type element allows the subscriber to specify
   the type of location information that they wish to receive, geodetic,
   civic, or any.  The LIS should try to provide location in the form
   subscribed for.  If the LIS is unable to provide location in the form
   requested, then it may provide location in an alternative form.  If
   the subscriber is unable to process the location form returned by the
   LIS, then the subscriber is expected to terminate the subscription.

   An extension point is included in the schema so that additional
   requirements of what is to be provided in notification responses can
   be specified.  Examples of how to use this this extension point are
   providced in Appendix A.  Thes examples should be considered
   informative only.

5.6.1.2.  When

   The "when" part of the subscription tells the LIS when the subscriber
   would like to receive location information about the Target.  Two
   basic components are provided.  An interval, in seconds, tell the LIS
   how often to send a location update to the subscriber.  An trigger
   for sending notifications when the Target's point of network
   attachment changes is also provided.  The "when" elements operate in
   a logical OR manner, and a notification SHOULD be sent whenever one
   of these conditions occurs.

   An extension point exists in the schema so that additional
   notification triggers can be specified and added as they become
   required.






Winterbottom, et al.     Expires January 8, 2009               [Page 11]

Internet-Draft           Location Event Package                July 2008


5.7.  Location Notification

   Location information and error messages are returned to the
   subscriber in the body of a SIP NOTIFY message.

5.7.1.  NOTIFY Bodies

   The NOTIFY body is either a HELD locationResponse, or a HELD error
   message, both are defined in
   [I-D.ietf-geopriv-http-location-delivery].  The rationale for reusing
   the location response and error messages from HELD is twofold.
   Firstly a location recipient cannot be assured ahead of time of the
   location URI type that a Target will provide it; this is largely
   determined by what the LIS in the local access network provides to
   the Target and so is out of the control of both the Target and
   recipient.  So the recipient should be capable of dealing with HELD
   location responses in any event.  Secondly, the HELD location
   response and error messages provide excellent containers for the
   information that the LIS needs to provide to the location recipient
   in a NOTIFY.  Rules from HELD
   [I-D.ietf-geopriv-http-location-delivery] apply when constructing
   these messages, with the exception of the clarifications provided
   later.

   An error will, in some circumstances, result in a terminated
   subscription, however in other cases the error condition may be
   present for only one specific notification cycle in which case the
   subscription will remain active.  The subscriber MUST examine the
   value of the Subscription-State header to determine if the
   subscription has been terminated or not.

   The LIS MUST send a NOTIFY with a Subscription-State header value of
   "terminated" and a reason code of "noresource"when it is no longer
   able to provide the Target's location though the subscribed URI.
   This informs the subscriber that no further attempts to subscribe to
   the resource should be attempted.  The LIS MUST include a HELD error
   message with a code of "locationUnknown" in the NOTFIY body when this
   condition occurs.

5.7.2.  Rate of Notifications

   The rate at which notifications are generated is excplictly defined
   in the interval element of the "when" component in the SUBSCRIBE
   body.  This element defines how often the subscriber wishes to
   receive notifications about a Target's location.  The interval value
   is a positive integer respresenting seconds.

   A new HELD error token of "intervalTooShort" is regsitered in



Winterbottom, et al.     Expires January 8, 2009               [Page 12]

Internet-Draft           Location Event Package                July 2008


   Section 9 and MUST be used by the LIS when an inappropriately short
   notification interval is requested by the subscriber.  When this
   error is returned the corresponding NOTIFY message MUST have a
   Subscription-State header value of "termninated", reason code of
   "giveup" and a value for the retry-after parameter MAY be provided.

5.8.  State Agents

   The LIS is responsible for keeping track of where a Target is
   physically located in the access network.  Stare, as it pertains to
   this event package, refers to the policies associated with the URI to
   which the subscription was made, and physical location of the Target.
   State is therefore maintained internal to the LIS and is explcitly
   resolved at the time that a notification is generated.





































Winterbottom, et al.     Expires January 8, 2009               [Page 13]

Internet-Draft           Location Event Package                July 2008


6.  Schema

   This section defines the schema that constitutes the body of this
   even package.

    <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:loc-event"
     xmlns:loc-event="urn:ietf:params:xml:ns:loc-event"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:qop="urn:ietf:params:xml:ns:geopriv:lq"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"

     <xs:element name="locationSubscription">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="what" type="loc-event:subscribeFor"
                       minOccurs="1" maxOccurs="1"/>

           <xs:element name="when" type="loc-event:trigger"
                       minOccurs="1" maxOccurs="1"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <xs:complexType name="subscribeFor">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="locationType"
                         type="loc-event:locationType"
                         minOccurs="1" maxOccurs="1"/>

             <xs:element name="QoP" type="qop:quality"
                         minOccurs="0" maxOccurs="1"/>

             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0"  maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:simpleType name="locationType">
       <xs:restriction base="xs:token">
         <xs:enumeration value="any"/>
         <xs:enumeration value="civic"/>



Winterbottom, et al.     Expires January 8, 2009               [Page 14]

Internet-Draft           Location Event Package                July 2008


         <xs:enumeration value="geodetic"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:complexType name="trigger">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="updateInterval"
                    type="loc-event:intervalType"/>

             <xs:element name="attachmentChange" type="xs:boolean"
                         minOccurs="0" maxOccurs="1"/>

             <xs:any namespace="##other" processContents="lax"
                     minOccurs="0"  maxOccurs="unbounded"/>
           </xs:sequence>
           <xs:anyAttribute namespace="##any" processContents="lax"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:complexType name="intervalType">
       <xs:simpleContent>
         <xs:extension base="xs:positiveInteger">
           <xs:attribute name="notificationCount"
             type="xs:positiveInteger"
                         use="optional" default="1"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
   </xs:schema>

                Figure 2: XML Schema for Subscription Body

















Winterbottom, et al.     Expires January 8, 2009               [Page 15]

Internet-Draft           Location Event Package                July 2008


7.  Examples

7.1.  Example 1

   In this example emergency application 1, emgapp1, is subscribing for
   the location information associated is xyzabc being service by the
   LIS at example.com.  The emergency application would like to get
   geodetic location information, updated every 10 seconds or when
   xyzabc changes wireless access points.  The subscription is for a
   duration of 30 minutes.

   SUBSCRIBE sip:xyzabc@lis.example.com SIP/2.0
   Via: SIP/2.0/TCP emergency.emergizone.com;branch=z9hG4bKnashds7
   To: <sip:xyzabc@lis.example.com>
   From: <sip:emgapp1@emergizone.com>;tag=xfg9
   Call-ID: 2010@emergency.emergizone.com
   CSeq: 17766 SUBSCRIBE
   Max-Forwards: 70
   Event: loc-event
   Accept: application/held+xml
   Contact: <sip:emgapp1@emergency.emergizone.com>
   Expires: 1800
   Content-Type: application/loc-event+xml
   Content-Length: 330

   <?xml version="1.0"?>
   <locationSubscription xmlns="urn:ietf:params:xml:ns:loc-event">
     <what>
       <locationType>
         geodetic
       </locationType>
     </what>
     <when>
       <updateInterval>
         10
       </updateInterval>
       <attachmentChange>
         yes
       </attachmentChange>
     </when>
   </locationSubscription>


                        Figure 3: SUBSCRIBE Message

   The successful response to the subscription shown in Figure 3 is a
   200 OK followed almost immediately by a NOTIFY containing the
   requested location.  This is shown in Figure 4.



Winterbottom, et al.     Expires January 8, 2009               [Page 16]

Internet-Draft           Location Event Package                July 2008


   NOTIFY sip:emgapp1@emergizone.com SIP/2.0
   Via: SIP/2.0/TCP lis.example.com;branch=z9hG4bKna998sk
   From: <sip:xyzabc@lis.example.com>;tag=ffd2
   To: <sip:emgapp1@emergizone.com>;tag=xfg9
   Call-ID: 2010@emergency.emergizone.com
   Event: loc-event
   Subscription-State: active;expires=1790
   Max-Forwards: 70
   CSeq: 8775 NOTIFY
   Contact: sip:lis.example.com
   Content-Type: application/held+xml
   Content-Length: 911

   <?xml version="1.0"?>
   <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               entity="pres:xyzabc@lis.example.com">
       <tuple id="3b650sf789nd">
         <status>
           <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
             <location-info>
               <Point xmlns="http://www.opengis.net/gml"
                      srsName="urn:ogc:def:crs:EPSG::4326">
                 <pos>-34.407 150.88001</pos>
               </Point>
             </location-info>
             <usage-rules>
               <retention-expiry>
                 2006-01-11T03:42:28+00:00
               </retention-expiry>
             </usage-rules>
             <method>
               Device-Assisted_A-GPS
             </method>
           </geopriv>
         </status>
         <timestamp>2008-03-31T03:42:28+00:00</timestamp>
       </tuple>
     </presence>
   </locationResponse>


            Figure 4: NOTIFY Message with Location Information








Winterbottom, et al.     Expires January 8, 2009               [Page 17]

Internet-Draft           Location Event Package                July 2008


7.2.  Example 2

   An error message is returned when a problem with the subscription is
   encountered, for example the location URI that the subscriber
   subscribed too has expired or its usage count has been exceeded.
   This error message may look something like the NOTIFY shown in
   Figure 5.

   NOTIFY sip:emgapp1@emergizone.com SIP/2.0
   Via: SIP/2.0/TCP lis.example.com;branch=z9hG4bKna998sk
   From: <sip:xyzabc@lis.example.com>;tag=ffd2
   To: <sip:emgapp1@emergizone.com>;tag=xfg9
   Call-ID: 2010@emergency.emergizone.com
   Event: loc-event
   Subscription-State: terminated;reason=noresource
   Max-Forwards: 70
   CSeq: 8775 NOTIFY
   Contact: sip:lis.example.com
   Content-Type: application/held+xml
   Content-Length: 159

   <?xml version="1.0"?>
   <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
          code="locationUnknown"
          message="Unable to determine location"/>


                    Figure 5: NOTIFY Message with Error























Winterbottom, et al.     Expires January 8, 2009               [Page 18]

Internet-Draft           Location Event Package                July 2008


8.  Security Considerations

   TBD.
















































Winterbottom, et al.     Expires January 8, 2009               [Page 19]

Internet-Draft           Location Event Package                July 2008


9.  IANA Considerations

9.1.  HELD Error Token Registration

   Reference: RFC-XXXX (i.e., this document) requires the following new
   HELD error code to be added to the HELD error code respository
   defined in [I-D.ietf-geopriv-http-location-delivery].

      Error code: intervalTooShort

9.2.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:loc-event

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:loc-event", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:loc-event

      Registrant Contact: IETF, SIP working group, (sip@ietf.org), James
      Winterbottom (james.winterbottom@andrew.com).

      XML:

   BEGIN
   <?xml version="1.0"?>
     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
       <head>
         <title>Location Information Subscription Event Package</title>
       </head>
       <body>
         <h1>Namespace for the Location Information
             Subscription Application Event Package
         </h1>
         <h2>urn:ietf:params:xml:ns:loc-event</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
         <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
       </body>
     </html>
   END








Winterbottom, et al.     Expires January 8, 2009               [Page 20]

Internet-Draft           Location Event Package                July 2008


9.3.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:loc-event

   Registrant Contact:  IETF, SIP working group, (sip@ietf.org), James
      Winterbottom (james.winterbottom@andrew.com).

   Schema:  The XML for this schema can be found as the entirety of
      Section 6 of this document.

9.4.  MIME Media Type Registration for 'application/loc-event+xml'

   This section registers the "application/loc-event+xml" MIME type.

   To:  ietf-types@iana.org

   Subject:  Registration of MIME media type application/loc-event+xml

   MIME media type name:  application

   MIME subtype name:  loc-event+xml

   Required parameters:  (none)

   Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], section 3.2.

   Security considerations:  This content type is designed to carry
      protocol data related to the location of an entity, which could
      include information that is considered private.  Appropriate
      precautions should be taken to limit disclosure of this
      information.

   Interoperability considerations:  This content type provides a basis
      for a protocol

   Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]





Winterbottom, et al.     Expires January 8, 2009               [Page 21]

Internet-Draft           Location Event Package                July 2008


   Applications which use this media type:  Location information
      consumers.

   Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)

   Person & email address to contact for further information:  James
      Winterbottom <james.winterbottom@andrew.com>

   Intended usage:  LIMITED USE

   Author/Change controller:  This specification is TBD

   Other information:  This media type is a specialization of
      application/xml [RFC3023], and many of the considerations
      described there also apply to application/loc-event+xml.

9.5.  Event Package Registration

   This specification registers an event package, based on the
   registration procedures defined in RFC3265 [RFC3265].  The following
   is the information required for such a registration:

   Package Name:  loc-event

   Package or Template-Package:  This is a Package

   Published Document:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]

   Person or Contact:  James Winterbottom, james.winterbottom@andrew.com



















Winterbottom, et al.     Expires January 8, 2009               [Page 22]

Internet-Draft           Location Event Package                July 2008


10.  Acknowledgements

   We would like to thank Miguel Garcia and Brian Rosen for their
   comments.















































Winterbottom, et al.     Expires January 8, 2009               [Page 23]

Internet-Draft           Location Event Package                July 2008


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC3859]  Peterson, J., "Common Profile for Presence (CPP)",
              RFC 3859, August 2004.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [I-D.ietf-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work
              in progress), February 2008.

   [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-07 (work in
              progress), April 2008.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
              progress), June 2008.

11.2.  Informative References

   [RFC4079]  Peterson, J., "A Presence Architecture for the
              Distribution of GEOPRIV Location Objects", RFC 4079,



Winterbottom, et al.     Expires January 8, 2009               [Page 24]

Internet-Draft           Location Event Package                July 2008


              July 2005.

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [I-D.ietf-geopriv-pdif-lo-profile]
              Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO Usage Clarification, Considerations and
              Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
              (work in progress), February 2008.

   [I-D.winterbottom-geopriv-deref-protocol]
              Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
              Thomson, M., and M. Dawson, "An HTTPS Location
              Dereferencing Protocol Using HELD",
              draft-winterbottom-geopriv-deref-protocol-01 (work in
              progress), July 2008.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

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

   [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-17 (work in progress),
              June 2008.

   [I-D.winterbottom-geopriv-held-context]
              Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD
              Protocol Context Management Extensions",
              draft-winterbottom-geopriv-held-context-02 (work in
              progress), February 2008.

   [I-D.thomson-geopriv-location-quality]
              Thomson, M. and J. Winterbottom, "Specifying Location
              Quality Constraints in Location Protocols",
              draft-thomson-geopriv-location-quality-01 (work in
              progress), May 2008.

   [I-D.ietf-geopriv-loc-filters]
              Mahy, R., "A Document Format for Filtering and Reporting
              Location Notications in the  Presence Information Document



Winterbottom, et al.     Expires January 8, 2009               [Page 25]

Internet-Draft           Location Event Package                July 2008


              Format Location Object (PIDF-LO)",
              draft-ietf-geopriv-loc-filters-01 (work in progress),
              March 2007.
















































Winterbottom, et al.     Expires January 8, 2009               [Page 26]

Internet-Draft           Location Event Package                July 2008


Appendix A.  Subscription Examples

   The exmaples in this appendix should be regarded as non-normative,
   that is that they are for informational purposes only.  There intent
   is to demonstrate that other geoprive location request criteria can
   easily be included into the framework described in this document.

A.1.  Requesting a Quality of Position

   It is quite common for applications to want loation to be provided as
   a set of coordinates, latitude, longitude and optionally alitutde,
   and an area of uncertainty.  The document
   [I-D.thomson-geopriv-location-quality] describes a means by which
   location information of a specific accuracy and/or confidence can be
   requested.  Together these characteristics are referred to as the
   Quality of Position (QoP).  The following example show how a location
   subscription can be constructed including QoP parameters based on the
   scheme provided in [I-D.thomson-geopriv-location-quality], the
   location provided in the subsequent location response messages should
   also comply with [I-D.thomson-geopriv-location-quality].

   <locationSubscription xmlns="urn:ietf:params:xml:ns:loc-event">
     <what>
       <locationType>geodetic</locationType>
       <quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
         <maxUncertainty confidence="95">
           <horizontal>150</horizontal>
           <vertical>1000</vertical>
         </maxUncertainty>
         <maxAge>PT30S</maxAge>
       </quality>
     </what>
     <when>
       <updateInterval>
         180
       </updateInterval>
       <attachmentChange>
         true
       </attachmentChange>
     </when>
   </locationSubscription>


       Figure 6: Subscribing for Location with a Quality of Position







Winterbottom, et al.     Expires January 8, 2009               [Page 27]

Internet-Draft           Location Event Package                July 2008


A.2.  Inclusion of Mahy Loc-Filters

   Rohan Mahy produced an early specification
   [I-D.ietf-geopriv-loc-filters] that described how specific location
   events and triggers could be defined in an XML document.  This work
   is easily included into the framework.

   In this example the LIS is to generate a noficiation if the Target
   moves horizontally by more than 20 metres, or vertical by more than
   10 metres.  The LIS should provide an update every 3 minutes
   regardless of the Target movements, or when the Target changes its
   point of attachment to the network.

   <locationSubscription xmlns="urn:ietf:params:xml:ns:loc-event">
     <what>
       <locationType>civic</locationType>
     </what>
     <when>
       <updateInterval>
         180
       </updateInterval>
       <attachmentChange>
         true
       </attachmentChange>
       <location-filter
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:containment">
        <movedHoriz uom="urn:ogc:def:uom:EPSG::9001">20</movedHoriz>
        <movedVert uom="urn:ogc:def:uom:EPSG::9001">3</movedVert>
       </location-filter>
     </when>
   </locationSubscription>

     Figure 7: Subscribing for Location of Location Constrained Target

   In this example LIS is to generate a noficiation if the Target
   exceeds a speed of 3 MPH.  The LIS should provide an update every 3
   minutes regardless of the Target movements, or when the Target
   changes its point of attachment to the network.













Winterbottom, et al.     Expires January 8, 2009               [Page 28]

Internet-Draft           Location Event Package                July 2008


   <locationSubscription xmlns="urn:ietf:params:xml:ns:loc-event">
     <what>
       <locationType>civic</locationType>
     </what>
     <when>
       <updateInterval>
         60
       </updateInterval>
       <location-filter
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:containment">
         <speedExceeds uom="#mps">3</speedExceeds>
       </location-filter>
     </when>
   </locationSubscription>

       Figure 8: Subscribing for Location of a Speed Limited Target

   This final filters example shows how the entry or exit of a specific
   polygon by the Target can be subscribed to using the framework.
































Winterbottom, et al.     Expires January 8, 2009               [Page 29]

Internet-Draft           Location Event Package                July 2008


   <locationSubscription xmlns="urn:ietf:params:xml:ns:loc-event">
     <what>
       <locationType>civic</locationType>
     </what>
     <when>
       <updateInterval>
         60
       </updateInterval>
       <location-filter
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:containment">
         <enterOrExit>
           <gml:Polygon
                srsName="urn:ogc:def:crs:EPSG::4326"
                xmlns:gml="http://www.opengis.net/gml">
             <gml:exterior>
               <gml:LinearRing>
                 <gml:posList>
                   37.41188 -121.93243
                   37.41142 -121.93243
                   37.41142 -121.93132
                   37.41188 -121.93132
                   37.41188 -121.93243
                 </gml:posList>
               </gml:LinearRing>
             </gml:exterior>
           </gml:Polygon>
         </enterOrExit>
       </location-filter>
     </when>
   </locationSubscription>


         Figure 9: Subscribing for Location of Target in a Polygon


















Winterbottom, et al.     Expires January 8, 2009               [Page 30]

Internet-Draft           Location Event Package                July 2008


Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/


   Martin Thomson
   Andrew Corporation
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo,   02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.priv.at


















Winterbottom, et al.     Expires January 8, 2009               [Page 31]

Internet-Draft           Location Event Package                July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Winterbottom, et al.     Expires January 8, 2009               [Page 32]