Subject: [Simple] Choosing a mechanism for presence publication.

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Jun 2002 16:29:06 -0500

Several of us have engaged in an offline discussion on how to handle the 
publication of presence imformation from a PUA to a remote PA. We think 
we have reached a preliminary conclusion on the mechanism choice. This 
email reflects (what I believe to be) the consensus of that group so 
far. The bottom line is, there is significant advantage in using a SIP 
based mechanism.

There has been some controversy over the choice of mechanism by which
SIMPLE presence user agents publish information to remote presence
agents. The two most favored approaches so far have been the creation of
a new SIP method for the purpose, and the use of HTTP.

Nature of Presence Publication:

We propose a model for presence composition where more than one PUA may
publish on behalf of a single presentity. Those PUAs may exist in
separate administrative domains. The publications eventually make it to 
a logical network element that composes the views of presence sent by 
the various PUAs into a composite presence document. For the moment, at 
least, we are calling this logical element a "compositor". This model 
implies a few assumptions for publication:

1) A PUA must be capable of remotely publishing a presence document to a 
compositor. There is no requirement so far for the PUA to query a PA to 
determine what document it had published previously. We assume the PUA 
can subscribe to the final composed document via SIMPLE.

2) A presence document can be expressed by a MIME body part.

3) The document published by a PUA to a particular input is not
dependent upon previous publications to that input. The only transaction
semantic for a given input is "replace". (Note that this does not
prevent the compositor from applying complex application semantics to
compose the input, along with all other inputs, into a composite
presence document.) Any versioning is handled by payload itself.

4) The composition semantics belong to the local policy of the
compositor. The PUA does not need to understand these semantics, and
cannot expect to make composition policy choices as part of the
publication action. If a principle needs to make composition policy
decisions, that is through some other mechanism.

5) There may be multiple PUAs publishing on behalf of the same
presentity. There is no assumption that these PUAs all connect through
the same network, or even belong to the same administrative or security 
domain.

Differences between HTTP and SIP publication:

HTTP is well suited for moving data around in the form of MIME body
parts. An HTTP client-to-server publication solution would not require
much work to specify. A SOAP over HTTP solution would additionally allow
complex transaction semantics with little additional work.

HTTP, however, does not have a well-defined routing model at the
application level. It works fine if the publication point is well known
and fairly static, but it will require additional work to deal with
situations where the publication point changes dynamically.

SIP, on the otherhand, is built around the concept of mobility of
endpoints. The SIP proxy, registrar, and location service concepts
provide a rich mechanism of finding a dynamically changing endpoint from
and address of record.

SIP, however, does not have an existing method suited for presence
publication. REGISTER gets us part of the way, but has well-known
limitations when used for this purpose. SIP is, by nature, also adept at
moving around MIME payloads, so the creation of such a method is not a
particularly difficult task.

Motivation for a SIP based mechanism:

The application-level routing capabilities of SIP can be very useful for
presence publication. If all PUAs for a given presentity exist in the
same administrative domain, then they can most likely publish directly
to a compositor. But if PUAs exist outside the administrative domain, it
is likely they will not be able to do so.

For example, suppose that Alice uses a presence service that allows
multiple PUAs to publish to a compositor inside the service provider
network. Further suppose that Alice wishes to incorporate presence
information from an external provider, that has no business relationship
with her primary provider. For this example, Alice wishes to use a
shared browsing service that tracks the "location" she is currently
browsing in the web. That service acts as a PUA on Alice's behalf, and
publishes the information to her primary presence provider. Other users
of the shared browsing service can subscribe to her presence
information, and determine when they are browsing the same site.

The presence provider is highly unlikely to allow the external PUA to
send data directly to the compositor. But if Alice registers a contact
with a methods parameter value of "PUBLISH", that PUA can send a publish
request to an edge proxy in the presence providers network, and use
Alice's address of record as the requestURI. This AoR could be her
normal SIP URI, or it could be a special AoR for the purposes of
presence publication. The proxy forwards the request to the compositor,
without the external PUA having to talk directly to the compositor, or
even know its IP address.

Now consider that Alice's primary providor is actually an enterprise.
That enterprise has different compositors for different departments. The
external provider has no way of knowing this internal organization, nor
does it know what department Alice works in. Still, Alice register's her 
publication contact at an enterprise registrar, the external
provider sends the publish request to Alice's address of record, and the
companies internal SIP network handles things from there, eventually
getting the request to the correct compositor.

The composition model does not at first appear to require publishing to
dynamically changing PAs. But a very powerful, but often forgotten,
aspect of SIMPLE is it allows a PA to exist on an end-user device.
Indeed, some early implentations of SIMPLE rely on exactly that model.
It is reasonable to expect the composition model above to co-exist with
end-user device PAs, where the PA location changes dynamically.

For example, imagine Alice hosts a PA on her PC, which aquires its IP
address via DHCP. This address changes relatively frequently, and 
registers a publish contact with an enterprise registrar. Now,
imagine she also has a mobile phone which contains a PUA. She wants her
presence document to show a combined view of her PCs concept of her
presence and her mobile phone service's concept of her precence. She
cannot simply tell the mobile service her PC address since it changes
often. Instead, she tells the service an AoR to publish presence to.
The mobile service publishes presence state to that AoR, which resolves
to a SIP proxy or redirect server. Normal SIP proxy or redirect behavior
is invoked to get the publication to Alice's PC based on her publish 
contact registration.

It is our opinion that SIP style routing is very useful for presence
publication. Without the application level routing capabilities of SIP,
it would be difficult to build these sort of services. It is more
appropriate to add a publication mechanism to SIP than to standardize
SIP-style routing features for HTTP proxies.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 20 Jun 2002 22:12:32 -0400

I feel that this is going in the right direction and agree with the 
conclusion to use a SIP enhancement for doing publication.

	Tony Hansen
	[email-masked]

Ben Campbell wrote:
> based mechanism.  ...