Re: Comments on CPIM draft 03

inline.

Peterson, Jon wrote:
> The justification given in London for having a separate transaction ID and
> subscription ID, as far as I can gather from the minutes, was to
> differentiate a fetch operation from an unsubscribe operation (since they
> both have the same syntax, a subscription with a duration of 0) when a
> previous subscription is in place. It seems useful to be able to fetch
> presence at any given time, even when you have a previous subscription in
> place, without tearing down any existing subscription.
> 
> Mr. Ramsdell's proposal below is that the transaction ID of a (persistent)
> subscription operation becomes effectively the subscription ID for that
> subscription. A fetch operation targetting the same presentity would use a
> new transaction ID; an unsubscribe would use the same transaction ID as the
> original subscription.  Presumably a subsequent subscription with the same
> transaction ID and a non-zero duration would be a refresh. Doesn't this
> provide the differentiation required by the London use case? The only snag I
> can see off the top of head would be if an entity that was not privy to the
> original transaction ID (possibly the watcher's own user agent after an
> ungraceful reboot) wants to unsubscribe - it isn't clear how the transaction
> ID could be recovered. 

There are two reasons for the transaction ID. One is for the recipient 
of a request to differentiate retransmissions of that request from new 
requests. The second is for the sender of a request to match the 
response to the request, as Thanos has indicated. That is quite 
orthogonal to the subscription ID, which serves as an identifier for a 
series of transactions that refer to a common "subscription state".

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. However, this does not 
address the second, and more important usage, of matching responses to 
requests.

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.

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

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