CAP Command Format Issues

[sman@xxxxxxxxxxxx (Steve Mansour)]

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
begin:vcard 
adr;dom:;;;Mountain View;CA;94043;
n:Mansour;Steve
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-cpt:;0
fn:Steve Mansour
end:vcard