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

From: [email-masked]
Date: Thu, 4 Jul 2002 15:57:42 +0300

My main concern is that if the PUBLISH gets big enough contents, the PUA has to POST the presence info to some HTTP server and send a PUBLISH to the Presence Server with content-indirection. The Presence Serve then has to GET using HTTP. This is like going around in a circle. Why not just use HTTP in the first place and avoid all this.

BIND to the presence server can help you discover where to publish your presence info using HTTP.

Regards,
Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, June 21, 2002 12:29 AM
> To: Simple
> Cc: Ben Campbell; Jonathan Rosenberg; Brian Stucker; Sean Olson; Jon
> Peterson
> Subject: [Simple] Choosing a mechanism for presence publication.
> 
> 
> 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.
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Jul 2002 14:38:08 -0400

[email-masked] wrote:
> My main concern is that if the PUBLISH gets big enough contents, the PUA
> has to POST the presence info to some HTTP server and send a PUBLISH to
> the Presence Server with content-indirection. The Presence Serve then
> has to GET using HTTP. This is like going around in a circle. Why not
> just use HTTP in the first place and avoid all this.

Well, the indirection is needed only if you don't have e2e congestion 
control. We're working on that.

> presence info using HTTP.

The problem is that the server that you need to publish to may not be 
accessible directly by HTTP. COnsider the example in the draft about the 
PA deep within a multi-level enterprise, or the case where the PA is a 
registered PC.

I can understand the desire for HTTP - I've been on both sides of this 
fence! My current leaning is for sip publish because, practically 
speaking, there were a number of cases where http didn't work. I also 
think that the presence publication problem is sufficiently different 
from a number of other "data publication" things we're looking at (see 
http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt), 
where i do believe HTTP/SOAP is better.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Costa Requena <[email-masked]>
Date: Sat, 6 Jul 2002 21:23:45 +0300 (EET DST)

Hi Hisham,

I completely agree!
If PUBLISH suffer from Content Indirection we are going around the same
problem once more. Would it be much cleaner approach to use HTTP as
publishing mechanism?
BR
Jose

---

From: Costa Requena <[email-masked]>
Date: Sat, 6 Jul 2002 21:30:51 +0300 (EET DST)

Hi,

The problem with PUBLISH is e2e congestion control and that's one of the
drawbacks.
Could it be listed what are the scenarios where HTTP cannot be used. I
see that "draft-rosenberg-simple-data-req-00.txt" clearly set the
requirements for data management and presence publishing is one clear
example. Therefore, it would be wise to list pros and cons of using HTTP
versus PUBLISH.
BR
Jose