Re: status of wg specifications

I would add one more issue on CPIM. 
This is the one I mentioned at Minneapolis meeting. 

There is an inconsistency between CPIM and CPIM-MSGFMT. 

In draft-ietf-impp-cpim-02.txt, section 2.3, 

     An INSTANT MESSAGE comprises a MIME
     Type="message/cpim,profile=im" object, as defined in
     XML/MIME[6] and MESSAGE/CPIM PROFILE FOR INSTANT
     MESSAGING. 

But, there is no description about the "profile" parameter in the MSGFMT doc. 
Because I believe MSGFMT has passed WGLC, the CPIM doc should be 
changed.  Section 3.3 contains similar text for presence. 


-- Hiroyasu Sugano


----- Original Message ----- 
From: "John D. Ramsdell" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, May 14, 2002 8:35 PM
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]