RE: Comments on CPIM draft 03

A few notes below, some of which speak to one of the larger open issues with
CPIM.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email protected]]
> Sent: Thursday, September 05, 2002 1:42 AM
> To: Peterson, Jon
> Cc: 'Athanassios Diacakis'; [email protected]; [email protected]
> Subject: Re: Comments on CPIM draft 03
> 
[snip]
> 
> Your arguments above talk to the first usage for the transaction ID. If 
> one ignores the retransmission problem (perhaps based on the argument 
> that CPIM is an abstract protocol anyway), you are probably right that 
> the additional identifier isn't needed, that a subscription ID plus 
> other inforamtion can identify the transaction. 

Quite. More on abstract protocol requirements below.

> 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. Once again, we can defer the question to the
presence protocol, which may or may not guarantee ordered delivery. 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.

> Generally speaking, a lesson I have learned (the hard way) from other 
> protocol design activities is the value of a very explicit and well 
> defined transaction identifier.

Understood and agreed.

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

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

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

Judging from the way MSGFMT was handled, I think that historically the WG
has favored the approach that leads to SUBFMT. But our job in IMPP, I think,
it is to define the absolute minimum amount of information that needs to be
able to pass through a gateway to make these functions end-to-end
interoperable. If we can cut a corner on a parameter here and there, I think
it might make the difference between something that can be mapped between
using protocols by a gateway, and a new subscription object that will be
tunneled through gateways.

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