[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VCAR: RIGHTS Value Type Ambiguous
Doug Royer wrote:
> Bernard Desruisseaux wrote:
> > The semantic of OBJECT and VALUE rule parts is ambiguous.
> > To illustrate this fact, here's possible interpretations
> > of two very simple VCARs.
> > Example 1:
> > BEGIN:VCAR
> > CARID:UPDATEPARTSTATUS
> > GRANT:UPN=*;ACTION=MODIFY
> > ;OBJECT=PARTSTAT:VALUE=*
> > ;OBJECT=ATTENDEE;VALUE=SELF
> > END:VCAR
> Read it as, for each object that you are checking, if the
> rule matches - then the GRANT or DENY applies.
> And the result MUST match the GRANT or DENY.
> For example (1) this GRANT would apply to you if:
> you wanted to MODIFY
> And the PARTSTAT object had any valule.
> and ATTENDEE is <self>.
Given that the semantics of OBJECT and VALUE is not defined
anywhere, you can only claim that this is YOUR interpretation
of this VCAR.
Furthermore, given that this VCAR's CARID is UPDATEPARTSTATUS
(taken from section 11.2 of the latest interim version of the
draft) I have big doubts that your interpretation matches the
intent of the author of this VCAR. Why would he have specify
"And the PARTSTAT object had any valule"? This would be useless.
It is clear, to me at least, that the author's intent was to
specify that you were only allowed to MODIFY PARTSTAT.
As I mentionned in my previous post, the OBJECT and VALUE rule
parts are trying to specify too many things at once. For instance,
this VCAR is trying to restrict the stored objects you are allowed
to MODIFY (ATTENDEE set to <self> in our case), and to specify
restriction on the submitted object (the submitted object can
only change the value of PARTSTAT in our case). Trying to specify
both together with OBJECT and VALUE rule parts causes confusion.
> So for a VEVENT with with UPN 'x':
> The VCAR allows you to modify ONLY the one that matches.
> BEFORE AND AFTER.
BEFORE AND AFTER? Where is that specified?
How would I be able to say that you are only allowed to
modify PARTSTAT from NEEDS-ACTION to ACCEPTED?
You could propably argue that it's not a requirement, but
then Access Rights as a whole is marked as "deferred" in
the CAP requirements document.
> > (a) Anybody is granted the right to modify, to any value, the
> > PARTSTAT parameter of ATTENDEE properties set to himself;
> > (b) Anybody is granted the right to modify, to any value, the
> > PARTSTAT parameter of any ATTENDEE properties, as long as
> > there is one ATTENDEE property set to himself in the
> > component;
> NOT true as only ONE of them match, if <self>
> is not 'Z' it does not match the first one.
> > (c) Anybody is granted the right to modify, to any value, the
> > PARTSTAT parameter, as long as he modifies the ATTENDEE
> > property to himself as well;
> NOT true as it is only true IF he is the ATTENDEE,
> else he can not modify it. And yep - your VCAR allows them to
> modify the value of the ATTENDEE, as long as it is already
> set to 'x'. And you could modify the value, as long as the
> rule still was valid - so the only thing you could modify
> it to is 'x'
> > (d) Anybody is granted the right to modify the value of any
> > ATTENDEE property to himself, regardless of the stored
> > value of the parameter PARTSTAT.
> They could modify all ATTENDEEs from UPN 'x' to UPN 'x'.
> All other ATTENDEE values don't match.
If you think OBJECT and VALUE rule parts are not ambiguous,
can you propose a different VCAR for each of the four
interpretations that I wrote?
> > Example 2:
> > BEGIN:VCAR
> > GRANT:UPN=*;ACTION=READ;OBJECT=*;
> > ;OBJECT=ORGANIZER;VALUE=SELF
> > END:VCAR
> > (a) Anybody is granted the right to read everything in
> > components for which he is the ORGANIZER;
> > (b) Anybody is granted the right to read the ORGANIZER
> > property of components for which he is the ORGANIZER.
> 'property of components' ?
> I read (a) and (b) as the same. If the VALUE of ORGANIZER
> is 'x', you can read it.
> I don't see your points.
How would I write a VCAR to grant you the right to read
everything, that is, not only the ORGANIZER property, in
components that have the ORGANIZER property set to yourself?
After all the energy that was spent in this WG to define
CAP-QL, I think it would be a big mistake to use a different
selection mechanism in VCARs. Do you really want to go over
all the same issues again?
Bernard Desruisseaux mailto:bernard@xxxxxxxxxxx
Research & Development Tel. : +1 514 733-8500 x4213
Steltor Fax : +1 514 733-8878