Re: CAP Command Format Issues

[Alexander Taler <alext@xxxxxx>]

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.

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

Clearly this couldn't cover all the subtelties of access rights, but
could give you a general idea of what can and can't be done.

Alex

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:
> 
>      C: 10 SENDDATA
>      S: 10 2.0.1
>      C: CONTENT-TYPE:
>      text/calendar;method=create;component=VCOMMAND
>      C: Content-Transfer-Encoding:7bit
>      C:
>      C: BEGIN:VCALENDAR
>      C: VERSION:2.1
>      C: BEGIN:VCOMMAND
>      C: METHOD:CREATE VCALENDAR cap://cal.example.com/ relcal4
>      ://bobo.ex.com/ relcal5 cap://cal.example.com/relcal8 relcal9
>      C: BEGIN:VCALENDAR
>      C: RELCALUID:relcalz
>      C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill’s Soccer Team
>      C: OWNER:capcar:bill
>      C: OWNER:capcar:mary
>      C: CALMASTER:mailto:bill@example.com
>      C: PREFERRED-TZID:US_PST
>      C: BEGIN:VCAR
>      C: CARID:12345
>      C: GRANT;CN=”Bill
>      Jones”:principal=capcar:bill;action=ALL;object=all
>      C: GRANT;cn=”Mary
>      Jones”:principal=capcar:mary;action=read;object=all
>      C: END:VCAR
>      C: END:VCOMMAND
>      C: END:VCALENDAR
>      C: .
>      S: 10 6.0 cap://cal.example.com/
>      S: 10 2.0 cap://cal.example.com/relcal4
>      cap://cal.example.com/relcalz
>      S: 10 3.1.4 cap://bobo.ex.com/
>      S: 10 6.2 cap://cal.example.com/relcal5
>      S: 10 3.1.5 cap://cal.example.com/relcal8
>      S: 10 7.0 cap://cal.example.com/relcal9
> 
> The METHOD property was moved into the VCOMMAND component. It seems to
> make sense, but it is a little different from ITIP and ICAL as they
> stand today (so I expect there will be some push back on this). Also,
> the value of the METHOD property now describes the command and
> containers to which the command applies. Again, this seems to make sense
> in the context of a VCOMMAND, but it's a change to the simple METHOD
> values we currently have.
> 
> Comments?
> 
> -Steve