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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 3 Jul 2001 22:39:33 -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....

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.

> 
> This avoids the double subscription, and allows all packages --
> even .watcherinfo sub-packages -- to be migrated. If you want
> to use such a mechanism, I could add text to support it; essentially,
> saying that a "NOTIFY" with an "Expires: 0" should be answered
> by an attempt to re-subscribe. If the notifier wanted the subscription
> to migrate, it migrates. If the notifier really wanted to kick the
> subscriber out, it rejects the SUBSCRIBE it with a 403 or similar.

Whatever it is, it definitely needs to be generic and apply to all packages.
No doubt.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 5 Jul 2001 11:09:52 -0400

> From: Robert Sparks 
> Sent: Thursday, July 05, 2001 10:55 AM
> To: Jonathan Rosenberg; [email-masked]';
> [email-masked]
> 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?

How about a compromise approach? Expires retains the meaning that Robert and
I like - which is to define the lifetime of the state in the NOTIFY. We can
define another header, Subscription-Expires, which has the same syntax. Its
present in a NOTIFY and indicates the lifetime remaining of the
subscription. If zero, there can be parameters which indicate the reason for
it becoming zero:

NOTIFY sip:[email-masked] SIP/2.0
Subscription-Expires: 0;reason=deactivated

I still think that it is useful to subscribe to the watcherinfo for the
presentities you watch, in order to be notified of changes in your own
subscription state. Indeed, with watcherinfo defined as a sub-package, this
becomes possible.

I would argue that watcherinfo is still the most correct approach (although
admittedly more complex), as the above approach still mixes two different
things together. Indeed, with the above, I might get a NOTIFY even though
the state of the presentity remains unchanged, which is a bit odd. Might
there be other interactions lurking around the corner....?

-Jonathan R.

---

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Fri, 6 Jul 2001 10:03:01 -0600

Eventually, sufficient presence data from many sources will flow through
aggregators and redistributors. If an expiration isn't linked to each
piece of data individually, the value and usefulness of that data will
be diminished by aggregators and redistributors who will have to assign
some other value to the whole collection.

Moreover, as aggregation and redistribution become common, tracing the
origin of any given piece of presence data will be useful when things go
awry. It might be nice to have in addition a pointer to the originator,
maybe just a fully qualified host name. 

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Friday, July 06, 2001 9:26 AM
To: Robert Sparks
Cc: Jonathan Rosenberg; [email-masked]';
[email-masked]
Subject: Re: [Simple] Open issue: migration of subscriptions

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

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.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 6 Jul 2001 13:11:35 -0400

I think there may be expiration times for each piece of data individualy
within the presence document. This is an issue for impp, which is doing the
presence document format. I know they have talked about timestamps for each
piece of data individually.

So, whilst I agree that you want expirations for each piece of data
individually, that doesn't change the fact that Expires is really referring
to the content of the message, and thus the notification. It may be that
this is frequently not useful, but I'm not sure that means applying Expires
to mean something else is a good idea (namely, expiration of the
subscription).

-Jonathan R.

---
  
-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Friday, July 06, 2001 12:03 PM
To: Ben Campbell; Robert Sparks
Cc: Jonathan Rosenberg; [email-masked];

Eventually, sufficient presence data from many sources will flow through
aggregators and redistributors. If an expiration isn't linked to each piece
of data individually, the value and usefulness of that data will be
diminished by aggregators and redistributors who will have to assign some
other value to the whole collection.
Moreover, as aggregation and redistribution become common, tracing the
origin of any given piece of presence data will be useful when things go
awry. It might be nice to have in addition a pointer to the originator,
maybe just a fully qualified host name. 
--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 
            [email-masked] 
              +1 720 444 4001 
-----Original Message----- 
From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, July 06, 2001 9:26 AM 
To: Robert Sparks 
Cc: Jonathan Rosenberg; [email-masked]'; 

Robert Sparks wrote: 
> a countdown timer indicating the remaining duration of the subscription. 
> 
> only limits our ability to say "Here's a peice of state that's good for