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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Jul 2001 10:43:44 -0400

Let's start over.

A and B are both UAs.  I think we all agree on that.
You want a PS.  I'll agree they are useful.  If you
want a PS, then its a UAS to A.  I want to talk
about how PS and B interact.

I don't know if you would allow me to go there, but,
just for a moment, indulge me and let's talk about
A and B without PS.  A wants to know B's presence.
Okay, so A subscribes to B, and B supplies
presence as NOTIFYies.  This all works fine, although
it ignores how B authorizes A.  In particular,
in order for B to authorize A, he needs credentials
for A (who are you).  While the standard SIP headers
might be enough, in many cases, you need more 
information about A.  How do you get that?

With my example, everything (except credentials) is
fine.  In particular, B can send presence to A
because it's really B (B's real UA) that is the
source of the presence info, and we would all agree
that B the human interacts with B's UA in some
implementation dependent manner for B's UA to
find out the actual presence state.

Are we okay here?

Now let's put in the PS.  In your model, just for now,
skip authorization, and let's just talk about how
B tells PS that B's presence state changed.
I can see two possibilities.  The one I like is that
PS subscribes to B's presence.  The other is that
there is a new header that is used for that purpose.
My way is real simple, takes no extension, and does
exactly what you want.  When B changes his presence,
he does so on his UA (exactly as above), and Notifies
PS.  PS, in turn, Notifies A.  Simple, clean, effective.

So what is PS?  I claim it's a straightforward
B2BUA.  Instead of subscribing directly to B, PS
subscribes to B and A (as well as any other authorized
watchers) subscribe to PS.

Now, you introduce watcherinfo.  I'm okay with that.
B subscribes to watcherinfo on PS, and PS Notifies B
of subscriptions.  

Now, back to authorization

In several posts, I've stated that I'm interested in a
rich notion of presence.  That covers a LOT of territory,
but let me give you a small example.  Suppose I have
3 states in my presence model In-Busy-Out.  For
some watchers, I will give them one of these three
states.  However, there are some people for whom I
don't want them to know that I'm in, but busy.  They
only get two states - In/Out.  This is all pretty easy
stuff. 

However, my authorization is not binary.  I have to
tell PS which of the two models A gets.  Two URLs
are not enough.

So, authorization, I claim, is complex.  You need
arbitrary credentials from A, and you need arbitrary outputs
from B. Thus, I claim, there is no sensible way to define the
authorization process between B and PS, or for that
matter, between A and PS in a standardized way.

One way to help would be to at least tell A where 
to go to at least FIND OUT how to get authorization.  
Simply subscribing (attempting to subscribe) is not enough.
If you want to turn that around and say, fine, let's
also tell B how to authorize, I can't argue.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 10:03 AM
> To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)';
> [email-masked]'; Ben Campbell
> Cc: [email-masked]
> Subject: RE: [Simple] Another idea for presence authorization
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Wednesday, July 11, 2001 2:25 PM
> > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)';
> > [email-masked]'; Ben Campbell
> > Cc: [email-masked]
> > Subject: RE: [Simple] Another idea for presence authorization
> > 
> > 
> > Well, I'm real confused.  
> > 1. The "automata" you are talking about -- I don't understand
> > what role it has in the context of this discussion.  We have
> > "servers" that have presence information and "clients" that
> > want to get it.  The server is an entity operating on behalf of a
> > presentity.  The client is an entity operating on behalf of a 
> > watcher.  In
> > SIP terms, we have a UAC and a UAS.  
> 
> Its more complex than that, Brian. 
> 
> I'll repeat the picture I just sent in a previous email:
> 
> 
> 
>          |                  |                      |
>          |                  |SUB B's pres.winfo (1)|
>          |                  |<---------------------| B's 
> client turns on
>          |                  |200 OK             (2)|
>          |                  |--------------------->|
>          |                  |NOTIFY             (3)|
>          |                  |--------------------->|
>          |                  |200 OK             (4)|
>          |                  |<---------------------|
>          |                  |                      |
>          |SUB B's pres  (5) |                      |
>          |----------------->|                      |
>          |202 Accepted   (6)|                      |
>          |<-----------------|NOTIFY "A Pending" (9)|
>          |NOTIFY B's pres(7)|--------------------->|B learns that A
>          |<-----------------|200 OK            (10)|      subscribed
>          |200 OK         (8)|<---------------------|
>          |----------------->|                      |
>          |                  |                      |
>          |                  |                      |
>          |                  |Set policy        (11)|
>          |                  |<---------------------|
>          |                  |                      |
>          |                  |                      |
>          |                  |                      |
>          |                  |                      |
> 
>       Subscriber          Presence              Presentity
>          A                Server                   B
> 
> > The UAS
> > is the agent of the presentity, and the UAC is the agent of
> > the watcher.  Now, where is this automata?  In the UAS?
> > The UAS is what the protocol defines, you seem to want to deal
> > with something that is not the UAS but is connecting to it.
> 
> There is a presence server, which is a UAC for some 
> transactions, and UAS
> for others. There is a subscriber A, which is a UAC for some 
> transactions
> (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a presentity
> application for B, which is a UAC for some transactions 
> (SUBSCRIBE to its
> watcherinfo), and a UAS for others. Remember, UAC/UAS is a 
> per transaction
> role. The presence server is the "agent" for B, in the sense 
> that it accepts
> subscribes and generates notifies on B's behalf. How it finds 
> out about the
> presence state is another orthogonal piece, not specified in 
> the SUB/NOT
> mechanism. Typically, its through registrations or through 
> direct upload of
> a presence document.
> 
> 
> > 
> > At the moment, the model I'm imagining in your head is one
> > where the presentity and the watcher are both UACs and there
> > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger
> > idea.  If that is the model you are pushing, I want to push
> > back.  The UAC is the agent of the presentity, the UAS is the
> > agent of the watcher, and the UAC doesn't need any protocol
> > to the presentity -- it "is" the presentity.  
> 
> I cannot map these statements to sensible definitions of UAC and UAS,
> presentity or watcher. Please see above.
> 
> > If you want
> > the presentity to be a UAC, then we need more than what we
> > are talking about on this thread - we need to standardize
> > how the UAC at the presentity tells the UAS how to change its
> > presence, and then we get into all sorts of issues about 
> > how this model supports rich presence information (since it
> > requires that two UACs AND the UAS all have the same
> > capabilities).  How the UAC interacts with the presentity
> > is not the place we standardize.  It could be split into
> > a "client" and a "server", but the interactions between those
> > pieces are complex, and I don't see how we could standardize
> > them right now.
> 
> I still cannot understand any of the above based on the 
> definitions of UAC
> and  UAS in the bis spec, and presentity, watcher, etc. from rfc2778.
> 
> > 
> > 2. I never used Yahoo Messenger.  I just loaded it.
> > Yes, you get a message when someone puts you in his
> > friend list.  However, what it is asking you seems to be
> > whether you want to put him in YOUR buddy list.  In particular,
> > if you reject, you are still in his friend list, and he sees
> > your presence. 
> 
> No, thats not true. When I subscribe to someone, they appear 
> in my buddy
> list, and the status is marked as "pending authorization" 
> until the time
> that they provide authorization. Once that happens, I see their real
> presence. On the other side, when someone subscribes to me, I 
> get a screen
> pop, which asks for "approve", "approve and add", or "reject".
> Approve/reject have the meanings we've been discussing - they 
> approve or
> reject the subscription. "approve and add" approves the 
> subscription, and
> also sends a subscription from me back to them, adding them 
> to my buddy
> list. 
> 
> I've been using this tool for several years. I think I can make these
> statements with soem confidence that they are correct.
> 
> -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: "Daniel Starin" <[email-masked]>
Date: Fri, 13 Jul 2001 11:59:06 -0400

Brian,

It seems that there are two different issues you are discussing.  

One is whether or not A (the watcher) may access any of B's presence
information (a binary decision) and the other is IF B indeed allows A to
access presence information, what type of information will that be, -
In/Out, In / Busy/Out, etc.

Regardless of what complex presence information a user may have, there
will always be an initial binary decision (yes, you can access presence
or no, you cannot).  Because this decision must always be made for each
and every subscription request which is made, it may be reasonable to
standardize how this will be done.

-Dan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, July 13, 2001 10:44 AM
To: 'Jonathan Rosenberg'
Cc: [email-masked]
Subject: RE: [Simple] Another idea for presence authorization

Let's start over.

Are we okay here?

Brian

>          |                  |<---------------------| B's 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple