Subject: CAP Command Format Issues

From: [email-masked] (Steve Mansour)
Date: Wed, 17 Mar 1999 09:40:46 -0800

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:[email-masked]
     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

---

From: Alexander Taler <[email-masked]>
Date: Fri, 19 Mar 1999 13:39:49 -0500

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