Subject: RE: [Simple] authorization for presence

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 17 May 2001 09:06:54 -0400

I'm also in favor of more general mechanisms.  One specific that I
need is a more rich sense of presence; that is, there might be
more than a single "state" enumeration of presence.  It might also
be that the state variable has a lot of states, but a presentity
only allows a particular watcher to see a filtered set.  Suppose,
for example, I could set presence to in-the-building, in-the-office,
out-of-the-building, on-cell-phone, or home.  I may want some watchers
to get the exact state, others to only get in/out.

I don't want to see the first version of SIMPLE do all of this, I
want the mechanism to be able to expand reasonably.  Some of this
is easy (add parameters).

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 6:44 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] authorization for presence
> 
> 
> One general objective, I believe, has to be that we can present a
> complete solution, i.e., there needs to be a way to do the 
> authorization
> in SIP. Otherwise, there's no way to build interoperable 
> systems. (This
> doesn't disagree with what Jonathan says, just emphasizes 
> that we can't
> stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an
> explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.)
> 
> Also, as much as possible, naming must be predictable. I'm not too
> thrilled about having to configure the variations of peter_buddylist@
> and whatever else is needed. Making up URLs with designated 
> names is not
> general enough. There may also be other events that require the same
> mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event
> type need such a pairing? Or can we parameterize this to allow other
> events to re-use this meta-event mechanism? (For example, it might be
> possible to use something like Event: foo ;watchers or some 
> variation on
> this, so that every event is treated as a class with a standard
> associated meta-event.).
> 
> Finally, it would be nice if we can avoid special cases. 
> Subscribing to
> the event 'watcherinfo' should not be substantially different than any
> other event. In particular, this must recurse, i.e., subscribing to
> watcherinfo in itself must trigger a notification.
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Folks,
> > 
> > I think its time we begin discussing the second main open 
> issue discussed at
> > the last IETF. Specifically, the issue of authorization of presence
> > subscriptions.
> > 
> > The currently defined method makes use of QAUTH. When a 
> presence server gets
> > a SUBSCRIBE, it sends a QAUTH to the presentity. If the 
> subscription is
> > acceptable, the presentity responds to the QAUTH with a 200 
> OK. The proxy
> > knows to send QAUTH to the presentity because it will send a methods
> > parameter in a REGISTER, indicating that their contact 
> address supports
> > QAUTH.
> > 
> > There are several big problems with this:
> > 
> > 1. the QAUTH transaction will timeout if the user doesn't 
> answer right away.
> > QAUTH, like INVITE, requires human interaction, and so its 
> retransmit
> > semantics don't work.
> > 
> > 2. If QAUTH forks, we will end up receiving the "best" 
> response to the
> > query, which will be a 200 OK if anyone of the forked 
> requests results in a
> > 200 OK. As a result, the policy for merging approvals for 
> subscriptions is
> > forced to be the same as the forking rules, which is 
> probably not what you
> > want.
> > 
> > 3. The model assumes that if I can send a registration for 
> a presentity,
> > that means I am authorized to make policy decisions about 
> subscriptions.
> > That is not necessarily the case. We are really overloading 
> register to
> > imply something else.
> > 
> > So, the proposal I made to resolve this was the following:
> > 
> > 1. We define a new event package, called "watcherinfo". 
> This package defines
> > a subscribable entity, which is the current subscription 
> state for some
> > presentity. Its a list of those active and pending 
> subscriptions for some
> > presentity. When someone subscribes to a presentity, the 
> subscription state
> > for that presentity changes. A new pending subscription is 
> basically added.
> > Since this state is subscribable, a UA can subscribe to it, and get
> > notifications when it changes. In this case, the UA is 
> notified if someone
> > tries to SUBSCRIBE to the specific presentity. The body of 
> the notifications
> > contains the current subscription list for that presentity.
> > 
> > 2. We define an authorization document format for presence. 
> This is a simple
> > document format which indicates the set of subscriber 
> identities that are
> > permitted, or not permitted, to subscribe to a presentity. 
> For example:
> > 
> > allow:
> > sip:a@b
> > sip:b@c
> > 
> > deny:
> > sip:x@y
> 
> Nit-picking: I think we've learned from SDP that positional parsing is
> bad. I would suggest something like:
> 
> + sip:a@b
> - sip:x@y
> 
> Also, it is not clear whether such a denial is for one subscription
> event or "sticky". 
> 
> > 
> > 3. At any point in time (including after receiving a 
> notification that a new
> > subscriber has attempted to subscribe), a UA can push a new 
> authorization
> > document to the presence server. The presence server 
> applies this policy to
> > the current subscription list, dropping or approving 
> subscriptions as
> > needed. This push could happen via HTTP or through SIP, TBD.
> > 
> > Here is an example.
> > 
> > A subscriber, sip:[email-masked], subscribes to some presentity,
> > sip:[email-masked]. The presence server receives the 
> subscription, marks it
> > as pending, and sends a 202. Now, the subscriber list for 
> peter has changed;
> > [email-masked] has been added as pending. [email-masked] has 
> also subcsribed
> > to the subscription state for [email-masked]. It did this 
> previously, by
> > sending a SUBSCRIBE that looks like:
> > 
> > SUBSCRIBE sip:[email-masked] SIP/2.0
> > Event: watcherinfo
> > 
> > Now, since the buddy list for Peter has changed, Peter (and 
> any others that
> > have subscribed), get notifications. The NOTIFY might look like:
> > 
> > NOTIFY sip:[email-masked] SIP/2.0
> > From: sip:[email-masked]
> > To: sip:[email-masked]
> > Content-type: text/xml+buddies
> > 
> > <buddylist>
> >   <pending>
> >     <subscriber>sip:[email-masked]</subscriber>
> >   </pending>
> >   <active>
> >     <subscriber>sip:[email-masked]</subscriber>
> >   </active>
> > </buddylist>
> > 
> > Peter's UA gets this NOTIFY, and responds with 200 OK. It 
> also queries peter
> > about whether to accept this pending subscription from 
> [email-masked]. Peter
> > is away from his desk. He comes back 10 minutes later, and 
> clicks OK. At
> > this point, the UA uploads a new authorization document 
> fragment, using SIP,
> > say:
> > 
> > SETDATA sip:[email-masked] SIP/2.0
> > From: sip:[email-masked]
> > Content-type: text/authlist
> > 
> > accept:
> > sip:[email-masked]
> > 
> > The presence server gets this, and responds with a 200 OK. 
> Sally is now
> > approved.
> > 
> > The benefits of this approach are:
> > 
> > 1. we separate the policies on (1) who finds out about 
> subscription changes
> > for a presentity, and (2) who can set policies for 
> subscription changes for
> > a presentity.
> > 
> > 2. there is no transaction timeout problem
> > 
> > 3. policies on merging multiple authorization documents are at the
> > discretion of the presence server.
> > 
> > 4. We unify setting of policies asyncrhonously, and 
> syncrhonously with the
> > arrival of a subscription.
> > 
> > 5. since authorization policies are a document, not a 
> protocol, they can be
> > exchanged, stored, and manipulated which is very good.
> > 
> > 6. much of this is reusable by other protocols
> > 
> > The slides I presented at IETF 50, where I described this 
> proposal, can be
> > found at:
> > http://www.jdrosen.net/papers/simple_open_mar01.ppt
> > 
> > We need to decide whether to move forward with this 
> approach. Comments and
> > criticisms are welcome.
> > 
> > Thanks,
> > 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
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Ngo, Dai (c)" <[email-masked]>
Date: Thu, 17 May 2001 14:48:34 +0000

I'm new to speak up in this forum. So, forgive me if I show my ignorance.

I agree that QAUTH is having problem. 
But, what if there is an "AUTH" mechanism that only checks/reads the
authorization list (ACL) and sends a 200-class response if the request is
allowed. This can avoid the timeout problem or forking issues. 

The granting of access is left for local implementation. This can be done by
uploading policy database as Jonathan suggested or via other means.

Regards,

Dai Ngo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 May 2001 08:30:48 -0400

> Sent: Thursday, May 17, 2001 9:07 AM
> more than a single "state" enumeration of presence. 

Absolutely. THe presence data format will, in all likelihood, be an XML
document specifically because this will allow us to extend it and provide a
rich, tree-like structure for presence data. Even the baseline is more than
just a single piece of state; its a listing of communications addresses,
each of which is "open" or "closed".

> It might also

The presence package allows subscribers to indicate what aspect of my
presence they want (by carrying a subscription filter document in
SUBSCRIBE), and the proposed authorization mechanism allows presentities to
indicate how they want subscriptions handled (by putting a policy document
in an upload request). In the simplest, baseline operation, the SUBSCRIBE
carries no document, and the policy from the presentity is yes/no per
subscriber. Both can be made arbitrarily complex with more complex
documents.

> is easy (add parameters).

I think what you are asking is exactly provided by the proposed mechanisms.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 May 2001 08:53:43 -0400

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 10:49 AM
To: [email-masked]'
Subject: RE: [Simple] authorization for presence

>But, what if there is an "AUTH" mechanism that only checks/reads the
authorization list 
>(ACL) and sends a 200-class response if the request is allowed. This can
avoid the timeout 
>problem or forking issues. 

Yes, but it doesn't "write" the authorization into the access list in the
presence agent, which is really the whole problem. Reading it was not the
problem.

It is worth noting, however, they will probably will want a read mechanism
so that people can see what changes they've made. 

-Jonathan R.
---

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 21 May 2001 08:42:27 -0500

>I think that having a standard naming convention here is 
>probably a good
>thing. It also seems clear that this concept does go beyond 
>just presence.
>One way to consider it is that every event package has a 
>pre-defined set of
>subpackages:
>
>foo.wachters
>foo.statistics
>foo.policy
>
>or something like that.
>

<snip>

>
>I think the mechanism should allow this, but we don't need to 
>require each
>presence server to support these sub-sub packages. So, for example:
>
>SUBSCRIBE sip:[email-masked] SIP/2.0
>Event: presence.subscribers.subscribers
>
>might generate:
>
>SIP/2.0 489 Package not Supported
>
>
>This example does make me wonder, though; if the package name is
>"subclassed" to indicate watchers, do we need to indicate this 
>in the R-URI
>as well? That is, would the SUBSCRIBE instead look like:
>
>SUBSCRIBE sip:[email-masked] SIP/2.0
>Event: presence.subscribers
>
>I suspect this is probably more correct and in line with the SUBSCRIBE
>architecture.
>

This is a very nice way to handle this problem. But it raises
an interesting question. If I SUBSCRIBE to the Event: presence,
does this include all "sub-packages" as well? When a client SUBSCRIBEs
to "Event: presence", then receives a NOTIFY with "Event: presence.subscribers",
how should it respond, particularly when the client doesn't understand what
presence.subcribers means?

/sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 May 2001 10:03:00 -0400

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Monday, May 21, 2001 9:42 AM
To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne'
Cc: [email-masked]'
Subject: RE: [Simple] authorization for presence

>does this include all "sub-packages" as well? 

No.

>When a client SUBSCRIBEs 

>presence.subcribers means? 

Exactly the reason why a subscription to presence does not imply a
subscription to its sub-packages.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 May 2001 11:31:00 -0400

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:08 AM
> Cc: [email-masked]
> Jonathan Rosenberg writes:
> 
> > foo.watchers
> I like this idea. Should I be including this sort of thing in the
> SUB/NOT draft (since it ostensibly applies to all events), or
> should we leave this to a different draft or set of drafts?

I think the notion of a sub-package should be defined in SUB/NOT. 

> 
> It would seem most appropriate to allow this sort of thing to
> be extensible (e.g. float the idea of generic subpackages in
> the base draft), and then let other drafts define them. In other
> words, a new draft would define the "watchers" subpackage
> which can be applied to any arbitrary package (even other
> subpackages). That's rather cool...

Yup. I agree 100%.

-Jonathan R.
---

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 May 2001 13:31:18 -0400

Hi Adam and Jonathan,

Are we suggesting that _all_ packages would share the sub-package? In this
case, _all_ packages would have a watchers sub-package? It seems that might
unnecessarily encumber a package that did not actually need the sub-package,
and therefore sub-packages would be limited to those with universal
applicability.

If you mean the sub-package is a generic building block that any package
could incorporate if needed, then I agree. I gather Adam is suggesting the
latter, but Jonathan's original note seems to suggest the former.

> Sent: Tuesday, May 22, 2001 8:08 AM
> /a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 May 2001 21:14:27 -0400

> From: Ben Campbell 
> Sent: Tuesday, May 22, 2001 1:31 PM
> To: [email-masked]'; Jonathan Rosenberg
> Are we suggesting that _all_ packages would share the 
> sub-package? In this case, _all_ packages would have a 
> watchers sub-package? It seems that might unnecessarily 
> encumber a package that did not actually need the 
> sub-package, and therefore sub-packages would be limited to 
> those with universal applicability.
> 
> If you mean the sub-package is a generic building block that 
> any package could incorporate if needed, then I agree. I 
> gather Adam is suggesting the latter, but Jonathan's original 
> note seems to suggest the former.

No, I wasn't suggesting anything along those lines. All packages could have
a watchers sub-package (and indeed, the watchers sub-package would allow any
package to use it), but it might never be used, implemented or invoked if
its not needed.

-Jonathan R.

---

---

From: "Francois-Frederic Ozog" <[email-masked]>
Date: Wed, 6 Jun 2001 10:07:24 -0700

watcherinfo event is an elegant proposal.

I would like to propose to extend it to define what attributes or events are subscribable as there are provisions in the standard for other presence attributes and events.

<authlist>
   <subscriber URI="sip:[email-masked]" event="presence" auth="allow" />
   <subscriber URI="sip:[email-masked]" attribute="geolocation" auth="allow" />
   <subscriber URI="sip:[email-masked]" event="presence" auth="block" />
</authlist>

At the same time, why not using the same concept to provision the access rights and piggy-back this in a REGISTER payload, or a new method like AUTHORIZE.

The critical issue though is TRUST. Can I trust the sip URI to build authorization? If the presence service is authenticated by only one server that seems to be OK but what if subscriber A uses SIMPLE service S1 and publisher B uses SIMPLE server S2 ? Authorization model is the first step to defining a trustable service.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 8 Jun 2001 01:53:57 -0400

-----Original Message-----
From: Francois-Frederic Ozog [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 1:07 PM
To: [email-masked]
Subject: RE: [Simple] authorization for presence

>watcherinfo event is an elegant proposal.

Thank you.

>I would like to propose to extend it to define what attributes or events
are 
>subscribable as there are provisions in the standard for other presence 
>attributes and events.
>
>
><authlist>

As I commented earlier, policy can be arbitrarily complex. I want to get us
off to a good start by defining something very simple and easy first, and
then we can define more complex authorization documents down the road as the
need arises. Now, the very first cut may be more than just approve/reject,
but in my mind, the bar is high for things beyond that. 

Event, however, is something that has to be there. This would be a token
that contains the name of the event package that authorization is being
granted or denied for. This is needed since policies for different event
packages will undoubtedly be different (in fact, we already have a need for
that - watcherinfo is a separate event package, and requires different
authorization policies for it!). 

The other thing that we might want to debate about is the contact type. The
initial presence document format being worked on in impp will allow my
presence to contain a list of URIs, each of which describes a different
means of communications. One can easily imagine that I want certain people
to learn about the status of my phone, and others to learn the status of my
IM tool. As such, we might want to think about allowing the policy doc to
indicate what contact schemes or URLs to distribute to which subscribers. 

Attributes, like geoloc, are beyond what I would be inclined to put in the
first version. The impp presence doc format won't even be able to describe
geoloc, so defining a policy doc to control it seems premature.

>At the same time, why not using the same concept to provision the access
rights 
>and piggy-back this in a REGISTER payload, or a new method like AUTHORIZE.

Indeed, one of the main open issues remaining with this approach is how to
upload the authorization doc. We have:

1. http POST
2. SIP REGISTER
3. SIP <new-method>

I'll send a separate note summarizing what I think the pros/cons are with
each, to get the discussion moving.

>
>The critical issue though is TRUST. Can I trust the sip URI to build 
>authorization? If the presence service is authenticated by only one server
that 
>seems to be OK but what if subscriber A uses SIMPLE service S1 and
publisher B 
>uses SIMPLE server S2 ? Authorization model is the first step to defining a

>trustable service. 

I think you are talking about authentication, not authorization. The
presence document provides authorization, keyed on the subscribers identity
in the SUBSCRIBE (From field). The trick is authenticating this ID in order
to reliably apply the authorization policy.

There are a bunch of models here:

1. We believe in PKI. The server S2 can authenticate the subscribe request
from A directly. Everything is great. 

2. Trust by transitivity. The domain of S2 trusts that domain S1 has done a
good job in authenticating its users. When A sends the SUBSCRIBE, the proxy
server in its domain uses standard sip proxy-authentication, and verifies
the identity of the subscriber. The subscription is passed between a proxy
in S1 to the presence server for S2, using a secure transport layer, like
TLS. This allows S2 to verify that requests from S1 are really from S1. So,
if S2 trusts that S1 did its job, we get authentication through
transitivity. The real drag here is the need for interdomain TLS, which can
be a pain for large scale networks.

3. Shared secrets between A and B. I think this is the most workable model.
B knows A, and gives A, ahead of time, a password to use in order to access
B's presence. When the SUBSCRIBE arrives at the presence agent for A, the
SUBSCRIBE is challenged using SIPs digest capabilities. If the subscriber
provides a valid password, they are allowed to subscribe. The only trick
here is getting the passwords from user B to the presence server for B.
There had been some proposals in the iptel working group to standardize some
CPL extensions for this purpose, but the idea was rejected. I think the
easiest way is to use a web interface to the presence server to establish
groups, and associate a digest realm and set of usernames/passwords for
these groups. The usernames/passwords are then stored on the presence
server. We don't need to define any standardized transfer mechanisms in this
case. I think thats OK, since I don't see the need for automata to
distribute these passwords out to potential subscribers. That will generally
be done with a human user, in which case the web interface is fine. The less
that we need to standardize, IMHO, the better.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Jun 2001 10:48:12 -0400

> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Thursday, June 14, 2001 2:48 AM
> To: Jonathan Rosenberg; [email-masked]
> TH>> I guess what confuses me is why do we mix together under the
> TH>> mechanism of
> TH>> active/pending subscriptions (which is nice approach) with
> TH>> the 'set of folks
> TH>> to get
> TH>> notified when someone tries to subscribe to my presence'. The
> TH>> later is a
> TH>> separate application as far as I am concerned.
> TH>> ie I subscribe to an application (presentity) that monitors
> TH>> Bob's watchers.
> TH>
> TH>I am not understanding what you're saying here.
> TH>
> TH>There is a server, and it knows about my presence. My presence is
> TH>effectively state that changes dynamically. When it changes, the
> TH>subscribers
> TH>to that state get notified. That server has another piece of
> TH>state, which is
> TH>the set of subscribers to my presence. Thats state changes
> TH>dynamically too,
> TH>for example, when someone subscribes to my presence. Users can
> TH>subscribe to
> TH>this other piece of state, "presence.watcherinfo", and 
> they get notified
> TH>when it changes.
> TH>
> TH>The set of people subscribed to my presence is unrelated 
> to the set of
> TH>people who are subscribed to presence.watcherinfo. Thus, the set
> TH>of people
> TH>subscribed to my presence (the subscribers of the event
> TH>"presence"), is not
> TH>the same as the set of people subscribed to my
> TH>"presence.watcherinfo". The
> TH>set of people who subscribe to my presence affects the state of
> TH>presence.watcherinfo, by definition, but thats the only coupling.
> TH>
> TH>Does that clarify it?
> 
> 
> Thanks.
> 
> Yes it does clarify it. The confusing part is why do we 
> bother about the
> second state from the standards point of view. Quoting from 
> above "...That
> server has another piece of state, which is the set of 
> subscribers to my
> presence. That state changes dynamically too, for example, 
> when someone
> subscribes to my presence. Users can subscribe to this other 
> piece of state,
> "presence.watcherinfo", and they get notified when it changes..."
> 
> Your description, quoting from above again "...There is a 
> server, and it
> knows about my presence. My presence is effectively state that changes
> dynamically. When it changes, the
> subscribers to that state get notified... " That statement 
> should be enough
> as far as I am concerned.
> 
> Its implicit that we can have sub-packages associated with a 
> presentity.
> 
> 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: Neil Deason <[email-masked]>
Date: Thu, 14 Jun 2001 13:25:58 -0400

> MESSAGE has render semantics associated with it. It means, "the
> body of this request contains data that is to be rendered in
> a reasonable manner for the human to whom I have addressed it."

If that is the defined sematics of MESSAGE I fully agree.
However, the word 'render' is never actually mentioned in
draft-ietf-simple-im-00.txt. In re-reading this draft I am
left unsure what the detailed semantics for MESSAGE are.
Section 6 talks more about syntax and UAC/UAS/Proxy processing
than semantics. Taking your definition, is it limited to
messaging to humans? Does it mean the message data must be
rendered? Is it just for IM style messaging or more general
messaging? I have an assumption based on the traditional IM
clients that have motivated MESSAGE, but the guidelines on
SIP extensions say that SIP SHOULD define general purpose
components rather than narrow ones, even at the cost of some
complexity. Before anyone jumps on me I am only asking questions
not suggesting answers.

There are also important open issues in this area:

9.1 Must a MESSAGE actually include a message?
9.5 What would a body in a 200 OK to a MESSAGE mean?

> What you have suggested is a wildly different application, which
> generally means that you should create a new method for it.

Indeed - to me that is SERVICE.

Cheers,
Neil.

> This is widely overlooked: methods actually *mean* something.
>
> If all behavior were based on content-type and content-disposition,
> we could have saved ourselves a *lot* of trouble by defining a
> transport for sending raw MIME bodies on the wire, and called
> ourselves done.
>
> /a
>
> > Sent: Thursday, June 14, 2001 2:20 AM
> > To: Jonathan Rosenberg; [email-masked]; 'Robert Brown';
> > Theodore Havinis
> > What about using the MESSAGE method to carry the
> > authorization document ?
> >
> > Content-Type header would be set to:
> message/presence-authorization or
> > whatever works like application/simple-authorization...
> >
> >
> >
> > ----- Original Message -----
> > From: "Jonathan Rosenberg" <[email-masked]>
> > To: <[email-masked]>; "'Robert Brown'"
> > <[email-masked]>;
> > "Theodore Havinis" <[email-masked]>; "Jonathan
> > Rosenberg"
> > <[email-masked]>; <[email-masked]>;
> > "'Francois-Frederic Ozog'" <[email-masked]>
> > Sent: Wednesday, June 13, 2001 7:44 AM
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Tuesday, June 12, 2001 12:11 PM
> > > > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg;
> > > > [email-masked]; 'Francois-Frederic Ozog'
> > > > Some recent posts have made it clear that the
> subpackage proposal
> > > > may be widely misunderstood. I'll attempt to clarify a couple
> > > > of points.
> > > >
> > > > > From: sip:bar.com
> > > > > Cseq: 34
> > > > ...
> > > > "Event: watcherinfo" will **NEVER** be a valid thing to
> > say. We are
> > > > proposing this to be a *subpackage*, which means it must
> > be contained
> > > > in another package. For the purposes of the discussions
> we've been
> > > > having here, my guess is that you mean to say "Event:
> > > > presence.watcherinfo"
> > >
> > > Right. A notification for a watcherinfo event to my
> > presence would have
> > the
> > > Event name of presence.watcherinfo. Such a notification
> > would occur when
> > > someone asked to subscribe to my presence.
> > >
> > > >
> > > > One of the consequences of this fact is that, for
> > example, including
> > > > "event" as part of the XML document makes no sense.
> > > >
> > > > ><authlist>
> > > > >   <subscriber URI="sip:[email-masked]"
> > > > attribute="geolocation" auth="allow"
> > > > />
> > > > Since this document will be carried in a NOTIFY which has an
> > > > "Event:" header of "presence.watcherinfo,"
> > >
> > > Well, thats the question. My interpretation of this
> > document above is that
> > > its the thing thats carried in the AUTH (or whatever we
> > defined) method
> > that
> > > sets authorization policy. You are correct that the
> > document carried in a
> > > NOTIFY of presence.watcherinfo has no need to define the
> > event. But, the
> > > document carried in the AUTH does need to define it.
> > >
> > > -Jonathan R.
> > > ---
> > ______________________________________________________________
> > ________________
> > ifrance.com, l'email gratuit le plus complet de l'Internet !
> > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> > http://www.ifrance.com/_reloc/email.emailif
> >
> >
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Jun 2001 16:59:35 -0400

> 9.5 What would a body in a 200 OK to a MESSAGE mean?

We addressed 9.5 in Minnesota. A MESSAGE response may
not contain a body - it would break cpim. 

Issue 9.1 from the document was asking a different
question from what you might have meant. Basically,
it boiled down to "Is it ok to have a MESSAGE request
with and empty body?". We can derive the answer to that
from the consensus we already acheived that while an
implementation MUST be able to receive message/cpim,
it MAY send text/plain. Thus it MAY send an empty
text/plain document. I suspect you rather wanting to
ask "Can a MESSAGE have a payload that isn't a message?".
Outside of the message, and message meta-data like
we have with message/cpim, I hope the answer is no.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Jun 2001 17:42:28 -0400

> > From: Robert Sparks [mailto:[email-masked]]
> > 
> > We touched on a danger point with following this generalization
> > 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.

Has that ever not been true?

I agree fully with what you have below. My point was to remind us
_why_ we went with a subpackage instead of creating a separate
full-blown identity you could subscribe to in order to get this
information.

A system MAY choose to manage authorizations to subscriptions for
the presence.watcherinfo event using the watcherinfo mechanism. It
MAY do this to an arbitrary number of levels.

What I want to avoid is propogation of the following bad logic:
1) This presence server provides authorization for subscriptions
   to _any_ presentity using our mechanism involving a subscription
   to watcherinfo.
2) presence.watcherinfo is a presentity

Therefore, this presence server provides authorization for
subscriptions to presence.watcherinfo via subscriptions to
presence.watcherinfo.watcherinfo. 

Further, through induction, this presence server provides
authorization for presence.watcherinfo.watcherinfo.watcherinfo......
to an arbitrary number of watcherinfos.

This is broken because:

Statement 1) misdirects. It should say "This presence server
provides authorization for subscriptions to Event: presence of
any resource using our mechanism...."

Statement 2) is an over-generalization (if not a mis-generalization).

So, lets be careful about saying things like 2).

RjS

> 
> 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
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 01:34:16 -0400

> From: Neil Deason [mailto:[email-masked]]
> Sent: Thursday, June 14, 2001 1:26 PM
> To: [email-masked]; 'Francois-Frederic Ozog'; Jonathan
> Rosenberg; 'Robert Brown'; Theodore Havinis
> draft-ietf-simple-im-00.txt. 

We need to rectify that. Coming up with a good definition for the semantics
of this is important. I actually like the text Adam has proposed; we should
start with that as a basis.

> Taking your definition, is it limited to
> messaging to humans? 

IMPP went through a similar debate, around presence as well (what about
presence of toasters? stock prices? etc.) The conclusion there was to focus
on the problem for humans, since it is more well defined, and allows you to
make assumptions that are needed to create a decent protocol.

Thats not to say that an IM need only be sent to a human. I can imagine
having a system that receives IMs and stores them, allowing me to review
them from a web page. THis is quite reasonable. THe key, I think, is that
the content in a MESSAGE has no machine-interpretable syntax or semantics. 

> Does it mean the message data must be
> rendered?

The intention is that the recipient wishes it to be rendered. Whether it is
or not, depends on the implementation at the recipient. 

> Is it just for IM style messaging or more general
> messaging? 

IM style. There are many differences between IM style messaging and a
general purpose messaging protocol (ala tibco). One is that human IM
messaging tends to be session oriented...

> I have an assumption based on the traditional IM

There is a difference between well-defined, but generally useful mechanisms,
and ill-defined, and as a result, generally useless mechanisms. Caller prefs
is an example of a well-defined, generally useful mechanism. We continue to
find new uses for it, since it has utility across many applications. But,
the semantics are very well defined, to the point where the proxy algorithms
are even specified with code. 

An example of an ill-defined mechanism that is generally useless, would be
to define a method called DOIT, and then say that the headers and body tell
you what to do. This is guaranteed not to interoperate.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 01:37:20 -0400

> Sent: Thursday, June 14, 2001 1:46 PM
> To: [email-masked]; Jonathan Rosenberg; 'Robert Brown';
> Theodore Havinis
> Now, if we do not need such method, AUTH seems pretty 
> adequate, providing
> that the content can be flexible. For instance, we define 
> authorization
> document version 1, after a few years we refine it with 
> version 2. Or two
> ways of specifying authorization may cohexist: CPL, CGI... 

Yes, the idea is that the specific authorization document can be of a
variety of types. We will define a basic one first, and in the future, they
can get more complex. However, I have argued that in general, if you want
really complex, you don't want to do it through the watcherinfo mechanism.
Rather, the user would pre-specify policies, which could be done in any real
programming language, and you will get the generality you will often want. 

> And I still do
> not like HTTP method as it looses the SIP proxying mechanism: 
> PUA must then
> resolve a PS SIP address down to a non-proxied URL.

I think we can declare consensus on not going with HTTP alone (it need not
be ruled out, but I think enough people think a SIP mechanism is needed that
it has to be done).

-Jonathan R.

---