Subject: Re: [Simple] immediate notify issue

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Feb 2001 12:33:56 +0100

What the discussion seems to boil down to is that the model of having 
subscriptions' fate being decided by the client whose presence is being 
reported is not workable.

A more workable model seems to be:

- Presence service decides on the fate of a subscription, and either responds
   with a failure to the subscribe, or sends an OK and a NOTIFY.

- Presence service informs presentity of subscription as soon as the
   presentity is available (or when it asks for the info).
   Note: it should probably also be informed of unsuccessful subscriptions.

- Presentity can order the presence service to cancel a subscription at
   any time.

No special cases. But a CPL might be desirable for the presentity to inform 
the presence service about its desires.
--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: James Undery <[email-masked]>
Date: Wed, 28 Feb 2001 15:42:57 +0000 (GMT)

> - Presentity can order the presence service to cancel a subscription at

I don't really follow how this is different, if anything it is worse as it
specifically tells you the state of the presentity rather than making you
deduce it. If the presentity is offline you also get to know when they
come online without doing any further work. The third point does raise a
related issue about how to display current subscriptions to a subscriber
without exposing presence info. (If you think I am wandering in a paranoid
fantasy land here's where to turn off it's getting worse.)

If subscriber can get the present list of their subscriptions and the
presentity can remove them the subscriber will be able to see this, and
subscribe again. I still think maintaining the facade of the user being
offline and the subscription intact best protects the presentity, ideally
you'd also never respond with anything other than a 200 or 202 to
refreshes of existing subscriptions. As this then forces an attacker to
let the subscription lapse so they can get a 600 class response
indicating sometime during the life of the subscription the presentity
was on line and rejected them, this could be limited by allowing the
mandating of a minimum expiry time returning a 488 Not Acceptable Here be
returned if the expiry on a subscription was too short. 
(This last bit is poorly thought out and I don't like it myself.)

> 
> But a CPL might be desirable for the presentity to inform 

This I certainly agree with.

James Undery