Re: [Ietf-caldav] comments on -03 schedule draft

[Bernard Desruisseaux <[e-mail]>]

Bonjour Arnaud,

Arnaud Quillaud wrote:
> 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:

Yes. Discussion of this Internet-Draft is taking place on this mailing list.

> 
> 
> "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.

We already fixed that in our yet-to-be-submitted draft -04.

> 
> 
> 
> 
> "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.
> 
> 

If you get a 201 with a Location response header than you can assume
the server kept a copy of the message.

> 
> 
> "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.

The intent here was the if a CalDAV server doesn't allow users to
create calendar collections with MKCALENDAR, then this requirement
probably doesn't make sense for such implementation.

> 
> 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).

Agreed.

> 
> 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...

We will give some thought to this.

> 
> 
> 
> 
> "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.

Right. I would also add:

CALDAV:supported-calendar-component-set
CALDAV:supported-calendar-data

> 
> 
> 
> 
> "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.
> 

We need to add text to clarify that.  Indeed, when an attendee is replying
to a scheduling message, the attendee is the originator.

> 
> 
> 
> 
> "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).

If you are the recipient of a free busy request *and* that you are
listed as one of the attendee *or* is a member of a group listed as
an attendee, then you should reply to the request, else I would think
that you should ignore the request.

> 
> 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.
> 

We figured that the HTTP status code were not appropriate here,
and that there were some iCalendar REQUEST-STATUS values that
made sense plus the fact that we can extended the set of
REQUEST-STATUS values if we need too.

> 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 ?

The whole POST should not fail.  We need to fix that, and define
new REQUEST-STATUS values if we need to.

> 
> 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 ?

I believe this is an implementation detail. A CalDAV server could accept an
incoming scheduling message even if the scheduling Inbox is locked.  The
incoming scheduling message would then only become visible in the
collection once it is unlocked.

> 
> 
> 
> 
> 
> 
> 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.

Why not send the attachment inline in the iCalendar object?

> 
> 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.

Thanks for the feedback!

Cheers,
Bernard

> 
> 
> Arnaud Q
> 
> _______________________________________________
> Ietf-caldav mailing list -- [e-mail]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav