Re: Comments on CPIM draft 03

inline.

Peterson, Jon wrote:

>>However, this does not 
>>address the second, and more important usage, of matching responses to 
>>requests.
>>
> 
> 
> I did consider this, but there didn't seem to be many risky cases. In what
> cases might the response to an unsubscribe be mistaken for the response to a
> subscribe, or vice versa? Only, obviously, when subscribes and unsubscribes
> are being sent very rapidly to the same target (already, a bit of a corner
> case) and ordering is lost. 

Exactly.

> Once again, we can defer the question to the
> presence protocol, which may or may not guarantee ordered delivery.

Everything in CPIM also exists in the underlying presence protocol. CPIM 
is about specifying what has to be there.

> But if
> ordering is lost in the presence protocol, there are a lot of problems with
> distinguishing an unsubscribe from a fetch, a refresh from a new
> subscription, and it isn't obvious to me how a subscription ID would clarify
> any of that. But I don't mean to argue that I think a transID would add no
> value - just that I want to better understand what value we think it adds.

I dont understand why this is complicated.

Generally, matching responses to requests is something each presence 
protocol needs to be able to do to function. I think we all agree its 
useful in a real protocol. Having this identifier in CPIM means that any 
CPIM compliant protocol has to have a way to match responses to 
requests. All will, of course. So, I don't understand the big problem here.


>>The more important question to address here, is what is the meaning of a 
>>transaction identifier in a protocol that is abstract? I think what it 
>>amounts to is this - any protocol that is CPIM compliant must support a 
>>transaction ID of some sorts, otherwise a gateway between the two cannot 
>>effectively be built. 
> 
> 
> I think this is one of the larger open issues about the core CPIM
> specification, and about how the 'abstract' operations are to be understood.
> What should be deferred to the using protocol (APEX, PRIM, SIMPLE, etc), and
> what must be built here in IMPP? If something must be built here in IMPP,
> how do we go about it? If it is a requirement for the using protocol, how do
> we capture that, how do we enforce it (especially for 'CPIM-compliant'
> protocols that have already gone to RFC), and what do we in turn require
> CPIM gateways to do?

My understanding of CPIM is that any protocol compliant to CPIM must be 
able to specify how to build a gateway to CPIM, mapping to/from every 
parameter in CPIM. Thus, presence of a parameter in CPIM implies that 
the protocol must support the equivalent semantic. Saying that CPIM has 
a transaction ID simply means that any underlying protocol has to have a 
way of mapping a response to a request it corresponds to. Whether thats 
done using transaction IDs in the underlying protocol, by having the 
protocol sequence the requests/responses so there is no ambiguity, or 
something else, is not important.



> 
> I think your argument above could be used against, say, the entire MSGFMT
> draft. We inherit a certain number of requirements from RFC2778/RFC2779, and
> they can either be fulfilled by the using protocol, or we can create objects
> in IMPP and carry require that the using protocol carry them around. 

IMPP is doing both. Its specifying CPIM as a set of common semantics 
that must be present in any protocol. Its also specifying objects that 
must be carried on the wire in order to support e2e integrity through 
gateways. I don't see those as inconsistent goals.


> But To,
>>From and the like are quite likely to be fulfilled by any using protocol,
> and the abstract messaging object in the core CPIM spec already defines
> these attributes. 

Indeed. The idea, as I am sure you understand, is that a common format 
is necesary since this meta-data - the To, From, etc. - are important 
things that need to be covered by the signature. Thus, a real protocol 
probably has those fields too, but when integrity is needed, they would 
be replicated in this common format. So, in the case of SIMPLE:

MESSAGE sip:[email protected] SIP/2.0
From: im:[email protected]
To: im:[email protected]
Content-Type: multipart/signed;boundary=---foo

--foo
Content-Type: Message/CPIM

From: im:[email protected]
To: im:[email protected]
DateTime: 2002-09-05T12:50:00-5:00
Subject: CPIM
Content-Type: text/plain

Is CPIM the same as CMIP?
--foo
Content-Type: application/pkcs7-signature
<signature>


Clearly, To and From are replicated, but that is the nature of this 
beast. SIP works the same way for signed sip messages using s/mime - 
information is replicated in the headers and in the signed body. Here, 
the signed body just happens to be using a slightly-different (but 
parser compatible) format.


Only the message/cpim body really needs to be an
> independent object. So why do we need MSGFMT, why isn't all of this just
> deferred to the instant messaging protocol? Even the most complex MSGFMT
> functions (like its extensibility mechanism) could be pushed up to the
> abstract protocol layer.

The desire was for things like extensibility reuqirements to be signable 
and survivable through gateways. Whether something like that needs to be 
included in the signature, perhaps that can be debated. Things like To 
and From I think clearly do need to be included.


> 
> 
>>This is probably a a moot requirement; a presence 
>>protocol that didn't have a transaction ID, either explicitly or 
>>implicitly, is a non-functional protocol, and thus building a gateway 
>>for it is not really an issue. That said, I think its fine to have the 
>>identifier there in CPIM, since its already there, we have had consensus 
>>on it, and there is no good reason to remove it.
>>
> 
> 
> If we have a transaction ID, a subscription ID, and a notification ID in the
> abstract protocol, what is the resulting requirement? Some protocols will
> not support all three of these as separate identifiers.

Thats OK. So long as they have the equivalent semantic.

> Should we therefore
> author a SUBFMT draft, with a subscription object that is carried around
> (which will be redudant for those protocols that do support one or more of
> the identifiers above)? Or should we demand that all presence protocols must
> adopt support for these three identifiers, and then define how gateways
> would map these identifiers between protocols? Is CPIM the cart or the
> horse?

The format is needed for things that we need signatures over. I don't 
think that includes the transaction identifiers. In fact, since there is 
no "document" associated with subscriptions, I don't know what it means 
to have a subscription format. We have documents for presence, and for 
instant messages, that can be sensibly signed, so there are message 
formats for them.


-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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