Re: status of wg specifications

My comments are inline.

John

Derek Atkins <[email protected]> writes:

> [email protected] (John D. Ramsdell) writes:
> 
> > For the record, I think CPIM-MSGFMT and DATETIME are well done and
> > good to go, as you put it, but I continue to think that CPIM is
> > flawed.
> > 
> > 1. CPIM specifies there is no reply to a notification, but protocols
> >    such as SIMPLE specify and make use of replies.  It seems to me
> >    that a notification should receive a reply, and a valid reply
> >    should be "indeterminant".  Gateways into systems that do not
> >    produce a reply to a notification would immediately generate an
> >    indeterminate reply.
> 
> What information do you think needs to be in such a reply?

The same information that is in a response to an instant message.
Your logic implies the CPIM spec needs not specify replies to instant
messages. 

> > 2. CPIM conflates a subscription ID with a transaction ID.  

...

> Do you have suggested wording to clear up the confusion?

I would be happy to provide text on this issue.  One simply needs to
define a subscriptionID similar to the definition of a transID, and
allow a response to have an optional parameter containing a
subscriptionID that is included in a response to a subscribe operation
which includes a non-zero duration as a parameter.  Since I have
already raised this issue, I realize there is little chance for change
at this time.

> > 3. The CPIM document seems to be internally inconsistent.  Section
> >    3.4.3 states there is no explicit UNSUBSCRIBE command, but Section
> >    8 contains XML syntax for this command.
> 
> Dave?
> 
> > Of course, what really bothers me about CPIM is that the specification
> > of the notify operation in Section 3.4.2 ...

> Do you have suggested text to add to CPIM?

As I stated in a later message, I realize this is a lost cause, and
issue should not have been raised.  I really mean to focus on finding
a common subscription data format.  

By the way, all one needs to do to fix this is add an optional
"regarding" parameter that, when present, identifies the presentity in
those cases in which the from field only identifies the server
providing the information.  The regarding parameter would be required
whenever a server signs notifications.

John


  [reminder: [email protected] for non-technical discussions, please]