RE: Comments on CPIM draft 03

I don't think discussions get too lively around here any more; but
nevertheless, a few notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Athanassios Diacakis [mailto:[email protected]]
> Sent: Wednesday, September 04, 2002 6:22 PM
> To: Peterson, Jon; John D. Ramsdell
> Cc: [email protected]
> Subject: Re: Comments on CPIM draft 03
> 
> 
[snip]
> 
> 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.
> 

It is worth noting that CPIM-03 currently doesn't define the transID
parameter in this fashion, or indeed in any other non-self-referrential way
(i.e. "The transID parameter specifies the transaction-identifier associated
with this operation").

[snip]
> 
> 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.
> 

Your argument above does not illustrate why transIDs, with the one small
functional difference (which was what I thought Mr. Ramsdell had proposed),
would not suffice to serve as purpose of the subscription IDs in question.
In his proposal, as before, each time a subscription request that intends to
initiative a new subscription is sent, a new transID is used - but, and this
is the difference, the same transID would be allowed in subsequent
subscription operations (with duration '0' or longer) if they want to refer
to this initial subscription. Since transIDs can never be re-used for new
subscriptions, that original transID will always identify the initial
subscription operation. Any subsequent subscription refresh or
unsubscription operation can choose to refer to that original subscription
by its unique transID in order to affect the subscription. Fetch operation
can choose different transIDs, even when they target the same presentity, in
order to avoid affecting any pre-existing subscription. In this fashion, one
could have multiple persistent subscriptions, each associated with a
different transID, to the same presentity - they could be torn down or
refreshed independently with the transID. 

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

I think the distinction between having two persistent subscriptions to the
same presentity, and fetching from a presentity to whom one already has one
persistent subscription, is moot. They both have the same requirements. A
fetch is just a very short-lived 'multiple subscription'. There's no
question that multiple subscriptions is the requirement that motivated the
subscription ID. The question is whether or not a slight change to transID
makes the need for subscription ID go away.

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

'having' or 'not having'?

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

I think that's interesting, actually. Can you motivate that further? Why do
you need to differentiate between different notifications at the CPIM layer,
as opposed to at the PIDF layer?

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

Um... I'm kind of getting lost here. Are you arguing for or against having a
subscription identifier? I thought above you were motivating it as something
distinct from the transID? But here you seem to be saying that we only need
one identifier, which is what I thought Mr. Ramsdell had proposed... his
last message about this, I thought, proposed three identifiers as a
straw-man, to show that these three identifiers were really being used for
the same purpose in different contexts, and therefore having only one
identifier would suffice. John, am I understanding you correctly?

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

True. You're right, this is an orthogonal issue.

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



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