Re: Comments on CPIM draft 03

Just to clarfy a point:  I was arguing against replacing transaction ids
with three different types of ids (sub, msg, and notify).  That said, as we
all agreed to in London, I think that we need subscribtion id in addition to
the transaction id.

More comments inline and perhaps review my original message with the above
clarification in mind.

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

----- Original Message -----
From: "Peterson, Jon" <[email protected]>
To: "'Athanassios Diacakis'" <[email protected]>; "John D. Ramsdell"
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, September 05, 2002 6:15 PM
Subject: 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.
>

Technically, transaction IDs should suffice.  However:

(a) it will be very confusing as two semantically different things are
merged into one
(b) typically, the software subsystem that deals with transaction ids is at
a lower layer than that that deals with the actual semantics of the
operation.  Exposing the transaction ids to that higher layer will cause all
kinds of head-aches.
(c) although in theory transaction IDs cannot be re-used, because our
sessions are defined to be of infite length, in practice we can re-use a
transaction ID, provided we don't do it too close to the previous usage
(i.e. order of magnitude of retransmissions, or thereabouts).  I'm not
saying that this is a good practice, but implementations may inadvertently
not be able to guarantee the uniqueness.

(a) and (b) are my main concerns.  (c) is not so important.

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

What's the change?

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

Ah.  I see the confusion.  I think John's argument was replacing transaction
id with three separate ones, which I'm against.  I think the best thing to
do is keep transaction ids across all operations, and add subscriptions id
for the operations that need them (subscribe, notify).   I wasn't arguing
above against subscriptioin ids, I was arguing against replacing transaction
ids with subscriptions ids.

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

Yeah.  For example for the retransmission issue that Jonathan R. mentioned.

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

Same thing as before.  Apologies if I was unclear.  I was against replacing
transaction ids with three separate ids.  We need subscription ids in
addition to the transaction ids.

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





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