Indirect Presence Publication with the Session Initiation Protocol(SIP)

The Session Initiation Protocol (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'. The presence information is typically carried in Extensible Markup Language (XML) documents that are compliant with a given XML schema . These presence documents are called 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 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 , Rich Presence Extensions to PIDF (RPID) , or the Contact Information to the Presence Information Data Format (CIPID). 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 . The HELD client on the end host can request Location URI (location by reference) as opposed to as a value (location by value).

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 ). 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 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 ) and send it to a location recipient, such as a presence server.

This document, though, discusses proposals for the scenario envisioned in , where the target or end hosts acquires a reference via the location configuration protocol (step 1 in ), 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. discusses 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: 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. 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.

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

A presentity first send a location request 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.]] Inserts the value of the locationURI in a Geolocation header field, as specified in the SIP Location Conveyance document. 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. 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. 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.