Re: CAP Command Format Issues

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Fri, 19 Mar 1999 13:39:49 -0500
> From: Alexander Taler <alext@cst.ca>
> 
> This looks good to me.  It also gets rid of the problems of trying to
> associate the CREATE commands with the SENDDATA command and the issues
> that it was raising with tagging lines.

Same here - In fact, I like this more than the original proposal.

> Since the ability to check access permissions seems to be useful, how
> about another command, "PERMIT" which checks the various permissions?
> 
> It could go something like:
> 
> PERMIT CREATE VCALENDAR relcal8 cap://foo.nz/
> PERMIT READ VEVENT relcal9

How would that help - don't you have the same problem as we
just eliminated?

-Doug

> 
> Steve Mansour wrote:
> > 
> > Folks,
> > 
> > A couple of things got brought up during the second meeting as we went
> > through the general format of the commands in example CREATE-1:
> > 
> >   1. It was confusing to see multiple CREATE commands followed by a
> >      SENDDATA which actually did the create.
> >   2. The current syntax makes it possible to do an access check on
> >      CREATE but send down a METHOD:DELETE. That's confusing.
> >   3. There was concern about requiring a round trip to determine whether
> >      or not you have access to do something, when it is possible that
> >      access can change before you send the command that actually does
> >      it.  (While this point is valid, note that in addition to checking
> >      access, the response codes also indicated whether or not the server
> >      supports the operation. For example, the 3.1.4 error returned when
> >      an attempt was made to create a calendar on a remote calendar
> >      store.)
> > 
> > Another related issue occurred to me after the meeting:
> > 
> >    * The containers on which the CREATE command operates are specified
> >      in the CREATE command but NOT in the VCOMMAND. So, the VCOMMAND is
> >      not really self-contained in the examples presented.
> > 
> > Here are a couple of thoughts on how we could deal with these issues.
> > 
> > First, we put the containers into the VCOMMAND so that it really is
> > self-contained.  Second, once the command is self-contained, the first
> > two CREATE commands sent by the client are now completely optional. You
> > can still check to see if you have access rights --but now it's not
> > required. So, if you do not want to check access rights up front,
> > example CREATE-1 reduces to:
> > ...