Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F4B17F6F4 for ; Thu, 24 May 2007 13:20:40 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C73214220E for ; Thu, 24 May 2007 13:19:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-50 required=4 tests=[AWL=0.777, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D53jf6faTqrM for ; Thu, 24 May 2007 13:19:43 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B7B3414220C for ; Thu, 24 May 2007 13:19:43 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l4OKJfUr008367 for ; Thu, 24 May 2007 14:19:41 -0600 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l4OJcG9p022853 for ; Thu, 24 May 2007 14:19:37 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 2728527391180037946; Thu, 24 May 2007 13:19:06 -0700 Message-ID: <4655F331.6090608@oracle.com> Date: Thu, 24 May 2007 16:18:57 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= Subject: [Ietf-caldav] [Fwd: Last Call: draft-crispin-collation-unicasemap (i; unicode-casemap - Simple Unicode Collation Algorithm) to Proposed Standard] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2007 20:20:40 -0000 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 Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'i;unicode-casemap - Simple Unicode Collation Algorithm ' 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 ietf@ietf.org mailing lists by 2007-06-20. Exceptionally, comments may be sent to iesg@ietf.org 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 IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 503A67F7DE for ; Wed, 9 May 2007 06:22:39 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 18F0B1422EF for ; Wed, 9 May 2007 06:21:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-50 required=4 tests=[AWL=1.515, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HN4c6BH9ZHE for ; Wed, 9 May 2007 06:21:41 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 418A01422EE for ; Wed, 9 May 2007 06:21:41 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l49DLdVT019504 for ; Wed, 9 May 2007 13:21:40 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHR00801ZKWSO00@d1-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-caldav@osafoundation.org; Wed, 09 May 2007 14:21:39 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.116.246]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHR007G5ZS2P6C6@d1-emea-09.sun.com>; Wed, 09 May 2007 14:21:39 +0100 (BST) Content-return: prohibited Date: Wed, 09 May 2007 15:21:58 +0200 From: Arnaud Quillaud Subject: RE : [Ietf-caldav] comments on -03 schedule draft In-reply-to: <46291080.5050108@oracle.com> Sender: Arnaud.Quillaud@Sun.COM To: Bernard Desruisseaux Message-id: <0JHR007G7ZS2P6C6@d1-emea-09.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.310.1 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2007 13:22:39 -0000 > >=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 subelements. Can't we define = new pre/post conditions ? And actually, the could be wrapped in an 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