Indirect Presence Publication with the
Session Initiation Protocol(SIP) EricssonCalle Via de los Poblados 13MadridES28033Spainmiguel.a.garcia@ericsson.comNokia Siemens NetworksOtto-Hahn-Ring 6MunichBavaria81739GermanyHannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.atColumbia UniversityDepartment of Computer Science450 Computer Science BuildingNew YorkNY10027USA+1 212 939 7042schulzrinne@cs.columbia.eduhttp://www.cs.columbia.edu/~hgs
RAI
SIMPLE Working GroupSIPindirectPUBLISHSIP 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. 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. This document has no actions for IANA. The security considerations described in SIP Location Conveyance are applicable to this document.