RE: Comments on CPIM draft 03

Way back when discussion on this transID/subID topic started, I said:

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

I think now the context of the whole subscription operation in CPIM is
becoming at least somewhat clearer. Some other notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, September 11, 2002 11:52 AM
> To: Peterson, Jon
> Cc: [email protected]
> Subject: Re: Comments on CPIM draft 03
> 
> 
> "Peterson, Jon" <[email protected]> writes:
> 
> > I agree that the way the 'operations' in the core CPIM spec are
currently
> > specified, it isn't clear if they are intended to ....
> 
> Of course, rather than abolishing transaction IDs for request/response
> matching, another alternative is to add text making in very clear the
> intended role of the IDs in the specification by, for example, making
> it clear protocols don't actually have to have transaction
> IDs--concrete protocols must just implement the semantics implied by
> them.
> 
> If transaction IDs are only for matching requests to replies, its
> still not clear to me why the notification operation has them.
> 

Point taken. I suspect that no one wants to close the door on a possible
notification acknowledgment operation, which could make use of a transID;
even though CPIM doesn't define such an operation, many presence protocols
do, and use a transID for correlation.

> On the topic of subscription IDs, I note the change I suggested which
> used transaction IDs as subscription IDs had two flaws (at least).
> One was that transaction IDs were being used for two logically
> distinct purposes, and another one is that presence user agents
> generated subscription IDs.  With this design, a CPIM compliant
> protocol could not use the convention that subscription IDs are
> generated by a presence service. 

I'm a little unclear on what the intention behind this would be. The watcher
sends a subscription operation to a presence service, right? Presumably,
there is no cost associated with a watcher selecting a unique subscription
identification at that time. In your proposal, would the subscription
operation actually contain no subscription identifier?

> In other words, one cannot have the
> case in which a client requests a subscription, and receives the ID in
> the response.  

Okay...

> Is it our intension to require that only presence user
> agents select subscription IDs?
> 

Well, there are a couple of reasons I think we might make that simplifying
assumption, yes. I think in this case the burden of proof would probably be
on your side: is there some reason why we need to allow a presence service
to generate the subscription ID?

> John
> 
> 



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