Re: Comments on CPIM draft 03

Folks,

This is lengthy (and I aplogize in advance), and contains nothing really
new.  We've discussed this on the list and in person before, but hopefully
should clear any confusion, or more likely, generate lively conversation :-)

Transaction IDs are there to uniquely identify a particular "transaction"
which is a request, followed by zero or more requests and/or replies.  I
think in CPIM this is usually just a request-reply, but may be just a
request.  I do not recall anything more complicated than that.  The purpose
of the identifier is to (a) match the reply to the request, and (b) to
distinguish it from other transactions (i.e. request replies).  The
transaction ID is unique for a particular session of exchanges between two
entities.

[Sidenote: Actually, this is a place where CPIM is weak because it is not a
protocol, the idea of a session is not exactly defined.  This is not too bad
because we could define a session to be an exchange between two entities of
infinite duration. Essentially this means that a transaction ID can never be
re-used between a given pair of To: From: addresses (though if it does, it
shouldn't cause any problems as long as the two uses are not close enough to
eachother so that some entity has some recollection of the first transaction
when it sees the second transaction).]

Transaction IDs shouldn't be used for anything else (semantically
unrelated), because if they do it gets complicated and we get into
discussions such as this :-).  More on this further down.

Now, in London we discussed the need to be able to place multiple
subscriptions to a particular presentity.  Every time that one wants to
subscribe, fetch or unsubscribe, they need to specify which subscription
they want to affect (as now they can be many).  This is done by introducing
a new identifier (subscription ID) that indicates which subscription we are
talking about.  Actually, Notify requests need that too, as mutliple
notifications will take place when you have multiple subscriptions.
Subscription IDs are unique for a particular To: From: combination, meaning
the same SubId for a given pubisher/subscriber pair, is semanticlly the same
subscription.  Of course the same SubID for different pub/sub pairs is a
different subscription.

BTW, there is some text in 3.1 about a watcher having only one subscription
to a presentity that needs to be fixed.

Having said that, there are a few remaining points:

1. Jon is correct in stating you need the subscription ID in order to make
fetch to work (without an explicit fetch), but I think incorrect in stating
that this is the motivation for subscription IDs.  The actual motivation is
to have the ability to have multiple subscriptions, and there are various
reasons as to why that is useful that I can rant about separately.

2. John's thinking about having message ids, subscription ids and
notification ids, is feasible, but I will argue, not desirable, for two
reasons:

(a) The fact that notifications to not have replies to match to the requests
doesn't alleviate the need for a transaction identifiers.  The receiver
still needs the transaction id to differentiate between different
notifications.
(b) all three identifiers have the same purpose - why have 3 instead of one
? - particularly keeping in mind that in implementations you want to keep
the transaction ids at a lower layer than that of the separate transactions
(such as sub, notify, etc), so you can deal with them once, in one place.

3. This issue is orthogonal to the issue of having one or more ids, but here
goes anyway:  Recovering the subscription ID (or whatever ID) should not be
an issue.  The entity that will issue, say, an unsubscribe command, better
know that it earlier had issued a subscribe command, and similarly it will
remember the subscription id.  (Really it needs to "remember" the whole
subscription, id and everything).

Thanos
---
Athanassios Diacakis, CTO
Personity, Inc.
[email protected]

----- Original Message -----
From: "John D. Ramsdell" <[email protected]>
To: "Peterson, Jon" <[email protected]>
Cc: "'Athanassios Diacakis'" <[email protected]>; <[email protected]>
Sent: Wednesday, September 04, 2002 6:51 AM
Subject: Re: Comments on CPIM draft 03


> "Peterson, Jon" <[email protected]> writes:
>
> > 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
>
> ....
>
> > Is there some other motivation for differentiating the two IDs?
>
> >From the write up, I'm not quite sure.  Please answer this question.
> Suppose we replaced transaction IDs in the CPIM document by three
> other IDs.  For instant messages, we use message IDs, for
> subscriptions we use subscription IDs, and for notifications, we use
> notification IDs.  Have we changed the intent of CPIM?  Is there an
> essential reason why the IDs for the three different CPIM operations
> have the same name, or is the reason simply a matter of economy of
> keystrokes?  It appears that transaction IDs are used for different
> purposes by the three operations.  For example, sometimes they are
> used to match responses with requests, but in the case of
> notifications, this use makes no sense.
>
> John







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