Subject: RE: [Simple] Questions/comments on draft-olson-simple-publish-00.txt

From: [email-masked]
Date: Tue, 16 Jul 2002 10:34:39 +0300

Hi,

Ben Campbell wrote:
> > 3. In section 1.1.1 it says "Each PUA publishes a full view 
> of presence 
> > from its perspective--each publication carries full state, 
> and does not 
> > depend on previous states for the particular PUA." Why 
> can't each PUA 
> > publish incremental/differential presence state - after all the 
> > compositor should have the logic to handle this.
> 
> If you by incremental state, you mean a situation where the 
> compositor 
> cannot intepret a publication P(n) without also having received P(0) 
> through P(n-1), then that is a much bigger problem than we were 
> attempting to solve.

I think there should be a way to publish only limited changes to the composite presence state. If a user has a single device from which he publishes the presence state, it does not make sense to allways send the full document/state when some small bit changes. Talking about CPIM, I think it should be possible to publish changes in each tuple separately, without the need to always send all of them. I don't think "diff" type of deltas are needed, but there should be some kind of granularity. (Actually, the same should apply to SUB/NOT too.)

From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a single device should be able to partition the presence state as well, which seems to require multiple PUAs per device?

Markus 

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 09 July, 2002 22:01
> To: Sriram Parameswar
> Cc: [email-masked]
> Subject: Re: [Simple] Questions/comments on
> draft-olson-simple-publish-00.txt
> 
> 
> Sriram Parameswar wrote:
> > Hi:
> > 
> > Overall I liked the document and agree with its purpose. 
> Just have a few 
> > questions and comments:
> > 
> > 1. The draft seems to take it for granted that the 
> Compositor/Presence 
> > Agent supports the PUBLISH method. Given that we already 
> have presence 
> > deployed - I would like to see some mechanism to (a) 
> establish that the 
> > compositor/presence agent supports the PUBLISH method (b) a 
> fallback 
> > mechanism in case it doesn't: example back to using 
> REGISTER or other 
> > mechanisms.
> 
> The draft is only proposing a mechanism. It does not in anyway assume 
> that other mechanisms do not exist. If the compositor 
> supports other SIP 
> methods, but not PUBLISH, I would think 504 responses and OPTIONS 
> provide a sufficient mechanism to discover this.
> 
> If you are asking that we mandate that all compositors 
> support REGISTER 
> as a fallback for backwards compatibility, then I do not agree.
> 
> > 
> > 2. I understand the motivation to limit PUBLISH to event state 
> > publishing. However since we are taking the trouble to add 
> a whole new 
> > method to SIP, I would like to see you establish some extensibility 
> > mechanisms within the method so it may be extended to publish other 
> > things like CPL, etc. I do not buy the argument in the 
> Abstract that 
> > there are better mechanisms to publish things like CPL.
> 
> By limiting the scope, we were not trying to say it was not 
> possible to 
> use it for other things. We were trying to say that we did not worry 
> about requirements beyond those for event publishing.
> 
> > 
> > 3. In section 1.1.1 it says "Each PUA publishes a full view 
> of presence 
> > from its perspective--each publication carries full state, 
> and does not 
> > depend on previous states for the particular PUA." Why 
> can't each PUA 
> > publish incremental/differential presence state - after all the 
> > compositor should have the logic to handle this.
> 
> If you by incremental state, you mean a situation where the 
> compositor 
> cannot intepret a publication P(n) without also having received P(0) 
> through P(n-1), then that is a much bigger problem than we were 
> attempting to solve.
> 
> > 
> > 4. The whole motivation for slots (and future 
> standardization of slot 
> > names) and the use of the PTYPE header, may be solved if cpim-pidf 
> > simply adds the RFC2778 mandated "Contact Means". I have 
> contacted the 
> > pidf authors on this. Is there any other need for the PTYPE 
> header - the 
> > Contact Means tag would carry the same meaning.
> 
> We still may need the ptype to deal with situations where the 
> compositor/PA might not otherwise interpret the payload. Even 
> if all the 
> info we need is in the cpim-pidf payload, other event type 
> payloads may 
> not have this information.
> 
> > 
> > 5. PStream tracking - the document reiterates that PUBLISH does not 
> > establish a dialog, as dialogs create state to keep track 
> of. Then the 
> > discussion on REGISTER says "However, this does not guarantee that 
> > clients will follow the rules, and thus, sequencing may be 
> lost as a 
> > result". If the Compositor/PA has to keep track of PStream to keep 
> > temporal ordering - how have we reduced the state that has to be 
> > maintained. Also if clients do not 'follow the rules' and 
> uses different 
> > Pstream values for PUBLISH, again sequencing is lost. I am 
> not sure that 
> > PStream buys us anything more than simply requiring clients 
> to PUBLISH 
> > using the same Call-ID.
> > 
> > Regards,
> > 
> > 
> > Sriram
> > __________________________________________
> > Sriram Parameswar              Phone: 972-685-8540
> > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > Nortel Networks, Richardson USA  Email: [email-masked]
> > 
> 
> 
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Jul 2002 03:01:28 -0500

> From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a…

The model in the publish draft is entirely a logical model. There is no 
reason at all why a single physical device could not publish to multiple 
slots.