Re: CAP: moving to closure on transport / application layers

[Bernard Desruisseaux <bernard@xxxxxxxxxxx>]

Steve Mansour wrote:
> 
> Does anyone have issues with this?  Can we close this issue and move
> on?

I have no problem about removing XML from CAP.  On the other hand,
we need to look at the issues that need to be addressed as a result
of this change.  Don't worry, none of the following issues need XML
to be resolved!

1- The version of iCalendar supported by the CS will end up
   being specified in an iCalendar object (chicken'n'egg
   problem).  Shall we specify that the capabilities MUST
   always be returned in an iCalendar 2.0 object?  For
   instance, a CS supporting iCalendar 2.1 would returned :

      BEGIN:VCALENDAR
      VERSION:2.0          <-- Always 2.0
      BEGIN:VCAPABILITY
      VERSION:2.1          <-- Version of iCalendar
      ...                      supported by the CS
      END:VCAPABILITY
      END:VCALENDAR

2- The MODIFY command requires ordering of components (i.e.,
   OLD-VALUES component needs to appear before the NEW-VALUES
   component in the iCalendar object).  The iCalendar syntax
   usually doesn't impose ordering of components.  Are there
   iCalendar parsers known not to preserve the ordering of
   components in iCalendar objects?  Should the old and new
   values be identified explicitly by some other mean than
   their ordering?  Is that an issue?

3- According to RFC 2445, besides CALSCALE, METHOD, PRODID and
   VERSION, only "x-prop" properties can appear in the body of
   iCalendar components.  Do we want to break this syntax and
   allow TARGET, CMDID, LATENCY, etc. in iCalendar components?
   We used to have a VCOMMAND components for these types of
   properties.  Do we need to add it back?  What about iTIP?
   iTIP doesn't allow TARGET, etc. in the iCalendar object
   either.

4- We need to agree on the mapping of the existent DTD into
   the iCalendar syntax.  That is, we will need to define new
   components (e.g., VCAPABILITY, VGENERATE-UID) as well as new
   properties and parameters (e.g., UPN property or parameter
   for the IDENTIFY command, NUMBER-OF-UID property or parameter
   for the GENERATE-UID command).  We will also have to define
   the format of the response returned for the commands, perhaps
   we will need a VRESULT component?

5- Further to this change, I think it will become even more
   important to separate the method/command specified in the
   iCalendar objects from their actual state.  Perhaps, we
   will want/need the ability to create objects in a specific
   initial state eventually (e.g., a PDA willing to sync its
   meeting trash can on the CS (i.e., create meeting in the
   state DELETED)).

   We might also want to consider Doug's proposition of using
   a "CMD" property to hold the name of the command instead
   of using METHOD.  It might be worthwhile to use METHOD
   only in iTIP messages.  Doug's proposal can be found at
   http://www.imc.org/ietf-calendar/mail-archive/msg04741.html

Cheers,
Bernard
-- 
Bernard Desruisseaux                    mailto:bernard@xxxxxxxxxxx
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878