RE: draft-ietf-impp-pres-01

"Peterson, Jon" <[email protected]> Mon, 13 Jan 2003 19:15:33 -0500
Newsgroups gmane.ietf.impp
Message-ID <[email protected]>
Notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Thanos Diacakis [mailto:[email protected]]
> Sent: Thursday, January 09, 2003 2:42 PM
> To: Peterson, Jon; John Ramsdell; [email protected]
> Subject: Re: draft-ietf-impp-pres-01
> 
> 
> Jon Peterson wrote:
> > I assumed it would be intrinsically globally unique. Each time a watcher
> > issues a new subscription operation, it must use a new SubscriptID. I
don't
> > think this is particularly burdensome.
> >
> > Incidentally, I think we do want to allow a given watcher to have
multiple
> > subscriptions to the same presentity - that has been accepted as a
> > requirement. Even if we were not to allow them to exist concurrently, it
> > would still be useful to differentiate subscriptions over time.
> 
> Inherently, it makes more sense to me for this to be unique to the
> watcher/presentity pair.
> 
> This uniqueness requirement could be quite burdensome in some scenarios.
A
> simple scenario is where a "client" doesn't intend to use the multiple
> subscriptions feature.  If the SubscriptionID needed to be unique just for
> that particular watcher/presentity pair, this "dumb" client could use the
> same subscription ID everywhere, or use some less strict mechanism to
issue
> those, instead of having to guarantee global uniqueness.
> 

Some have argued that it could be valuable to have multiple subscriptions
(concurrently or over time) from the same watcher for the same presentity.
That seems to be the primary argument. 

And again, I have a hard time imagine a plausible client that is so dumb
that it can't think up new unique SubscriptionIDs as necessary. In what way
is this difficult?

> Thinking of this in a different way, whether we agree or not on what the
> burden is going to be, is there any good reason for doing it this way,
> instead of making it unique just for the watcher/presentity pair?  Note,
> that implementations *CAN* use the stricter requirement if they want to.
> 
> Thanos
> ---
> Thanos Diacakis
> Openwave Systems
> [email protected]
> +1-303 385 6705
> 
> 



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