Subject: VCAR: RIGHTS Value Type Ambiguous

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 21 Jan 2002 11:34:16 -0500

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

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

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

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

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.

The problems lies in the fact that the OBJECT and VALUE
rule parts have been overloaded to allow us to specify
all of the following:

(1) The set of stored objects on which the specified
    ACTION is granted or denied (i.e., the selected
    objects).

    For instance, you are granted the right to READ
    objects for which you are the ORGANIZER (which
    does not imply that you are granted the right to
    read the ORGANIZER property);

(2) The part of the selected objects on which the
    specified ACTION is granted or denied.

    For instance, you are granted the right to READ
    the ORGANIZER property of the selected objects
    (which does not imply that you can only read objects
    that have an ORGANIZER property);

(3) Restrictions on the submitted objects.

    For instance, you are granted the right to WRITE new
    objects with the METHOD property set to REQUEST only.

The OBJECT and VALUE rule parts introduce an additional
selection mechanism which is less flexible than the much
debated CAP-QL.  IMHO, using CAP-QL to specify the selected
object and potentially the part of the selected objects on
which the ACTION is granted or denied would get us closer to
shipping CAP.

If the WG agrees, I volunteer to send a proposal to the list.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Jan 2002 10:36:50 -0700

>      ;OBJECT=ATTENDEE;VALUE=SELF

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

	So for a VEVENT with with UPN 'x':

	BEGIN:VEVENT
	...
	ATTENDEE;PARTSTAT=NEEDS-ACTION:Z
	ATTENDEE;PARTSTAT=NEEdS-ACTION:x
	...	
	END:VEVENT

The VCAR allows you to modify ONLY the one that matches.
BEFORE AND AFTER.

>     there is one ATTENDEE property set to himself in the

NOT true as only ONE of them match, if <self>
is not 'Z' it does not match the first one.

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

>     value of the parameter PARTSTAT.

They could modify all ATTENDEEs from UPN 'x' to UPN 'x'.
All other ATTENDEE values don't match.

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 21 Jan 2002 15:16:40 -0500

>         And the PARTSTAT  object had any valule.

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.

> The VCAR allows you to modify ONLY the one that matches.

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.

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

> I read (a) and (b) as the same. If the VALUE of ORGANIZER

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?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Jan 2002 14:52:05 -0700

> anywhere, you can only claim that this is YOUR interpretation

As I wrote VCARs, I guess I can :-)

> specify that you were only allowed to MODIFY PARTSTAT.

I am the author of VCAR - and my intent was to show that
you can restrict them to only be able to modify the PARTSTAT.

> both together with OBJECT and VALUE rule parts causes confusion.

Why? Your previous post did not seem make that point. 
It only shows me that there needs to be more text and examples.

> BEFORE AND AFTER?  Where is that specified?

It applies to the ACTION, where does it say that it only
applies to half of an ACTION?

Remember - ACTION means command, so in that context, why
would you think that it would not apply to all of the command?

> modify PARTSTAT from NEEDS-ACTION to ACCEPTED?

No such requirement exists. It does not seem to be a reasonable
need. An ATTENDEE can not chagne from ACCPTED to DECLINED?
Plus they still have to follow the rules of iTIP. 

> the CAP requirements document.

And it was later un-deferred by this WG. Do you want
NO access control in CAP? Or are you proposing that
it needs to be added as a requirement?

> interpretations that I wrote?

I don't think I understand your question.

(b) Not reasonable, why would you want anyone that is also
    an ATTENDEE to be able  to modify anyones elses PARTSTAT?

(c) Not reasonable, why would you want anyone to modify the
    value another ATTENDEE to themselves?

(d) Same as (c).

> components that have the ORGANIZER property set to yourself?

If you mean you want to be able to read anything?

	GRANT:UPN=*;ACTION=READ;OBJECT=*

Or you want to be able to ONLY read components that have
yourself as organizer?

	GRANT:UPN=*;ACTION=READ;OBJECT=VEVENT,VTODO
          ;OBJECT=ORGANIZER;VALUE=self

> all the same issues again?

They are different issues, there is NO ACL of any kind in CAP-QL.
Using CAP-QL won't work, You would have to define a way
to have

  component.property.paramater
  component.property.paramater.value
  component.component.property.paramater
  component.component.property.paramater.value

It's not the same model because querying for something is not
the same problem as listing what they have access to.

---

From: "Graham Gilmore" <[email-masked]>
Date: Mon, 21 Jan 2002 19:55:54 -0500

----- Original Message -----
From: "Doug Royer" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 21, 2002 4:52 PM
Subject: Re: VCAR: RIGHTS Value Type Ambiguous

> As I wrote VCARs, I guess I can :-)

    Perhaps; but it needs to be explicit in the draft for EVERYONE to have
the same interpretation, else interoperability will be next to impossible.

    If I follow this debate correctly (and no guarantees there ;), Bernard
says :

"The problems lies in the fact that the OBJECT and VALUE
rule parts have been overloaded to allow us to specify
all of the following:

(3) Restrictions on the submitted objects."

    Where the assumption is that the OBJECT and VALUE rule parts each have
ONE of the listed meanings.  (Feel free to correct me if I'm wrong here,
Bernard)

    You seem to be saying that, Yes, OBJECT and VALUE rule parts can have
all of those meanings; in fact they have ALL of those meanings, at the same
time, always.  (Again, feel free to correct me if I'm interpreting your
intention poorly)

    Example 1:

    BEGIN:VCAR
    CARID:UPDATEPARTSTATUS

    So, in this example, the OBJECT and VALUE rule parts specify (1) The
target of the VCAR, that is, the PARTSTAT parameter (with any value)
combined with an ATTENDEE value of SELF, (2) The parts of the selected
objects that can be modified, that is, the CU/CUA can modify a PARTSTAT with
any value, and any ATTENDEE with a value of SELF, and (3) The restrictions
on the final submitted objects, that is, after modifying the object it must
have a PARTSTAT of any value and an ATTENDEE value of SELF.

    The only thing that remains confusing is, how can one be sure that the
PARTSTAT in the VCAR applies (as is presumably the intention) to the
ATTENDEE property whose value is SELF?  This implicit link between the two
OBJECTs isn't expressed anywhere in the VCAR.

    As an example, suppose I want to DENY READ rights for everybody on
events whose DTSTART TZID and DTEND TZID are EST and PST respectively, and
vice versa (for example, an organization is very security-conscious and
doesn't want to permit the viewing of any events corresponding to business
flights of its executives).

    (pardon my poor VCAR grammar if there are any mistakes, but I'm sure
you'll get the drift)

    BEGIN:VCAR
    DENY:UPN=NONOWNER;ACTION=READ
     ;OBJECT=DTSTART:VALUE=*
     ;OBJECT=TZID;VALUE=EST5EDT
     ;OBJECT=DTEND:VALUE=*
     ;OBJECT=TZID;VALUE=PST8PDT
    END:VCAR

    How would a CUA or CS be able to figure out which TZID goes with which
property?

    Graham

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Jan 2002 19:41:31 -0700

> the same interpretation, else interoperability will be next to impossible.

I HAVE NO problem debating the contents, or adding / deleted text,
or being shown I am wrong. But the email point I was responding
to said in effect "that I did not know what the 'intent' was".
And I do as I wrote it - and evidently badly :-)

> The only thing that remains confusing is, how can one be sure
> that the PARTSTAT in the VCAR applies (as is presumably the intention)
> to the ATTENDEE property whose value is SELF?  This implicit link
> between the two OBJECTs isn't expressed anywhere in the VCAR.

Because that is what it means. Lets update the text.

For each object you are thinking about giving access to:

  If your object is 'a' and your object is 'b' and your object is 'c',
  and if the GRANT/DENY line is for object 'a' and object 'b' and
  object 'c' then it matches the object your are testing, then it
  applies.

	(1) ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:user-1
	(2) ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:user-2
	(3) ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:user-3

	BEGIN:VCAR
	GRANT:UPN=user-2;ACTION=MODIFY
         ;OBJECT=VEVENT
	 ;OBJECT=ATTENDEE;VALUE=user-2
	 ;OBJECT=PARTSTAT
	END:VCAR

   (If you replace 'user-2' with '*'  and SELF, then the same
     rule applied, just to every UPN.)

  And then if the MODIFY request from the CUA using UPN 'user-2' to
  the ORGANIZERS calendar contains:

	ATTENDEE;PARTSTAT=ACCEPTED;RSVP=FALSE:user-2

  So, the OBJECT set the user is attempting to modify
  is VEVENT, ATTENDEE, {PARTSTAT and RSVP} where ATTENDEE 
  VALUE is 'user-2':

  Now for EACH object they are attempting to modify:

	UPN=user-2		yes - so far.
	ACTION=MODIFY		yes - so far.
	OBJECT=VEVENT		yes - so far.
	OBJECT=ATTENDEE		yes - so far.
	OBJECT=PARTSTAT		yes for the PARTSTAT object

  	UPN=user-2		yes - so far.
	ACTION=MODIFY		yes - so far.
	OBJECT=VEVENT		yes - so far.
	OBJECT=ATTENDEE		yes - so far.
	OBJECT=RSVP		Nope - not in list.

  So, reject the MODIFY. Feel free to optimize the above in
  your implementation.

>     How would a CUA or CS be able to figure out which TZID goes with which

Your example above (I think) means 'NONOWNER' can not see
any (VEVENT?) where the DTSTART TZID is EST5EDT
.OR. where the DTEND TZID is PST8PDT.

Do this, it solves the ambiguity. You are not comparing
the value of DTSTART or DTEND, so the VALUE=* for them
is not needed:

	BEGIN:VCAR
	DENY:UPN=NONOWNER;ACTION=READ
	 ;OBJECT=VEVENT
  	 ;OBJECT=DTSTART
	 ;OBJECT=TZID;VALUE=EST5EDT
	DENY:UPN=NONOWNER;ACTION=READ
	 ;OBJECT=VEVENT
	 ;OBJECT=DTEND
	 ;OBJECT=TZID=VALUE=PST8PDT
	END:VCAR

For .AND. you you are right, but you don't need the VALUE parameter
to the DTSTART and DTEND because you are not comparing to the
value of DTSTART or DTEND, you are comparing to the VALUE
of the TZID. Plus the OBJECT and VALUE parameters are
multi-valued:

	BEGIN:VCAR
	DENY:UPN=NONOWNER;ACTION=READ
	 ;OBJECT=VEVENT
	 ;OBJECT=DTSTART,DTEND
	 ;OBJECT=TZID;VALUE=EST5EDT,PST8DT
	END:VCAR

So the target of the compare is TZID is for both DTSTART
and DTEND, for each TZID VALUE named.

If is what you want to do is limit who can see the entries based
on who they are, then do it by UPN.

	BEGIN:VCAR
	GRANT:UPN=<list>;....
	DENY:UPN=<list>;...
	END:VCAR

We could expand VCAR to allow named:

(from CAP)
   User Group (UG)

      A collection of Calendar Users and/or User Groups.  These groups
      are expanded by the CS and may reside either locally or in an
      external database or directory.  The group membership may be fixed
      or dynamic over time.

Then we could do something like allow UG or UPN in
the GRANT / DENY properties:

	DENY;UPN=named;...
	DEBY:UG=named;...

The only ambiguity I see is that the TZID is both a parameter in
VEVENT and VTODO (and VJOURNAL?) and a property in VTIMEZONE.
However that really is not a problem because it would be
impossible to create a cross component compare both in CAP-QL
and using a VCAR. So any VCAR provided could not be in
the same object set. They could exist in separate object sets
and they would not interfere with each other.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 22 Jan 2002 11:14:02 -0500

> > > >      ;OBJECT=ATTENDEE;VALUE=SELF

Unless I'm missing something, your first interpretation of

> you can restrict them to only be able to modify the PARTSTAT.

Your first interpretation was basically saying that

   OBJECT=PARTSTAT:VALUE=*

meant that we don't care what the value of PARTSTAT is,
but your intent was to say that the user is only allowed
to modify the PARTSTAT.  What would be the VCAR that would
translate your intent clearly?

> would you think that it would not apply to all of the command?

BTW, the mapping between ACTION and command is NOT 1:1.

See my post on why we can't have a MOVE ACTION:

http://www.imc.org/ietf-calendar/mail-archive/msg03230.html

> Plus they still have to follow the rules of iTIP.

That's beside the point.  More generally:

How would I be able to say that you are only allowed to
modify property P from value V1 to value V2?

In the case of the create command we can easily set
restrictions on the new values, but it doesn't seem
to be the case with the modify command. That doesn't
make sense.

>     value another ATTENDEE to themselves?

That's beside the point.  We are not here to judge whether
specific VCARs are reasonable or not.  We simply have to make
sure that VCARs are flexible enough to allow users to specify
their access rights the way they want regardless if it seems
reasonable to you or not.

I still don't see how I could write a VCAR for the following
statement:

Anybody is granted the right to read all the ATTENDEE
properties of VEVENT components for which he is the
ORGANIZER.

   (1) The set of stored objects on which the specified
       ACTION is granted or denied:

          VEVENT components that have the ORGANIZER
          property set to SELF.

          All ATTENDEE properties only (i.e., we
          are not granting the right to read the
          ORGANIZER property).

>           ;OBJECT=ORGANIZER;VALUE=self

Now, how would I write a VCAR that only grants me the
right to read the ORGANIZER property of VEVENT only,
but only when ORGANIZER is set to myself?

> They are different issues, there is NO ACL of any kind in CAP-QL.

Of course there is no ACL in CAP-QL.  It's a query language.
All I'm saying is that we should be using the same query
language to specify the object to which a given access right
applies.

>   component.component.property.paramater.value

Sorry, I don't understand what you are saying.

CAP-QL shouldn't have any problem defining "the set of stored
objects on which the specified ACTION is granted or denied".
Otherwise, we need to fix it.

> the same problem as listing what they have access to.

I agree it's not the same problem.  But why are VCARs trying
to solve different problems all at once?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jan 2002 16:14:55 -0700

> BTW, the mapping between ACTION and command is NOT 1:1.

It was when it was written :-) When the draft was updated some time
in the past, the VCAR text did not keep up. They should be
mapped 1:1 to commands/METHOD as that is a complete list
of what the CU can do to any object.

> http://www.imc.org/ietf-calendar/mail-archive/msg03230.html

Yes we can have an action MOVE - we just have to define it
as that is what it means. See my reply to that post.

We just define MOVE to mean: It means it gives you ... access.

> modify property P from value V1 to value V2?

No such requirement exists. Why would you want it?
CAP is not designed to replace the iTIP rules. So what
iTIP operation would allow it to be set to an invalid value?
If you want to restrict it for other reasons, then please
provide specific needs. I am not sure I understand your
needs, will this do it?

	DENY:...OBJECT=PARTSTAT;VALUE=<the-one-I-don't-want>

> specific VCARs are reasonable or not.

True - unless you want me to understand your point:-)

Changing some one elses ATTENDEE value (for non-owner) is not a
reasonable need and I can think of no reason to allow it. If it does
not already exist in 2445-2447, then lets just state that in CAP:

	You can't change components for iTIP generated
        objects	unless you are the ORGANIZER or OWNER.
        And the OWNER is limited to local changes only
        when the OWNER is not the ORGANIZER. The only time
	any OWNER can modify the objects in an iTIP generated
	object is when it comes from the ORGANIZER. This applies
	even if there is no specific VCAR. If you do, iTIP breaks.

	Any UPN that is granted access to modify any iTIP originated
	object is in effect given proxy OWNERship access as
	far as the VCAR specifies. And that UPN is limited
	to the same restrictions as the OWNER even if there
	is not a specific VCAR. If you do, iTIP breaks.

>  We simply have to make

Then please specify one that really can be used or needed.
iTIP does not allow it - we don't need a VCAR to define iTIP rules.
And CAP does not extend the scheduling functionallity, it simplyly
allows a CUA to store iTIP objects and their final state in the CS.
We are extending iCalendar by allowing new kinds of objects, but
we have not added, removed, or modified any iTIP operations.

>           VEVENT components that have the ORGANIZER

(They are never "set to 'SELF'" if that is what you mean.
 SELF is a value that is only used in the VCAR to mean the
 currently authenticated UPN)

If you mean you want ORGANIZERS to have access to their own
components?

	GRANT:UPN=*;ACTION=<??>
         ;OBJECT=VEVENT;VALUE=*
	 ;OBJEFT=ORGANIZER;VALUE=SELF

	For each object you are determining if you want to
	give access:

	Is this object a:

	VEVENT			yes - so far
	any VEVENT.*		yes - so far
	ORGANIZER == SELF	(true - applies, false - does not apply)

>           are not granting the right to read the

	I'll assume you ONLY want them
	to have access to the ATTENDEE property?

	BEGIN:VCAR
	DENY:UPN=NONOWNER;ACTION=...;OBJECT=*
	GRANT;UPN=*;ACTION=...;OBJECT=VEVENT;OBJECT=ATTENDEE
	END:VCAR

> but only when ORGANIZER is set to myself?

Do you mean set to 'OWNER'? VEVENT only - remove VTODO
from the above example and replace self with OWNER.

> language to specify the object to which a given access right

Why?

> Otherwise, we need to fix it.

Then how can it be as you say above "...using the same query
language to specify the object to which a given access right
applied." ?

> to solve different problems all at once?

"All at once"?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 22 Jan 2002 18:48:59 -0500

> as that is what it means. See my reply to that post.

You did not reply to this message, or else it
never made it to the list.

Regards,
Bernard

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 23 Jan 2002 15:54:17 -0500

----- Original Message -----
From: "Doug Royer" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 21, 2002 9:41 PM
Subject: Re: VCAR: RIGHTS Value Type Ambiguous

> .OR. where the DTEND TZID is PST8PDT.

    I meant the .AND. case (see the descriptive text above the example).

> ;OBJECT=TZID;VALUE=EST5EDT,PST8DT

    Alright, ignoring the extraneous DTSTART/DTEND values in my example
(which are really beside the point in any case), this new example still
doesn't seem to be very clear.  How could a VCAR interpreter be sure the
creator of the VCAR didn't mean to DENY READ rights for all meetings either
beginning or ending in EST or PST (which was not the original intention)?
There seems to be no way to say target events that look like this (events
representing flights, for example):
    DTSTART;TZID=EST:<value>
    DTEND;TZID=PST:<value>
without also filtering out events that start AND end in one of EST or PST
(regular events that don't span timezones).
   This is one concrete example of the larger problem that the VCAR grammar
implicitly mandates a particular relationship between OBJECTs (which covers
the large majority of cases, granted, but not everything a user might --
reasonably -- want to do).

> the GRANT / DENY properties:

    Sounds like a useful thing to include.

    Graham

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 31 Jan 2002 09:31:28 -0500

>         is not a specific VCAR. If you do, iTIP breaks.

To avoid breaking iTIP, I think we should drop the predefined
CARID:UPDATEPARTSTATUS or at least replace it by a predefined
CARID (e.g., CARID:DEFAULTORGANIZER) that would be more in line
with what you said.

Shall we drop it or replace it?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 10:06:22 -0700

> Shall we drop it or replace it?

Nether. Not the same topic.

UPDATEPARTSTATUS allows for the changing of the PARTSTAT,
not the ATTTENDEE value.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 31 Jan 2002 12:24:54 -0500

> UPDATEPARTSTATUS allows for the changing of the PARTSTAT,

Shouldn't that been done through iTIP?

A invites B and C.   C shouldn't be allowed to
change his PARTSTATS in B's VAGENDA.  Otherwise,
"iTIP is busted".  No?

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Recherche et développement              Tél.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 12:42:53 -0700

> Shouldn't that been done through iTIP?

It can be, however the CU may wish to do that to their own
copy of the ORGANIZER object in the CU's calendar :-)

There are three issues.

	(1) How do I store un-processed iTIP requests in my calendar.

	(2) How do I store the results of MY procesing iTIP requests
            in MY calendar?

        (3) How do I directly update MY PARTSTAT in the ORGANIZERs
	    (or some other) calendar? (not my calendar).

UPDATEPARTSTATUS applies to (3).

If I connect to the ORGANIZERs calendar.
Authenticate.
Ask if I can update my PARTSTAT - yes.
I update it.

> change his PARTSTATS in B's VAGENDA.  Otherwise,

Correct. But UPDATEPARTSTATUS is for B and C to be able
to update A directly.

Don't forget about METHOD:PUBLISH objects, that do not
follow the same rules as METHOD:REQUEST objects.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 31 Jan 2002 15:43:52 -0500

> copy of the ORGANIZER object in the CU's calendar :-)

CARID:DEFAULTOWNER will most probably allow them to.

> Correct. But UPDATEPARTSTATUS is for B and C to be able

Then, I have never seen a definition of CARID:UPDATEPARTSTATUS
that made sure that B and C could not bust iTIP.

Basically, CARID:UPDATEPARTSTATUS would need to select only the
VEVENTs that have the ORGANIZER property set to the address of
the calendar in which they are stored.

Have I finally helped you finding a valid reason to add OWNER()
to CAP-QL? :-)

How about the following definition?

   BEGIN:VCAR
   CARID:UPDATEPARTSTATUS
   GRANT:*
   PERMISSION:MODIFY
   SCOPE:SELECT att FROM VEVENT
         USING_PROPERTIES ATTENDEE att
         WHERE att = SELF() AND ORGANIZER = OWNER()
   RESTRICTION:ATTENDEE = SELF()
   END:VCAR

GRANT all users (*) the right to MODIFY the instances
of the ATTENDEE property set to one of their calendar
adresses (att = SELF()) in the VEVENT components for
which the ORGANIZER property is set to the address of
the VAGENDA in which the VEVENT is stored (OWNER()),
given that the submitted value of the ATTENDEE property is
a calendar address of the current user (ATTENDEE = SELF()).

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 16:08:52 -0700

> that made sure that B and C could not bust iTIP.

If you mean the text in CAP is busted - yep it could be :-)

> the calendar in which they are stored.

Yes.

>    RESTRICTION:ATTENDEE = SELF()

Yes.
         
> a calendar address of the current user (ATTENDEE = SELF()).

Yes.