Indirect Presence Publication with the Session Initiation Protocol(SIP)
draft-garcia-geopriv-indirect-publish-01

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 April 29, 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.

Abstract

A method for indirectly publishing presence information is described. This allows a presentity user agent to publish a URI that can be used by the presence agent to retrieve presence information. A presence agent is then better able to acquire dynamic presence information without relying on the presentity user agent. This also allows a presentity user agent to delegate responsibility for managing changing presence data to the source of that information.

Table of Contents

1.  Introduction
    1.1.  Geolocation Protocols Relationship
    1.2.  Terminology
2.  Indirect Presence Publish
    2.1.  Multiple Presence Sources
3.  Location header
4.  Indicating and Requiring Support of Indirect Publish
5.  De-reference Errors
6.  The Geolocation Header
7.  Example
8.  IANA Considerations
9.  Security considerations
10.  References
    10.1.  Normative References
    10.2.  Informational References
Appendix A.  Alternative Solutions Considered
§  Authors' Addresses

1.  Introduction

The Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] is extended by the SIP-events (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence' and this presence information is carried in Presence Information Data Format (PIDF) (Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” August 2004.) [RFC3863] documents.

Two sources of presence information have been established. The presence agent might be able to acquire presence data independently, or it might rely on the presentity user agent providing that information. Use of the SIP PUBLISH method for the purpose of informing the presence agent of state is described in RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903].

Many existing elements of presence information, such as the Presence Data Model (Rosenberg, J., “A Data Model for Presence,” July 2006.) [RFC4479], Rich Presence Extensions to PIDF (RPID) (Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” July 2006.) [RFC4480], or the Contact Information to the Presence Information Data Format (CIPID) (Schulzrinne, H., “Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals,” July 2006.) [RFC4481], are acquired directly from the presentity user agent. However, there are cases when the presentity user agent is not the direct source of the presence information.

One such example is location information. A presentity user agent might acquire location information from a Location Information Server (LIS). Due to the dynamic nature of location information, a LIS might provide location information by reference rather than value. One of these cases occurs when a presentity user agent acquires its own location information from a LIS using HELD (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery]. A reference in the form of a location URI allows the holder of the reference to obtain location information at any time directly from the LIS.

This document describes a means for a presentity user agent to publish presence information indirectly using a URI. The presence agent is then able to obtain information directly from the source of the data. This removes some of the burden of managing dynamic content from the presentity user agent, as they do not need to monitor changes to presence data and publish updates as changes occur.

Presence agents might provide a complex presence document that is assembled from multiple sources. A means is provided where the presence agent is able to assemble a presence document.

The mechanism in this document was originally designed with location information in mind, but it can be equally applied to any other form of dynamic presence data.

1.1.  Geolocation Protocols Relationship

[ED: move these pictures out of here. We need pictures that aren't location-specific so that readers don't mistakenly think that this is just about location. That's already compounded by using "Location", so this needs to be very clear. Maybe this could be made an appendix.]

The PIDF location object (PIDF-LO) (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119] establishes location information as a form of presence information. Therefore, a presence agent might provide location information along with other information such as status or mood ([RFC4480] (Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” July 2006.)).

A presence service commonly needs to rely on other entities to provide it with location information. A presentity user agent might be able to provide location information, or it might interact with a Location Information Server (LIS) (Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, “An Architecture for Location and Location Privacy in Internet Applications,” October 2009.) [I‑D.ietf‑geopriv‑arch] to acquire that information.

Figure 1 (Presence and Geolocation Protocols (Values)) depicts the geolocation protocol relationship. A location URI points to a resource on a LIS that is able to provide location of a specific Target. The LIS is able to associate the Location URI to the location of the Target inside its administrative domain. In this case, the Target in question is the presentity user agent.

         +-----------+               +------------+
         |           |               | Location   |
         |    LIS    |               | Recipient/ |
         |           |               | Presence   |
         |           |               | Agent      |
         +-----------+               +------------+
             ^  ^                           ^
             |  |                         //
Location     |  | Location              //
Configuration|  | Dereference         //
Protocol     |  | Protocol          //
(1)          |  | (2)             //
             |  |               //   Location Conveyance
             v  v             //     Protocol (e.g., SIP)
         +------------+     //       (3)
         |            |   //
         | Target /   | //
         | Presentity |<
         |            |
         +------------+

The following three steps are followed in Figure 1 (Presence and Geolocation Protocols (Values)):

(1).

The presentity user agent (or Target) acquires a location URI from the Location Information Server (LIS) using a Location Configuration Protocol (LCP).

(2).

Before publishing location information to the presence agent, the target must first de-reference the location URI to acquire a location value. Alternatively, location information might be acquired from the LIS by value.

(3).

Finally, the presentity user agent assembles an updated presence document and publishes this to the presence agent.

A location URI (Marshall, R., “Requirements for a Location-by-Reference Mechanism,” November 2009.) [I‑D.ietf‑geopriv‑lbyr‑requirements] provides additional flexibility that this process does not take advantage of. A location URI provides a way for a location recipient to have control over when and how location information is acquired. A location URI can be used by the presence agent to acquire location information according to the needs of the watchers that require the information.

This document enables the scenario shown in Figure 2 (Presence and Geolocation Protocols (References)), where the presentity user agent is able to acquire a location URI (step 1) and publish the URI (step 2). The presence agent is then able to acquire location information directly from the LIS (step 3).

 +-----------+               +------------+
 |           |  Location     | Location   |
 |    LIS    |<------------->| Recipient/ |
 |           |  Dereference  | Presence   |
 |           |  Protocol (3) | Agent      |
 +-----------+               +------------+
       ^                            ^
       |                          //
       | Location               //
       | Configuration        //
       | Protocol           //
       | (1)              //
       |                //   Location Conveyance
       v              //     Protocol (e.g., SIP)
+-------------+     //       (2)
|             |   //
| Target /    | //
| Presentity  |<
|             |
+-------------+

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

This document uses SIP events terminology from [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), presence terminology from [RFC3903] (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.), and Geopriv terminology from [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,” October 2009.).

2.  Indirect Presence Publish

A presentity user agent first acquires a reference to presence information in the form of a URI.

For location information, a location URI can be obtained using a location configuration protocol, such as HELD (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery]. For HELD, this is done by including a locationType element with the value set to locationURI.

The presentity user agent then publishes the URI (or URIs) to a presence agent, using the Location header (see Section 3 (Location header)).

This header is not specific to physical location information. Do not confuse the Location: header with the Geolocation: header. The former inherits its meaning from the HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] header of the same name, the name being a logical location or address. The latter is specifically restricted to physical location information.

The presence agent de-references URIs to acquire the referenced information. A sip:, sips: or pres: URI is dereferenced by subscribing for the presence event package at the given URI; a http: or https: URI is dereferenced following the rules 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.). Other URIs MUST not be used unless a method is defined for that URI that produces a presence document.

2.1.  Multiple Presence Sources

Indirect publish establishes multiple presence sources for a presence agent. In addition to the presentity user agent, multiple indirect sources of presence data can be identified using the Location header.

The presence agent acquires presence information from each source. This results in multiple presence documents. These documents are combined to produce a single document.

The single presence document contains the union of the set of tuples (or the [RFC4479] (Rosenberg, J., “A Data Model for Presence,” July 2006.) equivalents of device or person) from every presence document thus obtained. Tuple identifiers are modified as necessary to prevent collisions in the identifier namespace; this might be done be prefixing each tuple with the source identifier.

The presentity identifier in the final document is the presentity identifier in any presence document provided by the presentity user agent itself. Presentity identifiers from other sources are ignored.

The presence agent then monitors the state of the referenced presence document according to the needs of watchers. The presence agent updates its own copy of the presence data from each source. As presence state provided by each source changes, this is combined with data from other sources and watchers are notified accordingly.

A partial presence document (Niemi, A., Lonnfors, M., and E. Leppanen, “Publication of Partial Presence Information,” September 2008.) [RFC5264] MAY be used if the presence agent supports this format. In this case, partial differences (pidf-diff documents) provided from a given source are applied the information retrieved previously from the same source.

3.  Location header

The Location header includes a URI for information that might otherwise be included in the body of a request. It is defined by the following ABNF (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234], using the conventions and definitions in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.):

location-header        = "Location" HCOLON location-header-value
location-value         = (location-item *(COMMA location-item))
location-item          = LAQUOT location-URI RAQUOT
                       / *(SEMI location-param)
location-URI           = absoluteURI
location-param         = location-src-param / generic-param
location-src-param     = "src" EQUAL token

This document defines the Location header field as valid in SIP PUBLISH (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] requests only.

Each URI in the Location header MAY be tagged with a src parameter, identifying the source of the data that is found at the URI. This identifier is an opaque tag that is used to identify different URIs as having the same source. An included URI with no src parameter is considered to have a different src parameter to any other included URI. URIs with identical src parameters indicate that they are alternative URIs (possibly with different schemes) for the same information.

A presence agent MUST only attempt to use a single URI from each set with a unique src parameter. Presence information from any given URI can only be updated or replaced with presence information from a URI with the same src parameter.

Each PUBLISH message contains a complete set of URIs. The presence agent MUST NOT use a URI if the most recent Location header received does not include that URI. The Location header can be omitted in a request, which does not alter the set of URIs used by the presence agent. Providing an empty Location header stops the presence agent from using any URIs.

4.  Indicating and Requiring Support of Indirect Publish

A SIP option tag of indirectpub is created for use in the Require header. This is used by a presentity user agent to provide surety that any request to indirectly publish presence data has been understood by the presence agent.

Attempts to publish indirectly MUST use this option tag in the Require header. If an attempt to publish information indirectly fails, the presence agent includes the tag in the Unsupported header of a 420 (Bad Extension) response. Upon receiving this response, the presentity user agent SHOULD attempt to de-reference the URI and re-attempt the request with the presence information included directly unless it is unable or local policy dictates otherwise.

5.  De-reference Errors

Indirect publish adds an additional de-reference step to the publish process. This adds additional failure scenarios. The presence agent might be unable to de-reference a URI for a number of reasons:

• the indicated host might be unreachable
• the URI might be badly formed or it might refer to a non-existent destination
• the URI schemes - and the de-reference mechanisms they indicate - provided might not be supported by the presence agent
• the URI might produce information that is not presence data
• the presence agent might not be authorized to retrieve the indicated data and the de-reference request might be rejected by the server

Some of these errors might be detected during the processing of the request. Others might be encountered later by the presence agent. A mechanism is provided to indicate to the presentity user agent when the presence agent detects an error while processing the request.

[TBD: need to work out how to do this. Either way, it's almost essential to indicate to the presentity user agent that something has failed. There are many reasons that a URI might not be accessible, in many cases, it might be useful if the presentity user agent could fall back on providing information by value if the URI can't be used. It might be that the presentity user agent is more able to dereference the URI, or might be able to look for alternative sources for the information.]

[The lessons of the Geolocation header might be of some use here.]

6.  The Geolocation Header

[ED: Useful? Unnecessary complication? Initial inclination is toward the latter.]

A presence agent MAY choose to treat a Geolocation header (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” February 2010.) [I‑D.ietf‑sipcore‑location‑conveyance] in a PUBLISH request as though it were a Location header. The Require header of the request MUST include indirectpub in this case; if it does not, the presence agent cannot assume that the information was intended to be published.

The contents of the Geolocation header MUST be ignored if a Location header is present.

7.  Example

In the Figure 3, the presentity user agent (PUA) acquires and publishes a reference to presence data that is served by a presence source (PS). The presence agent (PA) provides this information to a watcher along with information included by the presentity user agent. Only request messages are shown for clarity.

     PUA              PS                   PA             WATCHER
      |               |                    |                 |
      |<-- Acquire -->|                    |<-- Establish -->|
      |   Reference   |                    |   Subscription  |
      |               |                    |                 |
      |------- M1: Publish Reference ----->|                 |
      |               |                    |                 |
      |               |<-- M2: Subscribe --|                 |
      |               |                    |                 |
      |               |--- M3: Notify ---->|                 |
      |               |                    |                 |
      |               |                    |-- M4: Notify -->|
      |               |                    |                 |
      |               |       ...          |                 |
      |               |                    |                 |
      |               |----- Notify ------>|                 |
      |               |                    |                 |
      |               |                    |---- Notify ---->|
      |               |                    |                 |
      .               .                    .                 .

A presentity user agent acquires a URI that refers to presence information. In this example, it is also assumed that the watcher has also established a subscription.

The presentity user agent publishes this information to a presence agent. The SIP PUBLISH might also include information that the presentity user agent directly provides, such as the status.

M1:
  PUBLISH sip:presentity@example SIP/2.0
  To: <sip:presentity@example>
  From: <sip:presentity@example>;tag=1234wxyz
  Call-ID: 81818181@pua.example
  CSeq: 1 PUBLISH
  Max-Forwards: 70
  Event: presence
  Location: <pres:3cy89sckl@source.example>;src=abc123,
    <https://source.example/presence/3cy89sckl>;src=abc123
  Contact: presentity@pua.example
  Content-Type: application/pidf+xml
  Content-Length: ...

  <presence entity="pres:presentity@example">
    <tuple id="status>
      <!-- status tuple contents-->
    </tuple>
  </presence>

The presence agent selects one location from each source and de-references this URI. For a SIP URI (sip:, sips:, or pres:) this requires a presence event package subscription.

M2:
  SUBSCRIBE pres:3cy89sckl@source.example SIP/2.0
  To: <pres:3cy89sckl@source.example>
  From: <pres:pa.example>;tag=4567qwer
  Call-ID: 111222@example
  CSeq: 1 SUBSCRIBE
  Max-Forwards: 70
  Event: presence
  Expires: 3600
  Contact: sip:pa.example
  Content-Length: 0

The presence source provides a notification containing presence information selects one location from each source and de-references this URI. For a SIP URI (sip:, sips:, or pres:) this requires a presence event package subscription.

M3:
  NOTIFY pa.example SIP/2.0
  To: <pres:pa.example>
  From: <pres:3cy89sckl@source.example>;tag=7678fghj
  Call-ID: 111222@example
  CSeq: 1 NOTIFY
  Max-Forwards: 70
  Event: presence
  Subscription-State: active; expires=3599
  Contact: sip:source.example
  Content-Type: application/pidf+xml
  Content-Length: ...

  <presence entity="pres:3cy89sckl@source.example">
    <tuple id="geolocation">
      <!-- geolocation tuple contents -->
    </tuple>
  </presence>

The presence agent then provides a notification to the watcher with this new presence data.

M4:
  NOTIFY watcher@example SIP/2.0
  To: <pres:watcher@example>
  From: <pres:presentity@example>;tag=asd234
  Call-ID: 789678@example
  CSeq: 1 NOTIFY
  Max-Forwards: 70
  Event: presence
  Subscription-State: active; expires=3207
  Contact: sip:pa.example
  Content-Type: application/pidf+xml
  Content-Length: ...

  <presence entity="pres:presentity@example">
    <tuple id="status>
      <!-- status tuple contents-->
    </tuple>
    <tuple id="abc123-geolocation">
      <!-- geolocation tuple contents -->
    </tuple>
  </presence>

From this point, changes in presence state at the source trigger notifications to the presence agent. This in turn triggers notifications to any watchers.

8.  IANA Considerations

TBD: register SIP header, indirectpub option tag and establish parameter registry (pah).

9.  Security considerations

The security considerations described in SIP Location Conveyance [I‑D.ietf‑sip‑location‑conveyance] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.)are applicable to this document.

Privacy protections are extremely important for presence information. Indirect publish potentially provides watchers and presence agents greater access to a user's private data. A presence source

10.  References

10.1. Normative References

10.2. Informational References

Appendix A.  Alternative Solutions Considered

[ED: this section is a mess; it should be cleaned up and moved to an appendix.]

The following alternative solutions were considered in the design of this solution:

1. Rather than using a header, additional SIP bodies could be defined. This could be a PIDF extension, or a specialized format. This has a number of advantages, particularly in terms of good protocol hygiene. This potentially runs afoul of the shy support for multipart MIME in SIP agents. As a PIDF extension, it's possible that multipart support is not required, but it would potentially be difficult to ensure that it is the presence agent that is performing the de-reference.
2. Integration with partial presence publish (Niemi, A., Lonnfors, M., and E. Leppanen, “Publication of Partial Presence Information,” September 2008.) [RFC5264] was considered. Including a URI in a pidf-diff document would provide an elegant way to integrate indirectly published data. However, RFC 5264 defines a format that cannot be extended. The scheme chosen also provides less flexibility and is consequently significantly simpler.
3. It's possible that a mechanism is not necessary at all. Presence sources could be given the information necessary to PUBLISH the information. Mechanisms would need to be provided for this purpose. Aside from the complexity of managing this relationship, it does not benefit from the ability to use an event-based subscription. It is also more difficult to ensure that the presence source publishes when the presence agent (and watchers) need the information.
4. The SIP Location Conveyance (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.) [I‑D.ietf‑sip‑location‑conveyance] defines a Geolocation header field that could be used for indirect publish. Limiting this solution to location information would be a constraint that would prevent this from use for other types of information.

Authors' Addresses