Subject: RE: [Simple] SIMPLE BoF agenda

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 06:53:07 -0500

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2001 7:22 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Simple] SIMPLE BoF agenda
> 
> > > Yes, however, I was thinking about authentication generally.
> > > Apart from issues
> > > of trust and authentication QAUTH suffers from transaction
> > > timeouts i.e. a PUA
> > > comes online and is sent a QAUTH the user has to respond
> > > before the transaction
> > > times out. (I now this issue was raised before!) This is why
> > > I thinking about
> > > push mechanisms, beacause QAUTH gets messy and really
> > > requires a second new
> > > method to work. (The server sends a QAUTH and gets a 202
> > > back, when the user
> > > allows or disallows the subscription the new method is used
> > > to communicate the
> > > result. This is very ugly.)
> >
> > So, are you saying some kind of pull mechanism, sip or not, 
> isn't needed?
> > Or, are you saying that the pull mecahnism shouldn't be sip?
> 
> I really think using the current QAUTH proposition is far 
> from ideal and if it
> can't be improved something else (non SIP based) should be 
> considered. The
> transaction time-out issue is a real killer, I'd be 
> interested in comments on
> using Subscribe and Notify for pull mechanism (my only 
> concern at the moment is
> horrendous recursion).

Well, there is a way to use SUB/NOT that would allow us to converge the
push/pull mechanisms.

Consider the set of subscribers to a presentity as a piece of dynamically
changing state. Call this state the "subscription list for presentity A". I
can easily imagine that it is possible for entities (typically, presentity
A) to subscribe to this state. So, when it changes (such as when a new
subscriber X asks for a subscription to A), this causes a NOTIFY to be sent
to anyone watching "subscription list for presentity A" - probably A. Now,
at this time, A can choose to push a new policy list to the server. This new
policy list is one which blocks X. Whenever a presence server receives a new
policy, it automatically runs that policy against existing subscriptions. 

Note that we even proposed a data format for representing the state of
"subscription lists". See
http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo-
00.txt.

So, lets assume that we use a CPL variant to express policy. Assume http is
used to push these policies into the server. The flow would look like this:

subscriber               presence server                  presentity

SUB
------------------------------>

202 OK
<------------------------------           NOTIFY w/ subscription state
                              ---------------------------------->
                                           200 OK
                              <----------------------------------
                                   http POST w/ CPL
                              <----------------------------------
                                   200 OK
                              ----------------------------------->

In this way, policy information is always passed using a single mechanism,
but it is triggered using a NOTIFY.

-Jonathan R.

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

---

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

> subscriber               presence server                  presentity
 
I think this is a better solution as with a properly configured policy
list/script it would address info leakages (for those concerned with
that sort of thing) by defaulting to display offline until the subscriber 
was accepted.

James Undery