Re: CAP Command Format Issues

[sman@xxxxxxxxxxxx (Steve Mansour)]

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?

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

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

begin:vcard 
n:Mansour;Steve
tel;fax:650.937.2103
tel;work:650.937.2378
x-mozilla-html:FALSE
org:Netscape
adr:version:2.1;;;;;;
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
fn:Steve Mansour
end:vcard