Subject: RE: [Simple] authorization for presence

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Jun 2001 13:39:03 -0400

We touched on a danger point with following this generalization
to far at the last meeting. If you take the first statement below
literally, then we have to worry about managing authorization for
the presence.watcherinfo presentity using the same mechanism we're
discussing, leading to a telescoping problem. We'ld have servers
having to handle subscriptions for presence.watcherinfo.watcherinfo.

The comment in the meeting was that authorization for 
presence.watcherinfo would be provided somewhere outside
the scope of this protocol (using static lists provisioned
with an account was one suggested way a service could provide
this - whatever other ways made sense to the domain would be valid).

RjS
 
> > Actually I tend to see 'presence.watcherinfo' as a 
> presentity itself.
> 
> Sure, thats another way to look at it. The only differece is 
> that the type
> of information sent to subscribers of this 
> "pseudo-presentity" is different
> than a normal presentity, since they are different event packages.
> 
> I think we are agreeing, but differ only on how to view the concept.
> 
> -Jonathan R.

---

From: [email-masked]
Date: Thu, 14 Jun 2001 14:49:12 -0500

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> 
> to far at the last meeting. ...[W]e have to worry about managing
> authorization for the presence.watcherinfo presentity using the
> same mechanism we're discussing, leading to a telescoping problem.
> We'ld have servers having to handle subscriptions for
> presence.watcherinfo.watcherinfo.

One of us is confused.

If a client *wants* to subscribe to presence.watcherinfo.watcherinfo,
and it contacts a server which is able and willing to provide
this type of meta-meta-state, I don't see what's wrong with that.

I don't beleive that anyone has ever suggested that a server supporting
a particular subpackage for one package MUST support it for all possible
packages it knows about. It could very well be (and I expect it will
usually be the case) that a server implementing presence.watcherinfo
would return a 489 in response to a SUBSCRIBE request for
presence.watcherinfo.watcherinfo. We don't require them to, but they
might. That same server could also very well also support
"Event: mailnotification," but reject "mailnotification.watcherinfo."

And that's whats just so nifty-keen about subpackages: the semantics
can be well enough defined that they can apply to any package
(including themselves and other subpackages), but we're not
*forcing* anyone to implement more than they need or want to.

/a