Hello Paul,
I understand what you mean, and you are right.
But, I would like to argue that there are two topics in authorization.
1) First, determining if a watcher is allowed to subscribe, and determine
what to do (allow, block, polite block, ...).
2) Secondly, if he is allowed, you can do all this element-by-element
authorization things you mention below.
What I mean is that it is probably useful to have a feature like a black
list, a white list and a gray list (you don't need all three, a black list
and gray list will do or a white list and gray list).
Maybe this is just an implementation issue. I think we can do with the
current presence authorization rules. It should be possible for the PS
(Policy Server) to construct these lists from the authorization policy.
P.S.: Maybe the idea of black/white/gray lists have been discussed before. I
don't know. I only recently subscribed to the mailing list.
Greetings,
Stefan.
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: woensdag 13 oktober 2004 18:14
To: Markus.Isomaki at nokia.com
Cc: Goeman Stefan; simple at ietf.org
Subject: Re: [Simple] Presence Authorization Discussion B:
Composition/Auth Sequencing
Markus,
I don't follow you - I think the point you make is backward.
First I want to clarify that we are talking about authorization on an
element-by-element basis within the document, as has been proposed.
I also want to assume that that the composer has broad
lattitude it what
it does, and in particular that it is free to construct elements that
didn't exist in any of the inputs. (E.g. it might construct an
<activity> of on-the-phone from other inputs that didn't include any
<activity> element.)
With those assumptions, an authorization policy that precedes and is
independent of composition policy can be ineffective. It may not
authorize inclusion of an <activity> element, but may authorize the
elements that the composer will use to infer it.
To get the intended result in this case, authorization must follow
composition.
Paul
Markus.Isomaki at nokia.com wrote:
Hi Stefan and all,
I agree that it is actually hard to separate composition
and authorization from each other if both of them are
watcher-dependent. (And I think there is some value that even
composition can be watcher-dependent, such as the ability to
show different person information to different watchers.) But
if you assume that the same rulemaker makes rules for both
functions, the rulemaker can at least in theory keep things
consistent even if composition happens first and
authorization after that. But if the composition policy is
not understood by the auth policy rulemaker AND composition
happens first, he can't make even auth rules that have a
deterministic outcome. At the moment, before the details of
composition policy are defined, we are at this kind of situation.
Markus
-----Original Message-----
From: simple-bounces at ietf.org
[mailto:simple-bounces at ietf.org]On Behalf
Of ext Goeman Stefan
Sent: 13 October, 2004 13:08
To: 'simple at ietf.org'
Subject: RE: [Simple] Presence Authorization Discussion B:
Composition/Auth Sequencing
Hello,
I would agree on the order of first composition and then
authorization in
the case that composition would be watcher independent.
But in light of the discussion of watcher dependent
composition I would
favor the other way around (first authorization and the
composition).
Because, does it make sense to do a watcher dependent
composition and spent
time and processing power on it, to find out later that you
will block this
watcher.
Greetings,
Stefan.
-----Original Message-----
From: simple-bounces at ietf.org
[mailto:simple-bounces at ietf.org] On Behalf Of Jonathan Rosenberg
Sent: maandag 11 oktober 2004 9:43
To: Simple WG
Subject: [Simple] Presence Authorization Discussion B:
Composition/Auth Sequencing
We had a lot of list discussion at some point about whether
composition
came first or whether authorization came first, and about
where the line
between one ended and the next began.
I think this is much clearer now in light of the data model,
which very
explicitly separates the roles of composition (correlation,
conflict
resolution, merging and splitting) and privacy filtering based on
authorization rules. The former happens first. Indeed, I
think the data
model gives us a good grounding to start a discussion later
on about
what we might want composition policy documents to look like.
But lets
hold that off until we finish our basic work.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Technology Officer Parsippany, NJ
07054-2711
dynamicsoft
jdrosen at dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple