Subject: RE: [Simple] Another idea for presence authorization

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 5 Jul 2001 09:28:38 -0400

Why can't the request to subscribe fail if there is no
authorization?  Provide the URL in the response.

Get authorized, try subscribing again.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2001 12:21 PM
> To: 'Rosen, Brian'; Jonathan Rosenberg; Ben Campbell
> Cc: [email-masked]'
> Subject: RE: [Simple] Another idea for presence authorization
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Tuesday, July 03, 2001 12:00 PM
> > To: 'Jonathan Rosenberg'; Ben Campbell
> > Cc: [email-masked]'
> > Subject: RE: [Simple] Another idea for presence authorization
> > 
> > 
> > Maybe one of the issues that is causing confusion is that
> > there are actually two "subscription" kinds of things.
> > 
> > One is the one where you get the human involved - will you
> > as presentity allow so-and-so as watcher presence information
> > (along with what kind/how often/....).  That has a possible
> > long delay, and lots of policy, and, as Jonathan has pointed
> > out, possibly no protocol.  When you decide, a database records
> > your choice, but there is no SIP.
> > 
> > Then you get right down to the actual user agent trying to
> > get the Notifies to come.  That too is a "subscription",
> > but it happens AFTER the former thing, has no UI, no delay,
> > no policy, and very much is a protocol thing.
> > 
> > Let's keep them straight.  Maybe we need some terminology:
> > 
> > Suppose we call the first "authorization" and the other 
> > "subscription".  Both have to be authenticated.  Thus you
> > would have to be authorized before you could subscribe.
> 
> The complexity is that one (subscription) will frequently 
> need to trigger
> the other (authroization). That is, when someone suscribes to 
> me for the
> first time, there is no authorization policy. In order to 
> make a yes/no
> decision on the subscription, the particular application 
> scenario might
> require that I be notified of the subscription in order to generate an
> authorization decision. So, the authorization policy here is
> "pseudo-real-time", in the sense that its triggered based on 
> a subscription.
> 
> However, because, ultimately, its still the process of providing
> authorization, and also, still may not happen immediately after the
> subscription arrives, I like the model of having a single 
> mechanism for
> providing authorization. That mechanism is server specific, I 
> argue, and
> ideally done through web interfaces. By providing the URL to give
> authroization, the process can be facilitated and can even be 
> done without a
> browser, for simple cases at least. More complex policy is 
> going to be too
> complex to do in a protocol.
> 
> -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: [email-masked]
Date: Mon, 9 Jul 2001 10:46:52 -0500

> authorization?  Provide the URL in the response.

Largely because it's crucial that an unauthorized subscription,
a denied subscription, and a subscription to the presence of
an offline user be completely and utterly indistinguishable
from the point of view of the subscriber.

/a