Re: CAP Command Format Issues

[Alexander Taler <alext@xxxxxx>]

Doug Royer wrote:
> 
> > 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
> 

This command would not be linked to the SENDDATA command.  It only 
checks permissions, with no additional commitments. We can use 
it to check permissions if we wish, prior to sending a lot of data
down the wire.  When we do send the data the server only uses the 
information specified in the METHOD property.

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