RE: Comments on CPIM draft 03

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. Then again, it isn't any more clear how the
subscription ID would be recovered in this case, if it were a separate
identifier.

Is there some other motivation for differentiating the two IDs?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Athanassios Diacakis [mailto:[email protected]]
> Sent: Tuesday, September 03, 2002 5:41 PM
> To: Peterson, Jon; [email protected]
> Cc: [email protected]
> Subject: Re: Comments on CPIM draft 03
> 
> 
> > > 6. Section 3.4.3 and Section 3.4.4 refer to a subscription ID, but
> > >    never define what it is.  For an unsubscribe 
> operation, I assume
> > >    the subscription ID is the transID of the subscription 
> operation
> > >    that established the subscription, while the subscription ID
> > >    for a fetch operation is any transID not currently in use.  The
> > >    assumptions on IDs must be explicitly stated.
> > >
> > >    Of course, we may want to be explicit about the role of
> > >    identifiers, as suggested by Thanos in
> > >
> > >       
> http://www.imppwg.org/ml-archive/IMPP-WG/200207/msg00007.html
> > >
> >
> > Yes, I agree that this needs to be clearer. For the time being it is
> > probably simplest to just remove the term 'subscription ID' 
> and use the
> term
> > 'transID' in its place, with the semantics you suggest 
> above. Whether or
> not
> > we need a subscription ID really hinges on the degree to 
> which CPIM is
> > standardizing a practice for subscriptions. A subscription 
> identifier
> would
> > probably only be meaningful in CPIM if the context of the whole
> subscription
> > operation in CPIM were a little more clear.
> >
> 
> Having both transaction ids and subscription ids was agreed 
> to and closed in
> London (see the minutes here:
> http://www.ietf.org/proceedings/01aug/51-17.htm)
> 
> Thanos
> ---
> Athanassios Diacakis, CTO
> Personity, Inc.
> [email protected]
> 
> 



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