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

[Arnaud Quillaud <[e-mail]>]

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

Could you elaborate ? 
The operation more or less comes down to doing a PUT in each recipient's inbox. This type of operation is likely to return an HTTP Status (e.g. 507 User over quota).
It has not much to do with iTIP at that point.

> here, and that there were some iCalendar REQUEST-STATUS 
> values that made sense 

Quite a few don't. 

Some of them have a CalDAV precondition equivalent ((CALDAV:supported-calendar-data), (CALDAV:valid-calendar-data), (CALDAV:supported-calendar-component), (CALDAV:max-resource-size), CALDAV:min-date-time), CALDAV:max-date-time), (CALDAV:max-instances), (CALDAV:max-attendees-per-instance)).


> plus the fact that we can extended the 
> set of REQUEST-STATUS values if we need too.

The same can be said for WebDAV <error> subelements. Can't we define new pre/post conditions ?

And actually, the <C:request-status> could be wrapped in an <error> in case of an iTip related failure.

...

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

I guess, for the same reasons that caused iCalendar to define both inline (BINARY) and external (URL) types of attachments, *external* being the default. CalDAV itself describes some of the drawback of inline attachments (http://tools.ietf.org/html/rfc4791#section-8.5.1).

Some real life scenario:
* as an invitee, I don't want to have to download a 20Mb invitation, just to discover that I'm not going to attend the meeting.
* if a invitation to 30 people containing a 20Mb attachment is rescheduled 10 times, we have a lot of data being posted/fetched for no good reason.

Allowing multipart/mixed as I suggested earlier would not help much in the first scenario since HTTP/WebDAV does not offer any mean to selectively GET a body part à la IMAP. It would not help at all in the second...


I now start to feel why the subject has not been covered... but I still think it is a P1 feature for a group scheduling server !

Arnaud Q