Subject: RE: [Simple] Open issue: migration of subscriptions

From: Robert Sparks <[email-masked]>
Date: Thu, 5 Jul 2001 10:54:35 -0400

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, July 03, 2001 4:40 PM
> > To: 'Jonathan Rosenberg'; [email-masked]
> > Subject: RE: [Simple] Open issue: migration of subscriptions
> > 
> > 
> > I like the overall idea, but I see a much easier way to do it.
> > 
> > In draft-roach-sip-subscribe-notify-03, I described a mechanism
> > by which the notifier can let the subscriber know that the
> > subscription has been kicked out: send a NOTIFY with an 
> > "Expires: 0".
> 
> Hmm. Thats definitely simpler. 
> 
> The one nagging doubt I have is whether this is really what 
> Expires means in
> a NOTIFY. You'd think the proper interpretation is, "the 
> state described in
> this notification is no longer valid after the time in the 
> expires header".
> Perhaps its just an academic concern....

I rather prefer this interpretation of Expires. I certainly want
that to be is meaning when the Expires value is non-zero and not 
a countdown timer indicating the remaining duration of the subscription.

For Expires: 0, coupling "The state described here is no longer valid"
with "You will receive no future Notifications in this subscription"
only limits our ability to say "Here's a peice of state that's good for
the rest of the week - I'm not going to tell you any more".

Is that a problem?

> 
> It also would be useful for telling you only one of the reasons why a
> subscription might be destroyed. There are other reasons - normal
> expiration, change in policy, etc. THe right behavior for each are
> different. Normal expiration should result in a subscription 
> within the same
> call leg. Migration requires a new subscription with a new 
> call leg. With
> change in policy, there is nothing you can do.
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 06 Jul 2001 10:25:48 -0500

> the rest of the week - I'm not going to tell you any more".

It might open up a kettle of worms in the situation where you have rich 
presence data, not all of which expires at the same time. It almost 
seems the concept of data expiration belongs to the data format, not the 
transport.