Subject: [Ietf-caldav] [Fwd: Last Call: draft-crispin-collation-unicasemap (i; unicode-casemap - Simple Unicode Collation Algorithm) to Proposed Standard]
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Thu, 24 May 2007 16:18:57 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

FYI

-------- Original Message --------
Subject: Last Call: draft-crispin-collation-unicasemap  (i;unicode-casemap - Simple Unicode Collation Algorithm) to  Proposed Standard
Date: Wed, 23 May 2007 12:08:16 -0400
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:

- 'i;unicode-casemap - Simple Unicode Collation Algorithm '
    <draft-crispin-collation-unicasemap-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-06-20. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-crispin-collation-unicasemap-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15508&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Content-return: prohibited
Date: Wed, 09 May 2007 15:21:58 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-caldav] comments on -03 schedule draft
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

> >=20
> >=20
> > "6.1.4. Response to a POST request"=20
> >=20
> (http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-03
> #section-6.1.4)
> >=20
> --------------------------------------------------------------
> --------------------------------------------------
> >=20
> > In the case of invite/response, given that the scheduling server =
is=20
> > not really doing any iTIP processing, it sounds weird to me that =
we=20
> > use the iTIP status to convey the result of something that more o=
r=20
> > less correspond to doing a PUT in each recipient's inbox.
> >=20
>=20
> We figured that the HTTP status code were not appropriate=20

Could you elaborate ?=20
The operation more or less comes down to doing a PUT in each recipien=
t'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=20
> values that made sense=20

Quite a few don't.=20

Some of them have a CalDAV precondition equivalent ((CALDAV:supported=
-calendar-data), (CALDAV:valid-calendar-data), (CALDAV:supported-cale=
ndar-component), (CALDAV:max-resource-size), CALDAV:min-date-time), C=
ALDAV:max-date-time), (CALDAV:max-instances), (CALDAV:max-attendees-p=
er-instance)).

> plus the fact that we can extended the=20
> 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> i=
n case of an iTip related failure.

=2E..

> >=20
> > Attachments:
> > -----------
> >=20
> > The CalDAV base spec has a section on=20
> >=20
> attachments(http://tools.ietf.org/html/rfc4791#section-8.5). While =
it=20
> > leaves the door opened to many contradicting=20
> implementations, at least=20
> > it is there.
> >=20
> > When doing scheduling, being able to send attachments along with =
an=20
> > invitation seems to me like a P1 functionality. Has this been=
=20
> > discussed already ?
> >=20
> > A possible solution would be to allow POST to be of type=20
> > multipart/mixed containing one and only one iTIP message=20
> (only in the=20
> > case of a REQUEST). If the server supports calendar-access on the=
=20
> > inbox/outbox, it would have to treat those as if they=20
> contained only=20
> > the iTIP message.
>=20
> Why not send the attachment inline in the iCalendar object?
>=20

I guess, for the same reasons that caused iCalendar to define both in=
line (BINARY) and external (URL) types of attachments, *external* bei=
ng the default. CalDAV itself describes some of the drawback of inlin=
e 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 resche=
duled 10 times, we have a lot of data being posted/fetched for no goo=
d reason.

Allowing multipart/mixed as I suggested earlier would not help much i=
n the first scenario since HTTP/WebDAV does not offer any mean to sel=
ectively GET a body part =E0 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 sti=
ll think it is a P1 feature for a group scheduling server !

Arnaud Q