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

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 15, 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

SIP is extended by the SIP-events 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) documents.

The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption.

There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality.

Table of Contents

1.  Introduction
    1.1.  Geolocation Protocols Relationship
    1.2.  Case Study: Location URIs
    1.3.  Terminology
2.  Overview of Operation
3.  IANA Considerations
4.  Security considerations
5.  References
    5.1.  Normative References
    5.2.  Informational References
§  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 framework (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence'. The presence information is typically carried in Extensible Markup Language (XML) (Bray, T., Paoli, J., Yergeau, F., Maler, E., and C. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.) [W3C.REC‑xml‑20060816] documents that are compliant with a given XML schema (Walmsley, P. and D. Fallside, “XML Schema Part 0: Primer Second Edition,” October 2004.) [W3C.REC‑xmlschema‑0‑20041028]. These presence documents are called Presence Information Data Format (PIDF) documents (Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” August 2004.) [RFC3863].

The SIP PUBLISH method specified in RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] carrying a PIDF document is typically used when presentities publish their own presence information. Usually the presentity can compose a quite detailed PIDF document, which is typically extended with a number of rich 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].

In the mentioned extensions, the presentity is typically the source of the extended rich presence information. However, there are occasions, when the presentity is not the direct source of the presence information. One of these cases occurs when a presentity acquires its own location information from a HELD server (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery]. The HELD client on the end host can request Location URI (location by reference) as opposed to as a value (location by value).

1.1.  Geolocation Protocols Relationship

Figure 1 (Current Geolocation Protocols Relationship) depicts the geolocation protocol relationship. A Location URI points to a Location Configuration Protocol (LCP) server that is able to provide location of a specific target. The LCP server is able to associate the Location URI to the location of the target inside its administrative domain. A target of location information implements a Location Configuration Protocol (LCP) client. The LCP client first uses the location configuration protocol to acquire its location information (see step 1 in Figure 1 (Current Geolocation Protocols Relationship)). We assume this location information is delivered in the format of a reference.

Then the LCP client needs to de-reference the acquired reference. This done in step 2 in Figure 1 (Current Geolocation Protocols Relationship) and uses a location de-reference protocol to get a value of its location information. Last, the end host can embed its location information in the location conveyance protocol (step 3 in in Figure 1 (Current Geolocation Protocols Relationship)) and send it to a location recipient, such as a presence server.

       +-----------+               +------------+
       |           |               | Location   |
       |    LCP    |               | recipient/ |
       |   server  |               | Presence   |
       |           |               | cerver     |
       +-----------+               +------------+
           ^  ^                        ^
Geopriv    |  | Geopriv              //
Location   |  | Location           //
Dereference|  | Configuration    //
Protocol   |  | Protocol       //
(2)        |  | (1)          //
           |  |            //   Geopriv Location
           v  v          //     Conveyance Protocol
       +-----------+   //       (e.g., SIP)
       | Target /  | //         (3)
       | End host  |v
       | LCP client|
       +-----------+

This document, though, discusses proposals for the scenario envisioned in Figure 2 (Proposed Geolocation Protocols Relationship), where the target or end hosts acquires a reference via the location configuration protocol (step 1 in Figure 2 (Proposed Geolocation Protocols Relationship)), sends such reference in a location conveyance protocol or presence publication (step 2), and lets the location recipient or presence server to acquire the actual value according to the reference (step 3).

The kind of reference that is first acquired and then send to the location recipient determines the value that the location recipient gets in step 3. Section 1.2 (Case Study: Location URIs) discusses location URIs.

+-----------+  Geopriv      +------------+
|           |  Location     | Location   |
|    LCP    |<------------->| Recipient/ |
|   server  |  Dereference  | Presence   |
|           |  Protocol (3) | Server     |
+-----------+               +------------+
      ^                         ^
      | Geopriv               //
      | Location            //
      | Configuration     //
      | Protocol        //
      | (1)           //
      |             //   Geopriv Location
      v           //     Conveyance Protocol
+-----------+   //       (e.g., SIP)
| Target /  | //         (2)
| End Host  |v
| LCP Client|
+-----------+

1.2.  Case Study: Location URIs

A Location URI points to a Location Configuration Protocol (LCP) server that is able to provide location of a specific target. The LCP server is able to associate the Location URI to the location of the target inside its administrative domain. However, the resolution step from a Location URI to a Location Object may be influenced by different parameters and by the location URI itself.

Depending on the value returned as an invocation to the reference URI, we can classify location URI in two cases:

Static location URIs:

Whenever a static location URI is de-referenced, the same static location is returned. These URIs are typically constrained by a start and a stop time. For example, the location of Alice on a her 21st birthday at 10:00 AM is a static location URI, because she was in a place at that time and date, so, the location does not change. The path that Alice took on the same day from 12 PM to 2 PM is also a static location URI, because as a result of its de-reference the location recipient will get the same collection of locations.

Dynamic location URIs:

Every time a dynamic location URI is de-referenced a new (potentially different) location is provided. Typically these URIs do not have a constraint with the time. Assume Alice acquires a URI that points to her current location, every time that a location recipient invokes the URI, he will get a different location (assuming that Alice's location changes). Another example can be when Alice acquires a URI that provides her location between today noon and now, so, when the location recipient invokes the URI, he will be accumulating further locations, providing that Alice is changing her location.

Dynamic location URIs have stronger privacy considerations, because the target does not really know what is the location supplied at any time. However, the target has mechanisms to constraint the availability of a dynamic location URI, for example, by imposing a time when the reference expires.

With either dynamic or location URIs there is a need for a mechanism that allows the presentity to publish indirect references. In absence of this mechanism, the presentity would need to retrieve its location information by value, compose a PIDF document that contains it, and publish it to the presence server.

1.3.  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 version of the document does not contain normative text at this point in time given the different options that are available to solve the described problem.

2.  Overview of Operation

A presentity first send a location request (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery] over the binding protocol, indicating the desire to receive its location by reference. This is done by including a <locationType> element with the value set to "locationURI". The server responds with one or more <locationURI> elements, typically with different URI schemas. The presentity then selects a SIP or SIPS URI scheme, and:

[[Editor's Note: We have several options here. We need to pick one.]]

1. Inserts the value of the locationURI in a Geolocation header field, as specified in the SIP Location Conveyance document (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” February 2010.) [I‑D.ietf‑sipcore‑location‑conveyance]. Then, it sends it in a PUBLISH request, which may also contain a regular PIDF document.
   
   

   The drawback of this approach is that it is specific to geolocation and difficult to generalize. Furthermore, it is not possible to determine whether the server actually understands the provided references.
   
   

2. Inserts the locationURI value in a new extension to the PIDF to carry an indirect reference. The extension consists of a new element called "indirect-reference", which is inserted. Then, the PIDF is attached to a PUBLISH request and sent to the presence server.
   
   

   The drawback of this approach is that it is still not possible to determine whether the server supports it. Also, if the referred document is a PIDF, then the semantics would be "here is the reference to an additional PIDF document" as opposed to "include this position some elements that are indirectly referred". The advantage of this approach is that this extension is general enough to include any indirect reference, for example, to a calendar that can publish RFC 4481 extensions to PIDF.
   
   

3. Creates an additional XML document (independent of a PIDF document) and if the presentity also attaches a regular PIDF document, then both documents are put into a MIME multipart/related wrapper, which becomes the payload of the PUBLISH request. Otherwise, the sole new XML document is attached to the PUBLISH request and sent to the presence server.
   
   

   The drawback of this approach is the shy support for multipart MIME bodies. The advantage is a clean solution with no interferences with PIDF. It also allows to include an indirect-reference of any kind.
   
   

When the presence server receives a PUBLISH request that contains an indirect reference, it tries to de-reference, e.g., invoke the URI included there. If the result of such operation is that the presence server gets a presentity's PIDF document, then it should consider the document as directly published from the presentity, and should composed a merged PIDF document, potentially including other sources of presence information.

3.  IANA Considerations

This document has no actions for IANA.

4.  Security considerations

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

5.  References

5.1. Normative References

5.2. Informational References

Authors' Addresses