[Ietf-caldav] comments on -03 schedule draft

[Arnaud Quillaud <[e-mail]>]

Hello,

Don't know if this is the right forum (should I send those to the authors instead ?) but here are some comments on the caldav schedule draft-03:


"4.1. Scheduling Collections" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-4.1):
---------------------------------------------------------------------------------------------------------

The new "6.3. Acting on incoming scheduling messages" section now mandate that clients should lock/process/delete/unlock. Hence we no longer keep an history  of received invitation and the following:

<<
It is useful for each participant in a scheduling transaction to
   maintain their own "history" of invitations sent and received during
   the process and after to keep track of what was done, and to properly
   handle updates to invitations as they may change over time.
>>

is no longer valid for inbox.

Also:

<<
Each calendar object resource has a WebDAV property that
   indicates whether the scheduling message has already been processed
   or not so that multiple clients do not repeat the processing actions
   already done.
>>

should be removed.




"5.2. Scheduling Outbox Collection" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-5.2)
---------------------------------------------------------------------------------------------------------------
It is mentioned that the server may keep a copy of the posted message. How is the client made aware of this ?

In the POST reply, it would be good to get back a header containing the uri of this newly created resource (if it is indeed created). Not sure whether it would be really correct to use the "Location" header but it would be something similar.




"5.3.1. CALDAV:calendar-free-busy-set Property" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-5.3.1):
-----------------------------------------------------------------------------------------------------------------------------

>From the example and the following sentense:
   "A server that allows users to create their own calendars SHOULD allow users to change their own property value"
 it sounds like only "local" calendars can be part of the set.

Nevertheless:
- The spec seems to imply that the scheduling and access servers might be totally separated services (e.g. see "A CalDAV scheduling server MAY also support the CalDAV calendar access feature").
- There is I think some value in a scheduling server that would be able to aggregate fb info from sources external to the calendar server (e.g. my family calendar hosted by an ISP + my work calendar).

Hence, it might be good to explicitely define some status code and precondition error for when trying to PROPPATCH this property.
For example HTTP 403 + the following <error>:
- (CALDAV:supported-freebusy-collection) one of the specified href does not correspond to a valid calendar collection (<!ELEMENT supported-freebusy-collection (DAV:href+)>)
- (CALDAV:no-freebusy-gateway) one of the specified href does not belong to this calendaring system and the server does not support freebusy aggregation from external sources (<!ELEMENT no-freebusy-gateway (DAV:href+)>)
- (CALDAV:collection-not-found) one of the specified href does not correspond to an existing collection (<!ELEMENT collection-not-found (DAV:href+)>)
- etc...




"6.1. POST Method" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-6.1)
----------------------------------------------------------------------------------------------

Don't we miss a (CALDAV:max-recipients) precondition (and its corresponding property on the calendar outbox) ?

Then shouldn't we add some of CalDAV base spec preconditions (or add a pointer to those).
I think that at least:
* (CALDAV:max-resource-size)
* (CALDAV:max-attendees-per-instance)

would belong there and maybe also:
* (CALDAV:min-date-time)
* (CALDAV:max-date-time)
* (CALDAV:max-instances)
although those last 3 might not apply in the case of a scheduling only server.




"6.1.1. Originator request header" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-6.1.1)
----------------------------------------------------------------------------------------------------------------
Two cases are described here:
1) originator = organizer
2) originator = another user acting on behalf of the organizer
Unless, I'm missing something, in a typical iTIP workflow, there are more cases where the originator contains the address of an ATTENDEE than cases of 1) or 2). Not listing this case makes you (ok, me) wonder whether you can really do a reply using POST.





"6.1.3. Recipient request header" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-6.1.3)
---------------------------------------------------------------------------------------------------------------

This sections explains quite well that the Recipient list might not always match the ATTENDEE list. This works well for invitations/responses but what does it mean for freebusy queries ?
Shouldn't we specify that the ATTENDEE list will be ignored and that the response might contain ATTENDEE not listed in the original iTIP request ?

It might also be worth adding that the Recipient header can contain the calendar address of a group (as it is done in the CALDAV:recipient property definition).

Finally I have the same comment than for 6.1.1 Originator: There are many cases where the Recipient is the Organizer. This is not listed and this might create some confusion.





"6.1.4. Response to a POST request" (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03#section-6.1.4)
----------------------------------------------------------------------------------------------------------------

In the case of invite/response, given that the scheduling server is not really doing any iTIP processing, it sounds weird to me that we use the iTIP status to convey the result of something that more or less correspond to doing a PUT in each recipient's inbox.

Can't we get away with a separate DAV:status for each recipient ?

That would solve another problem: in "6.1.5. Status Codes for use with the POST method" we list:

   502 (Bad Gateway) - The Recipient request header contained a URL
   which the server considers to be in another domain, which it cannot
   forward scheduling messages to.

   507 (Insufficient Storage) - The server did not have sufficient space
   to record the scheduling message in a recipient's scheduling inbox.

Would the whole POST fail just because one recipient causes an error ? And about 507, how do you differenciate a recipient lacking sufficient space in his inbox from the originator lacking space in his outbox ?

In other words, the given example could look like:

<C:schedule-response>
   <C:response>
     <C:recipient>mailto:[e-mail]</C:recipient>
     <D:status>HTTP/1.1 200 OK</D:status>
     <D:responsedescription>Delivered to recipient
     scheduling inbox</D:responsedescription>
   </C:response>
   <C:response>
     <C:recipient>mailto:[e-mail]</C:recipient>
     <C:request-status>HTTP/1.1 507 Insufficient Storage</C:request-status>
     <D:responsedescription></D:responsedescription>
	<error xmlns="DAV:">
        <quota-not-exceeded/>
      </error>
   </C:response>
</C:schedule-response>

Then what happen in the case where the recipient inbox is currently locked ? Should an HTTP 202 be returned ?






Attachments:
-----------

The CalDAV base spec has a section on attachments(http://tools.ietf.org/html/rfc4791#section-8.5). While it leaves the door opened to many contradicting implementations, at least it is there.

When doing scheduling, being able to send attachments along with an invitation seems to me like a P1 functionality. Has this been discussed already ?

A possible solution would be to allow POST to be of type multipart/mixed containing one and only one iTIP message (only in the case of a REQUEST). If the server supports calendar-access on the inbox/outbox, it would have to treat those as if they contained only the iTIP message.

If we think this is too much asking for some client/server, we could add a property to the inbox/outbox defintion to specify whether such contenttype is acceptable. 
A "415" "Unsupported Media Type" could be returned when the originator outbox or any of the recipient inbox does not support this format.


Arnaud Q