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.

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

1.  Introduction

Location information is generally recognized as being a subset of presence as described in [RFC4079] (Peterson, J., “A Presence Architecture for the Distribution of GEOPRIV Location Objects,” July 2005.). 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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) as a location dereference protocol. This is accomplished by defining a new subscription event package as described in RFC3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.).

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] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” February 2007.) and geolocation policy [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,” January 2010.) 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] (Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” October 2009.) are assumed to exist.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The terms Location Recipient and Target are used as defined in [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.)

The term location information (LIS) is used throughout this document as defined in [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.). A presence server that distributes physical location to watchers may also be regarded as a LIS in the terms of reference for this document.

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] (Marshall, R., “Requirements for a Location-by-Reference Mechanism,” November 2009.).

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] (Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, “A Location Dereferencing Protocol Using HELD,” January 2010.). 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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), 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 (IANA Considerations). The general context and model for location subscription is shown in Figure 1 (Context Diagram).

                              +-----------+
  +------------+              | 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  |
        |                       +--+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+--+
        |                          |                             |
        |                          |                             |

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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), and in the SIP specification [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) or a presence (pres) URI [RFC3859] (Peterson, J., “Common Profile for Presence (CPP),” August 2004.). 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), 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 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.

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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) 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 (IANA Considerations). 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 (NOTIFY Bodies).

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.

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 (IANA Considerations).

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 (Subscription Examples). 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.

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] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.). 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] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) 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 Section 9 (IANA Considerations) 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.

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

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>

The successful response to the subscription shown in Figure 3 (SUBSCRIBE Message) is a 200 OK followed almost immediately by a NOTIFY containing the requested location. This is shown in Figure 4 (NOTIFY Message with Location Information).

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>

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 Message with Error).

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

8.  Security Considerations

TBD.

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] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.).

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] (Mealling, M., “The IETF XML Registry,” January 2004.).

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

9.3.  XML Schema Registration

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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 (Schema) 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:

charsetIndicates 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 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [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.]]

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 (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) [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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.). 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

10.  Acknowledgements

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

11.  References

11.1. Normative References

11.2. Informative References

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] (Thomson, M. and J. Winterbottom, “Specifying Location Quality Requirements in Location Protocols,” January 2010.) 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] (Thomson, M. and J. Winterbottom, “Specifying Location Quality Requirements in Location Protocols,” January 2010.), the location provided in the subsequent location response messages should also comply with [I‑D.thomson‑geopriv‑location‑quality] (Thomson, M. and J. Winterbottom, “Specifying Location Quality Requirements in Location Protocols,” January 2010.).

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

A.2.  Inclusion of Mahy Loc-Filters

Rohan Mahy produced an early specification [I‑D.ietf‑geopriv‑loc‑filters] (Mahy, R., Rosen, B., and H. Tschofenig, “Filtering Location Notifications in the Session Initiation Protocol (SIP),” March 2010.) 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>

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.

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

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

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

Authors' Addresses

Full Copyright Statement

Copyright © 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.