Re: VCAR question

[Bernard Desruisseaux <bernard@xxxxxxxxxxx>]

"Paul B. Hill" wrote:
> 
> Hi,
> 
> There is no "write" VCAR action or permission...
> 
> From cal-updates:
> 
> "The ACTION rule part defines one or more CAP actions that are allowed
> for the UPN. The valid values are CREATE, DELETE, MODIFY, MOVE, READ,
> and all of the [iTIP] scheduling commands; PUBLISH, REQUEST, REPLY,
> ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding to the
> scheduling commands; and '*', meaning all of calendaring commands and
> scheduling commands. Multiple ACTION enumerations can be specified as a
> COMMA character (US-ASCII decimal 44) separated list of ACTION
> enumerated values. The text '*' is the same as specifying the
> enumerated values "CREATE,MODIFY,DELETE,READ,MOVE",."

Actually, this paragraph is not in line with the ABNF,
which specifies CREATE, MODIFY, DELETE, READ and * as
the only valid values for ACTION.

By looking at the CARID:REQUESTONLY example,

      BEGIN:VCAR
      CARID:REQUESTONLY
      GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=*
      ;OBJECT=METHOD;VALUE=REQUEST
      END:VCAR

it seems that the original intent was not to use the
ACTION rule part to restrict RIGHTS to submitted
VCALENDARs with a matching METHOD property, but rather
to restrict RIGHTS to the submitted VCALENDARs that
will require the specified ACTION to take place.

For instance, for a "move" command to succeed a user
should have the READ and DELETE ACTION granted for the
source calendar (or CS) and the CREATE ACTION granted
for the destination calendar (or CS).  We shouldn't
need a MOVE ACTION.

Furthermore, the MODIFY ACTION could probably be
eliminated, given that if you can READ and CREATE
you can MODIFY.

The relationship between the CAP commands (i.e.,
create, delete, modify, move, search and schedule)
and the CAP actions should be clarified.  Renaming
the ACTION CREATE to WRITE would probably help
reducing the confusion.


> So, if I grant you CREATE access you can create an entire VAGENDA heirarchy.
> The file system analogy would be like giving you the ability to create new
> subdirectories.
> 
> I don't think MOVE would provide you with the same ability.
> 
> At the moment I think MODIFY is underspecified in this case. I suspect most
> people would think that MODIFY would give you this ability as well. Is that
> what we want?
> 
> -----Original Message-----
> From: owner-ietf-calendar@xxxxxxxxxxxx
> [mailto:owner-ietf-calendar@xxxxxxxxxxxx]On Behalf Of Steve Mansour
> Sent: Tuesday, December 11, 2001 5:04 PM
> To: CalSched IETF
> Subject: VCAR question
> 
> Does "write" permission to a VAGENDA give you the right to move another
> VAGENDA into it?
> -Steve

As I said above, only if you have the READ and DELETE
ACTION granted for the source calendar (or CS) as well.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:bernard@xxxxxxxxxxx
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878