datetime - was -> RE: status of wg specifications

> 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.

In DATETIME, there was the problem that it allowed use of either 'T' or 't'
and 'Z' or 'z'.  That makes it incompatible with the XML Schema dateTime.
Removing one sentence in the ID is all that it would take to make it so only
'T' and 'Z' is allowed.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, May 14, 2002 4:36 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: status of wg specifications
> 
> 
> 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.
> 
> 2. CPIM conflates a subscription ID with a transaction ID.  These two
>    objects are distinct.  Transaction IDs are used to match a request
>    with it's corresponding reply, while subscription IDs identify a
>    subscription.  A literal interpretation of CPIM would suggest to
>    the reader that subscription IDs can only be represented as
>    transaction IDs.  In any event, the specification is needlessly
>    confusing.
> 
> 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.
> 
> Of course, what really bothers me about CPIM is that the specification
> of the notify operation in Section 3.4.2 was done in a way that seems
> to preclude an interoperable notification in which the notification is
> authenticated using a digital signature.  This is because the
> specification provides no parameter to the notify operation that
> naturally identifies the server that invoked the notify operation.  As
> a result, there is no mechanism to bind the server's certificate to a
> parameter of the operation.
> 
> I've made all these points before, so I know not to expect changes to
> CPIM, however, I want to be sure no one assumes I concur with the
> opinion that CPIM should become an RFC in its current state.
> 
> By the way, the SIMP servers that were deployed at the NATO exercise
> described in the SIGNAL magazine article signed all notifications they
> generated.  I was not there, but I assume every client was configured
> to ignore all unsigned notifications.  This is to be expected in a
> secure environment.
> 
> John
> 
> "Mark Day" <[email protected]> writes:
> 
> > > I've lost track.  What is the status of the working group's
> > > standards-track
> > > specifications?
> > 
> ...
> 
> > Once PIDF is done, I think that CPIM and MSGFMT are 
> basically good to go.
> > 
> > --Mark
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 


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