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

From: "Sriram Parameswar" <[email-masked]>
Date: Thu, 4 Jul 2002 14:11:16 -0500

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.

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.

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.

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.

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]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 09 Jul 2002 14:01:29 -0500

Sriram Parameswar wrote:
> 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 

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.

> 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