Subject: Re: CAP Command Format Issues

From: Doug Royer <[email-masked]>
Date: Fri, 19 Mar 1999 16:58:26 -0800 (PST)

> Date: Fri, 19 Mar 1999 13:39:49 -0500
> From: Alexander Taler <[email-masked]>
> 
> 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:
> > ...

---

From: Alexander Taler <[email-masked]>
Date: Fri, 19 Mar 1999 20:12:30 -0500

> How would that help - don't you have the same problem as we

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.

---

From: [email-masked] (Steve Mansour)
Date: Fri, 19 Mar 1999 17:31:57 -0800

> How would that help - don't you have the same problem as we

well, yes, it is possible that you

   * check to see whether or not you have permission to do something,
   * get some results,
   * and the permissions change out from under you before you had a chance to
     take perform an operation.

Nevertheless, I still think a command to check and see whether or not you have
permission to do something is a valid thing to do. There are many cases on a UI
where you will elect to either show something or not, enable a button, etc.,
depending access rights.

Also note that the scenario where access rights are changed out from under you
is undoubtedly an edge case.

-Steve