Re: status of wg specifications

[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?  If you
just mean an acknowledgement, then I don't think it needs to be in the
CPIM draft.  My reasoning is that CPIM is still a relatively abstract
specification, and a compliant protocol may use a reliable transport
where acknowledgements are not required.

I could be convinced of the requirement for a reply to the
notification iff you could explain what "non-acknowledgement"
information you need in the reply, or what protocol state machine
requires the reply.  I have seen no arguments, yet.

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

Do you have suggested wording to clear up the confusion?

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

Do you have suggested text to add to CPIM?

> 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

-derek

> "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]
> 

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email protected]             www.ihtfp.com


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