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 36AE77F59C for ; Wed, 28 Dec 2005 08:17:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 269A7142290 for ; Wed, 28 Dec 2005 08:17:19 -0800 (PST) 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 21158-06 for ; Wed, 28 Dec 2005 08:17:18 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B3A4914228E for ; Wed, 28 Dec 2005 08:17:18 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBSGHHcI025181 for ; Wed, 28 Dec 2005 09:17:17 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBSGHGYw001962 for ; Wed, 28 Dec 2005 09:17:16 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-98-51.vpn.oracle.com [141.144.98.51]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBSGH3lP001886; Wed, 28 Dec 2005 09:17:05 -0700 Message-ID: <43B2BA83.4020302@oracle.com> Date: Wed, 28 Dec 2005 11:17:07 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Content-Type: multipart/mixed; boundary="------------040708030001040708020307" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-09.txt] 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, 28 Dec 2005 16:17:19 -0000 This is a multi-part message in MIME format. --------------040708030001040708020307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-09.txt Date: Wed, 28 Dec 2005 10:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-09.txt Pages : 75 Date : 2005-12-28 This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-caldav-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-caldav-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040708030001040708020307 Content-Type: Message/External-body; name="draft-dusseault-caldav-09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-09.txt" Content-Type: text/plain Content-ID: <2005-12-28094937.I-D@ietf.org> --------------040708030001040708020307 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail-1.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040708030001040708020307-- 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 527827F535 for ; Sun, 25 Dec 2005 10:16:29 -0800 (PST) Received: from [192.168.1.101] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0817B142294; Sun, 25 Dec 2005 10:17:49 -0800 (PST) In-Reply-To: <43AD1F95.2090703@gmx.de> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> <43AD1F95.2090703@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <29783137fcee7b8bc7e03a4be50a13ba@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Sun, 25 Dec 2005 09:15:07 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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: Sun, 25 Dec 2005 18:16:29 -0000 That does suggest a way for Apache to avoid the within-second overwrite risk: to disallow PUT operations while there's a weak ETag. That would be consistent with HTTP as far as I can see. It would still, however, theoretically cause clients to reload the resource content when the server switches to the strong ETag. lisa On Dec 24, 2005, at 2:14 AM, Julian Reschke wrote: > Helge Hess wrote: >> On 24. Dez 2005, at 01:31 Uhr, Mike Shaver wrote: >>> On 12/22/05, Julian Reschke wrote: >>>> Apache simply has decided that multiple updates within one second >>>> *are* >>>> semantically equivalent. >>> >>> Do you mean to indicate that such a decision on the part of Apache is >>> reasonable, given the requirements of the HTTP specification? It >>> certainly doesn't seem that way to me, but I am probably the biggest >>> HTTP dullard on this list, so I'm happy to learn. >> Maybe I'm wrong but if I understood Julian correctly Apache will >> ensure that there will be only one PUT in the timeframe of 1s. If the >> server ensures that, a timestamp with 1s granularity should be enough >> for an etag? > > No, that's not what I intended to say. As far as I know, it currently > allows multiple PUTs. > > Best regards, Julian > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 8450A7F65B for ; Sat, 24 Dec 2005 03:17:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 628B21422D8 for ; Sat, 24 Dec 2005 03:18:53 -0800 (PST) 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 27638-02 for ; Sat, 24 Dec 2005 03:18:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 9736D1422CD for ; Sat, 24 Dec 2005 03:18:52 -0800 (PST) Received: (qmail invoked by alias); 24 Dec 2005 10:16:18 -0000 Received: from p508F8BC8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.139.200] by mail.gmx.net (mp023) with SMTP; 24 Dec 2005 11:16:18 +0100 X-Authenticated: #1915285 Message-ID: <43AD1F95.2090703@gmx.de> Date: Sat, 24 Dec 2005 11:14:45 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> In-Reply-To: <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Sat, 24 Dec 2005 11:17:26 -0000 Helge Hess wrote: > On 24. Dez 2005, at 01:31 Uhr, Mike Shaver wrote: >> On 12/22/05, Julian Reschke wrote: >>> Apache simply has decided that multiple updates within one second *are* >>> semantically equivalent. >> >> Do you mean to indicate that such a decision on the part of Apache is >> reasonable, given the requirements of the HTTP specification? It >> certainly doesn't seem that way to me, but I am probably the biggest >> HTTP dullard on this list, so I'm happy to learn. > > Maybe I'm wrong but if I understood Julian correctly Apache will ensure > that there will be only one PUT in the timeframe of 1s. If the server > ensures that, a timestamp with 1s granularity should be enough for an etag? No, that's not what I intended to say. As far as I know, it currently allows multiple PUTs. Best regards, Julian 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 494F87F639 for ; Sat, 24 Dec 2005 03:14:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 281DA142318 for ; Sat, 24 Dec 2005 03:16:26 -0800 (PST) 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 28525-01 for ; Sat, 24 Dec 2005 03:16:26 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 757AD1422D8 for ; Sat, 24 Dec 2005 03:16:25 -0800 (PST) Received: (qmail invoked by alias); 24 Dec 2005 10:13:51 -0000 Received: from p508F8BC8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.139.200] by mail.gmx.net (mp029) with SMTP; 24 Dec 2005 11:13:51 +0100 X-Authenticated: #1915285 Message-ID: <43AD1F01.7060904@gmx.de> Date: Sat, 24 Dec 2005 11:12:17 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Grant Baillie Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Sat, 24 Dec 2005 11:14:59 -0000 Grant Baillie wrote: > On Dec 23, 2005, at 16:31, Mike Shaver wrote: > >> On 12/22/05, Julian Reschke wrote: >>> Apache simply has decided that multiple updates within one second *are* >>> semantically equivalent. >> >> Do you mean to indicate that such a decision on the part of Apache is >> reasonable, given the requirements of the HTTP specification? It >> certainly doesn't seem that way to me, but I am probably the biggest >> HTTP dullard on this list, so I'm happy to learn. > > Actually, I think I'm the biggest HTTP dullard on the list :). Apache's > behaviour sure seems to be stretching the meaning of "semantically > equivalent": I would have thought this would relate to the semantic > equivalence of the content, not the semantics of the resource's creation > on the server. > > A related behaviour is that I've seen mod_dav servers reject (412) PUT > requests with If-None-Match: *, even when the resource doesn't exist on > the server. I suppose that's because they can't guarantee that someone > else won't come and clobber that resource in the next second(?). I don't think it's intentional, so I entered a bug report (). Best regards, Julian 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 A9B477F660 for ; Sat, 24 Dec 2005 01:41:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E57C142317 for ; Sat, 24 Dec 2005 01:43:04 -0800 (PST) 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 15729-08 for ; Sat, 24 Dec 2005 01:43:04 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id CCBD6142313 for ; Sat, 24 Dec 2005 01:43:03 -0800 (PST) Received: (qmail invoked by alias); 24 Dec 2005 08:40:28 -0000 Received: from p508F8BC8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.139.200] by mail.gmx.net (mp027) with SMTP; 24 Dec 2005 09:40:28 +0100 X-Authenticated: #1915285 Message-ID: <43AD0922.9040405@gmx.de> Date: Sat, 24 Dec 2005 09:38:58 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mike Shaver Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Sat, 24 Dec 2005 09:41:37 -0000 Mike Shaver wrote: > On 12/22/05, Julian Reschke wrote: >> Apache simply has decided that multiple updates within one second *are* >> semantically equivalent. > > Do you mean to indicate that such a decision on the part of Apache is > reasonable, given the requirements of the HTTP specification? It > certainly doesn't seem that way to me, but I am probably the biggest > HTTP dullard on this list, so I'm happy to learn. To the letter of the spec? Probably no. Satisfying the requirements of generic clients? Yes, I'd say. 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 876007F572 for ; Fri, 23 Dec 2005 18:16:53 -0800 (PST) Received: from [172.16.1.2] (adsl-69-107-123-191.dsl.pltn13.pacbell.net [69.107.123.191]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AB25E142313 for ; Fri, 23 Dec 2005 18:18:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Grant Baillie Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Fri, 23 Dec 2005 17:15:46 -0800 To: ietf-caldav@osafoundation.org X-Mailer: Apple Mail (2.746.2) 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: Sat, 24 Dec 2005 02:16:53 -0000 On Dec 23, 2005, at 16:31, Mike Shaver wrote: > On 12/22/05, Julian Reschke wrote: >> Apache simply has decided that multiple updates within one second >> *are* >> semantically equivalent. > > Do you mean to indicate that such a decision on the part of Apache is > reasonable, given the requirements of the HTTP specification? It > certainly doesn't seem that way to me, but I am probably the biggest > HTTP dullard on this list, so I'm happy to learn. Actually, I think I'm the biggest HTTP dullard on the list :). Apache's behaviour sure seems to be stretching the meaning of "semantically equivalent": I would have thought this would relate to the semantic equivalence of the content, not the semantics of the resource's creation on the server. A related behaviour is that I've seen mod_dav servers reject (412) PUT requests with If-None-Match: *, even when the resource doesn't exist on the server. I suppose that's because they can't guarantee that someone else won't come and clobber that resource in the next second(?). --Grant Grant Baillie Open Source Applications Foundation http://www.osafoundation.org 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 96A897F6EB for ; Fri, 23 Dec 2005 17:41:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C18C6142315 for ; Fri, 23 Dec 2005 17:43:00 -0800 (PST) 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 16438-07 for ; Fri, 23 Dec 2005 17:43:00 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 67923142313 for ; Fri, 23 Dec 2005 17:43:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0E9FA35DEA8 for ; Sat, 24 Dec 2005 01:30:35 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 6DAA135E006 for ; Sat, 24 Dec 2005 01:30:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Sat, 24 Dec 2005 01:40:24 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Sat, 24 Dec 2005 01:41:33 -0000 On 24. Dez 2005, at 01:31 Uhr, Mike Shaver wrote: > On 12/22/05, Julian Reschke wrote: >> Apache simply has decided that multiple updates within one second >> *are* >> semantically equivalent. > > Do you mean to indicate that such a decision on the part of Apache is > reasonable, given the requirements of the HTTP specification? It > certainly doesn't seem that way to me, but I am probably the biggest > HTTP dullard on this list, so I'm happy to learn. Maybe I'm wrong but if I understood Julian correctly Apache will ensure that there will be only one PUT in the timeframe of 1s. If the server ensures that, a timestamp with 1s granularity should be enough for an etag? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 F3B7E7F662 for ; Fri, 23 Dec 2005 17:32:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 376B5142318 for ; Fri, 23 Dec 2005 17:34:15 -0800 (PST) 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 16311-01 for ; Fri, 23 Dec 2005 17:34:15 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by laweleka.osafoundation.org (Postfix) with ESMTP id D01D3142315 for ; Fri, 23 Dec 2005 17:34:14 -0800 (PST) Received: by zproxy.gmail.com with SMTP id i11so701542nzh for ; Fri, 23 Dec 2005 16:31:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dFRdq+PGnHL8YG5FcBUT4u1uf7M128eEyjNVeCkDau2bqjkxxyYd/nu1T+bSnKkKDzSFyXiYXQfW7wcXiIVsiGNjwYt1NlmjXynGunjkxwuJl16l4evZX+hIbw6mL7wPZE6vSOlw5f4SHZJstox0hHQHgSG1LlyeVjjyc9uDWP8= Received: by 10.65.83.3 with SMTP id k3mr1071439qbl; Fri, 23 Dec 2005 16:31:40 -0800 (PST) Received: by 10.65.135.14 with HTTP; Fri, 23 Dec 2005 16:31:40 -0800 (PST) Message-ID: Date: Fri, 23 Dec 2005 19:31:40 -0500 From: Mike Shaver To: Julian Reschke Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis In-Reply-To: <43AAF5F6.4080507@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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: Sat, 24 Dec 2005 01:32:48 -0000 On 12/22/05, Julian Reschke wrote: > Apache simply has decided that multiple updates within one second *are* > semantically equivalent. Do you mean to indicate that such a decision on the part of Apache is reasonable, given the requirements of the HTTP specification? It certainly doesn't seem that way to me, but I am probably the biggest HTTP dullard on this list, so I'm happy to learn. Mike 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 298757F63C for ; Fri, 23 Dec 2005 13:34:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8615B1422B9 for ; Fri, 23 Dec 2005 13:35:45 -0800 (PST) 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 08918-01 for ; Fri, 23 Dec 2005 13:35:45 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 282BE1422BC for ; Fri, 23 Dec 2005 13:35:45 -0800 (PST) Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id jBNL17UV014903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Dec 2005 16:01:10 -0500 Date: Fri, 23 Dec 2005 15:32:58 -0500 From: Cyrus Daboo To: "Kervin L. Pierre" , Bernard Desruisseaux , CalDAV DevList Subject: Re: [Ietf-caldav] draft-dusseault-caldav-09.txt Message-ID: <81D2F3C836485B50EEFAAC22@ninevah.local> In-Reply-To: <43AC5B3D.2040102@adevsoft.com> References: <43AC1D5B.1000901@oracle.com> <43AC5B3D.2040102@adevsoft.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Fri, 23 Dec 2005 21:34:18 -0000 Hi Kervin, --On December 23, 2005 3:17:01 PM -0500 "Kervin L. Pierre" wrote: > How does a client retrieve all components of > a specified type from a collection, regardless > of time? > > That is, a substitute to... > > > > Just use: The mere presence of that now implies the previous 'is-defined' behaviour. -- Cyrus Daboo 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 E8E077F726 for ; Fri, 23 Dec 2005 13:25:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 532381422BC for ; Fri, 23 Dec 2005 13:27:02 -0800 (PST) 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 25708-08 for ; Fri, 23 Dec 2005 13:27:02 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 108461422B8 for ; Fri, 23 Dec 2005 13:27:02 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNKOPUg008762; Fri, 23 Dec 2005 14:24:25 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBNKOOMs013055; Fri, 23 Dec 2005 13:24:25 -0700 Received: from [144.23.219.65] (dhcp-ca-montreal-144-23-219-65.ca.oracle.com [144.23.219.65]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNKODSt012981 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 13:24:14 -0700 Message-ID: <43AC5CE6.3050209@oracle.com> Date: Fri, 23 Dec 2005 15:24:06 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] draft-dusseault-caldav-09.txt References: <43AC1D5B.1000901@oracle.com> <43AC5B3D.2040102@adevsoft.com> In-Reply-To: <43AC5B3D.2040102@adevsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Fri, 23 Dec 2005 21:25:35 -0000 See 7.6.8. Example: Retrieval of events only. Cheers, Bernard Kervin L. Pierre wrote: > Bernard Desruisseaux wrote: > >> >> b. Removed the CALDAV:is-defined XML element. >> > > How does a client retrieve all components of > a specified type from a collection, regardless > of time? > > That is, a substitute to... > > > > > > Regards, > Kervin 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 1FDD97F6D6 for ; Fri, 23 Dec 2005 13:17:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E9A61422AA for ; Fri, 23 Dec 2005 13:19:01 -0800 (PST) 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 12363-09 for ; Fri, 23 Dec 2005 13:19:01 -0800 (PST) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by laweleka.osafoundation.org (Postfix) with SMTP id 13E7A1422A9 for ; Fri, 23 Dec 2005 13:19:00 -0800 (PST) Received: (qmail 75790 invoked from network); 23 Dec 2005 20:16:26 -0000 Received: from unknown (HELO ?10.55.10.51?) (kervin@adevsoft.com@24.227.116.130 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 23 Dec 2005 20:16:26 -0000 Message-ID: <43AC5B3D.2040102@adevsoft.com> Date: Fri, 23 Dec 2005 15:17:01 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux , CalDAV DevList Subject: Re: [Ietf-caldav] draft-dusseault-caldav-09.txt References: <43AC1D5B.1000901@oracle.com> In-Reply-To: <43AC1D5B.1000901@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Fri, 23 Dec 2005 21:17:34 -0000 Bernard Desruisseaux wrote: > > b. Removed the CALDAV:is-defined XML element. > How does a client retrieve all components of a specified type from a collection, regardless of time? That is, a substitute to... Regards, Kervin 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 2B9117F728 for ; Fri, 23 Dec 2005 08:54:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B239014230F for ; Fri, 23 Dec 2005 08:55:43 -0800 (PST) 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 01689-05 for ; Fri, 23 Dec 2005 08:55:43 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D64514230A for ; Fri, 23 Dec 2005 08:55:43 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBNFr7P4005866 for ; Fri, 23 Dec 2005 08:53:08 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBNFr7vG014203 for ; Fri, 23 Dec 2005 08:53:07 -0700 Received: from [144.23.219.65] (dhcp-ca-montreal-144-23-219-65.ca.oracle.com [144.23.219.65]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBNFr56j014194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 08:53:06 -0700 Message-ID: <43AC1D5B.1000901@oracle.com> Date: Fri, 23 Dec 2005 10:52:59 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] draft-dusseault-caldav-09.txt 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: Fri, 23 Dec 2005 16:54:16 -0000 We just submitted CalDAV draft -09 to the IETF this morning. It is already available at the following URL: http://ietf.webdav.org/caldav/draft-dusseault-caldav-09.txt The draft is not yet ready for our informal last call. Few issues needs to be addressed first, and we want to add more examples to the draft. Please review the draft and send us feedback/questions/comments. Thanks, Bernard C.1. Changes in -09 a. Numerous editorial changes. b. Removed the CALDAV:is-defined XML element. c. Removed section on privilege aggregation. d. Renamed the CALDAV:expand-recurrence-set XML element to CALDAV: expand and clarified the server behavior. e. Renamed the CALDAV:calendar-component-restriction-set XML element to CALDAV:supported-calendar-component-set. f. Renamed the CALDAV:calendar-restrictions XML element to CALDAV: supported-calendar-data. g. Renamed some preconditions as "success conditions" instead of "failure causes". For instance, the precondition CALDAV: calendar-collection-location-bad has been renamed to CALDAV: calendar-collection-location-ok. h. Reordered some sections. i. Clarified the definition of CALDAV:time-range to specify that a repeating VALARM component is said to intersect a given time range if at least one of its trigger intersect the time range. j. Clarified that calendar object resources stored in calendar collections MUST NOT specify the iCalendar METHOD property. k. Clarified that CALDAV:calendar-data XML element is not a WebDAV property even though it is specified in the DAV:prop XML element in both calendaring REPORT requests and responses. l. Clarified CALDAV:limit-recurrence-set with respect to the RANGE parameter on the RECURRENCE-ID property. m. Changed the CALDAV:free-busy-query XML element to contain exactly one CALDAV:time-range XML element. n. Changed many ELEMENT and ATTLIST declarations to comply with DTD syntax. o. Changed XML element CALDAV:calendar-query to allow new XML element CALDAV:timezone. p. Changed the XML elements CALDAV:time-range, CALDAV:expand and CALDAV:limit-recurrence-set to only allow DATE-TIME with UTC time values for the "start" and "end" attributes. q. Changed description of CALDAV:limit-recurrence-set to specify that re-scheduled "overridden" recurrence instances whose original scheduled time used to overlap the time range specified by the "start" and "end" attribute should always be returned in a REPORT response. r. Changed the description of the value of CALDAV:calendar-data XML element to specify that the CR character (US-ASCII decimal 13) MAY be omitted in the iCalendar object specified in this XML element. s. Added specific requirements for entity tags support. t. Added more preconditions. u. Added further guidelines about finding calendars. v. Added XML element CALDAV:limit-freebusy-set to limit the set of FREEBUSY property values returned in VFREEBUSY components. w. Added property CALDAV:calendar-timezone on calendar collections. x. Added XML element CALDAV:timezone to override the CALDAV: calendar-timezone property for a given CALDAV:calendar-query REPORT request. y. Added text on the conversion of "floating date" and "floating time" values to date with UTC time values. z. Completed internationalization considerations section. aa. Completed security considerations section. 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 6490D7F71F for ; Thu, 22 Dec 2005 11:55:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 854BD1422D8 for ; Thu, 22 Dec 2005 11:57:16 -0800 (PST) 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 00948-06 for ; Thu, 22 Dec 2005 11:57:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id AC1DD1422CD for ; Thu, 22 Dec 2005 11:57:15 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2005 18:54:39 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp010) with SMTP; 22 Dec 2005 19:54:39 +0100 X-Authenticated: #1915285 Message-ID: <43AAF5F6.4080507@gmx.de> Date: Thu, 22 Dec 2005 19:52:38 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> In-Reply-To: <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 19:55:48 -0000 Lisa Dusseault wrote: > > On Dec 22, 2005, at 7:51 AM, Mike Shaver wrote: > >> On 12/21/05, Helge Hess wrote: >> >>> Usually the etag will just be a content revision number (most likely >>> matching the revision field of iCalendar, SEQUENCE) and is rather >>> cheap to deliver. >>> I'm not sure why you suggest that the etag must be computed, I know >>> of no server which does this (I know that Apache can be optionally >>> configured to compute a hash, but no one does it in RL ...). >> >> Is support for weak entity tags widespread? I certainly believe from >> my reading of the HTTP RFC >> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11) that a >> strong entity tag has to represent the specific set of octets, not >> just semantic equivalence. > > To my knowledge, the only server that uses weak ETags is > Apache/mod_dav. It's not a good example of how to use weak etags, Incorrect. IIS 5.1 shows similar behavior (you get the weak ETag not upon PUT, but on a subsequent GET). > because it doesn't do any semantic equivalence checking before deciding > whether to create a new ETag. Instead, it assigns a weak ETag based on > the timestamp when an entity is stored. Since the timestamp doesn't > always have enough granularity to be able to mark two changes within a > short time period, when the short time period expires the server > converts the weak ETag to a strong Etag (simply by stripping the w/). Apache simply has decided that multiple updates within one second *are* semantically equivalent. They also ensure that after that time window has elapsed any HTTP client that uses ETags will get the "final" state of the content. At least from an HTTP caching p.o.v. this is completely ok. > In theory, a client reading HTTP would have to treat this strong ETag as > representing a new entity -- the spec is very clear on clients not > trying to interpret ETags -- and always do a GET as soon as it noticed > the "new" ETag. In practice, a few clients treat the Apache server > specially and have custom logic for this case. I don't understand this part. An Etag is an opaque string, but what has this to do with server implementations, or whether the ETag is strong or not? > Thus this practice fails in two ways: > - There are many times when the client is forced to GET the content > again even when it hasn't changed > - There are some times when the content changes twice before the weak > ETag is converted to the strong ETag and the client doesn't catch the > second change So why does this matter? If the client stops polling within that window, it will have one of many versions sent in that time window. If it continues polling, it will eventually get the final state. > ... Best regards, Julian 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 B4CBA7F71E for ; Thu, 22 Dec 2005 11:44:34 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B0A641422BC; Thu, 22 Dec 2005 11:46:02 -0800 (PST) In-Reply-To: References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 10:43:23 -0800 To: Mike Shaver X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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, 22 Dec 2005 19:44:34 -0000 On Dec 22, 2005, at 7:51 AM, Mike Shaver wrote: > On 12/21/05, Helge Hess wrote: > >> Usually the etag will just be a content revision number (most likely >> matching the revision field of iCalendar, SEQUENCE) and is rather >> cheap to deliver. >> I'm not sure why you suggest that the etag must be computed, I know >> of no server which does this (I know that Apache can be optionally >> configured to compute a hash, but no one does it in RL ...). > > Is support for weak entity tags widespread? I certainly believe from > my reading of the HTTP RFC > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11) that a > strong entity tag has to represent the specific set of octets, not > just semantic equivalence. To my knowledge, the only server that uses weak ETags is Apache/mod_dav. It's not a good example of how to use weak etags, because it doesn't do any semantic equivalence checking before deciding whether to create a new ETag. Instead, it assigns a weak ETag based on the timestamp when an entity is stored. Since the timestamp doesn't always have enough granularity to be able to mark two changes within a short time period, when the short time period expires the server converts the weak ETag to a strong Etag (simply by stripping the w/). In theory, a client reading HTTP would have to treat this strong ETag as representing a new entity -- the spec is very clear on clients not trying to interpret ETags -- and always do a GET as soon as it noticed the "new" ETag. In practice, a few clients treat the Apache server specially and have custom logic for this case. Thus this practice fails in two ways: - There are many times when the client is forced to GET the content again even when it hasn't changed - There are some times when the content changes twice before the weak ETag is converted to the strong ETag and the client doesn't catch the second change We've had some discussions on the WebDAV list lately about how one might fix Apache/mod_dav without creating unduly slow performance on bulk upload operations. It's generally thought that such a fix would be a good thing if somebody can think of the right way to do it. > > I am not actually confident that we can give implementors a meaningful > definition of "semantic equivalence", personally. I did take a stab at this for calendar events, based on scrutinizing iCalendar: Weak ETags MAY be used by servers when the bytes on the wire may vary without any change to the semantics of the event. Some examples of variations that do not require a change of weak ETag (but would require a change in a strong ETag). For CalDAV component resource, semantic equivalence is obtained if only the following things change: - The ordering of the properties or sub-components in a component (section 4.1.1 of RFC2445) - The ordering of values in a list of values (section 4.5 of RFC2445) - Case changes in property names, parameter names, and enumerated parameter values (section 4.5 of RFC2445) - Changes in line folding (section 4.1) that do not change the value The following changes MUST result in a change of ETag, whether strong or weak: - Addition or removal of any property, including a custom property - Addition or removal of any value or parameter, including a custom parameter - Change in any property value or parameter value - Change in any reference URL (e.g. URL to an attachment) - Change in content of any inline attachment A change to the external attachment itself (e.g. an image stored in a separate resource, referenced with a URL) does not require a change in either strong or weak Etag of the referring resource. Thus, clients synchronizing external attachments MUST handle that synchronization separately from synchronizing the event with the attachment. --- However, even having proposed this, I am not convinced that it's simply enough to effectively interoperate. > > Following SEQUENCE here seems like a bad idea, given the vagueness of > the specification and its requirement that the organizer guess what > might cause people to change their attendance. (Certainly, in my > world, someone else confirming their attendance might affect my > attendance. Typically more because we don't both need to be at a > given meeting than because I can't stand to be in the same room as > Lisa, f.e.) Uh, gee, thanks! ;) Lisa 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 116AE7F783 for ; Thu, 22 Dec 2005 09:08:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76B4A1422F4 for ; Thu, 22 Dec 2005 09:09:47 -0800 (PST) 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 10841-05 for ; Thu, 22 Dec 2005 09:09:47 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id DAF6B1422F1 for ; Thu, 22 Dec 2005 09:09:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 7B18035D6CB for ; Thu, 22 Dec 2005 16:57:11 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id D021335D1F5 for ; Thu, 22 Dec 2005 16:57:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59A2F739-9199-422C-8033-E6A1566ADF70@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 17:07:10 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 22 Dec 2005 17:08:19 -0000 On 22. Dez 2005, at 16:51 Uhr, Mike Shaver wrote: >> Usually the etag will just be a content revision number (most likely >> matching the revision field of iCalendar, SEQUENCE) and is rather >> cheap to deliver. >> I'm not sure why you suggest that the etag must be computed, I know >> of no server which does this (I know that Apache can be optionally >> configured to compute a hash, but no one does it in RL ...). > > Is support for weak entity tags widespread? I don't think so and weak etags are useless in our context anyway as mentioned before in this thread (only allowed for GET and HEAD methods). > I certainly believe from my reading of the HTTP RFC > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11) that a > strong entity tag has to represent the specific set of octets, not > just semantic equivalence. Exactly. Semantic equivalence is not enough. BTW 1: even if you calculate the etag as a hash, this can be done on writes. Retrieving the etag will be fast. BTW 2: the etag is not required to be the same for equal content (eg in the history of a resource). Only the reverse is true. > I am not actually confident that we can give implementors a meaningful > definition of "semantic equivalence", personally. The server vendor is free to choose how he ensures 3.11. I only made suggestions, this should not be specified in CalDAV. Eg in OGo we have an "object revision" number which is increased on each write and is unique for a resource in combination with the primary key sequence. I assume a lot of servers do similiar stuff. > Following SEQUENCE here seems like a bad idea, given the vagueness of > the specification and its requirement that the organizer guess what > might cause people to change their attendance. Yes, probably the iCalendar SEQUENCE was a rather bad example. Sorry ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 A75697F794 for ; Thu, 22 Dec 2005 08:53:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 255F11422F4 for ; Thu, 22 Dec 2005 08:54:32 -0800 (PST) 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 04989-06 for ; Thu, 22 Dec 2005 08:54:31 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by laweleka.osafoundation.org (Postfix) with ESMTP id C17391422F1 for ; Thu, 22 Dec 2005 08:54:31 -0800 (PST) Received: by wproxy.gmail.com with SMTP id 69so377674wra for ; Thu, 22 Dec 2005 07:51:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jcyjoB9vyPXIvq8IHzXnW3O2e69DojeMiUfUo07cFBfV6N0Kvh5TRoII8aMpdC1mLZu0DEksb9YFV7Hmxw70K8LFrIawzYANkWjJjnPD3G4R2pz5g6ohdb5sYwZUzdeXmtGERcjEbcXwBLBME9ekFAq6EO83CYGpQLqpxJD1uKw= Received: by 10.65.232.11 with SMTP id j11mr987837qbr; Thu, 22 Dec 2005 07:51:55 -0800 (PST) Received: by 10.65.135.14 with HTTP; Thu, 22 Dec 2005 07:51:55 -0800 (PST) Message-ID: Date: Thu, 22 Dec 2005 10:51:55 -0500 From: Mike Shaver To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis In-Reply-To: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 16:53:03 -0000 On 12/21/05, Helge Hess wrote: > On 22. Dez 2005, at 00:51 Uhr, Mike Shaver wrote: > > On 12/21/05, Helge Hess wrote: > >> Yes, definitely. Any server which modifies content will be required > >> to respond with a 205 (with an etag?!). > > I don't think they should be required to send an ETag. > > The etag is a must-have for consistent updates. If the server doesn't > send an etag, the client can't know whether its a regular server side > update or a conflict on the subsequent GET (eg a recreation of the > resource under the same URL). OK, that's fair. > Usually the etag will just be a content revision number (most likely > matching the revision field of iCalendar, SEQUENCE) and is rather > cheap to deliver. > I'm not sure why you suggest that the etag must be computed, I know > of no server which does this (I know that Apache can be optionally > configured to compute a hash, but no one does it in RL ...). Is support for weak entity tags widespread? I certainly believe from my reading of the HTTP RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11) that a strong entity tag has to represent the specific set of octets, not just semantic equivalence. I am not actually confident that we can give implementors a meaningful definition of "semantic equivalence", personally. Following SEQUENCE here seems like a bad idea, given the vagueness of the specification and its requirement that the organizer guess what might cause people to change their attendance. (Certainly, in my world, someone else confirming their attendance might affect my attendance. Typically more because we don't both need to be at a given meeting than because I can't stand to be in the same room as Lisa, f.e.) Mike 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 0D05A7F790 for ; Thu, 22 Dec 2005 08:51:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F2131422F4 for ; Thu, 22 Dec 2005 08:52:51 -0800 (PST) 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 07992-06 for ; Thu, 22 Dec 2005 08:52:51 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1C1831422F1 for ; Thu, 22 Dec 2005 08:52:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0E43935D74C for ; Thu, 22 Dec 2005 16:40:15 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 4AADD35D715 for ; Thu, 22 Dec 2005 16:40:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43AAC71E.9090305@adevsoft.com> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <43AAC71E.9090305@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 16:50:13 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 22 Dec 2005 16:51:23 -0000 On 22. Dez 2005, at 16:32 Uhr, Kervin L. Pierre wrote: > Helge Hess wrote: >> 2-a) GET /blah.ics, if-match: etag=ABC > > But could that GET be inconclusive since the server > may have split the ICS file into multiple resources? HTTP can't track such splits. So yes, if the server for example flattens a recurrence rule into multiple ics resources with different uids, the client can't know about that fact and will just see the new events as regular new ones. I think thats as good as it can be (splitting is a hack). > Ie. you get blah.ics back on your "2-a" GET, it has > the ETag from the 205 PUT but it does not represent > the ICal that was originally sent since the server > created blah1.ics, blah2.ics, etc. in response to > the original ICal. I can't follow you on this one. The etag of the 205 PUT response does not represent the "ICal that was originally sent" in any case, it represents the resource now living at the given URL. Please reread this thread. If you create _additional_ resources I think this is clearly a hack (maybe a necessary one since your server does not support the iCalendar data model [eg OGo is in this category as well]). >> BTW: I think the issue of conflicts is very much underestimated. > I agree, which is why I am leaning on having the > client require WebDAV Class 2 on logon, and use > locks. Locks do not scale, I would be very disappointed if this would be required for operating CalDAV when HTTP already supports optimistic locking (etags). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 9E7B47F788 for ; Thu, 22 Dec 2005 08:44:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1DF331422F4 for ; Thu, 22 Dec 2005 08:46:12 -0800 (PST) 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 15979-05 for ; Thu, 22 Dec 2005 08:46:11 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B6BE61422F1 for ; Thu, 22 Dec 2005 08:46:11 -0800 (PST) Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id jBMGBmUV024576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Dec 2005 11:11:50 -0500 Date: Thu, 22 Dec 2005 10:43:28 -0500 From: Cyrus Daboo To: "Kervin L. Pierre" , Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Message-ID: <152CA9D1110E06A6277E9FCD@ninevah.local> In-Reply-To: <43AAC71E.9090305@adevsoft.com> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <43AAC71E.9090305@adevsoft.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 16:44:43 -0000 Hi Kervin, --On December 22, 2005 10:32:46 AM -0500 "Kervin L. Pierre" wrote: > Ie. you get blah.ics back on your "2-a" GET, it has > the ETag from the 205 PUT but it does not represent > the ICal that was originally sent since the server > created blah1.ics, blah2.ics, etc. in response to > the original ICal. I don't think there are any circumstances where a CalDAV server will do that, given the data restrictions we have for PUT into calendar collections. -- Cyrus Daboo 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 42CAE7F77F for ; Thu, 22 Dec 2005 08:33:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B775A1422F4 for ; Thu, 22 Dec 2005 08:34:49 -0800 (PST) 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 06941-03 for ; Thu, 22 Dec 2005 08:34:49 -0800 (PST) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by laweleka.osafoundation.org (Postfix) with SMTP id 48D961422F1 for ; Thu, 22 Dec 2005 08:34:49 -0800 (PST) Received: (qmail 60704 invoked from network); 22 Dec 2005 15:32:14 -0000 Received: from unknown (HELO ?192.168.0.70?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 22 Dec 2005 15:32:13 -0000 Message-ID: <43AAC71E.9090305@adevsoft.com> Date: Thu, 22 Dec 2005 10:32:46 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> In-Reply-To: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 16:33:21 -0000 Hello Group, Helge Hess wrote: > 2-a) GET /blah.ics, if-match: etag=ABC But could that GET be inconclusive since the server may have split the ICS file into multiple resources? Ie. you get blah.ics back on your "2-a" GET, it has the ETag from the 205 PUT but it does not represent the ICal that was originally sent since the server created blah1.ics, blah2.ics, etc. in response to the original ICal. > > BTW: I think the issue of conflicts is very much underestimated. I agree, which is why I am leaning on having the client require WebDAV Class 2 on logon, and use locks. Best Regards, Kervin 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 BCF237F783 for ; Thu, 22 Dec 2005 05:06:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D6121422EE for ; Thu, 22 Dec 2005 05:07:40 -0800 (PST) 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 01755-09 for ; Thu, 22 Dec 2005 05:07:40 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06B0B1422E9 for ; Thu, 22 Dec 2005 05:07:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4CE1135D580 for ; Thu, 22 Dec 2005 12:55:03 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 2EE3335D57F for ; Thu, 22 Dec 2005 12:55:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43AA9566.9030904@gmx.de> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <43AA4096.9080801@gmx.de> <74AC8015-4FC5-4EA2-8301-08A0FA268C4A@opengroupware.org> <43AA9566.9030904@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92F65CAA-0207-487C-B616-561AB34A4071@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 13:05:03 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 22 Dec 2005 13:06:11 -0000 On 22. Dez 2005, at 13:00 Uhr, Julian Reschke wrote: > OK. If by "419 Conflict" you mean "412 Precondition Failed", then > this may work :-) Ups, yes, of course ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 05FAE7F517 for ; Thu, 22 Dec 2005 05:03:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 955881422FB for ; Thu, 22 Dec 2005 05:05:00 -0800 (PST) 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 29114-03 for ; Thu, 22 Dec 2005 05:05:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id D7CD11422E9 for ; Thu, 22 Dec 2005 05:04:59 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2005 12:02:23 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp032) with SMTP; 22 Dec 2005 13:02:23 +0100 X-Authenticated: #1915285 Message-ID: <43AA9566.9030904@gmx.de> Date: Thu, 22 Dec 2005 13:00:38 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <43AA4096.9080801@gmx.de> <74AC8015-4FC5-4EA2-8301-08A0FA268C4A@opengroupware.org> In-Reply-To: <74AC8015-4FC5-4EA2-8301-08A0FA268C4A@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 13:03:32 -0000 Helge Hess wrote: > On 22. Dez 2005, at 06:58 Uhr, Julian Reschke wrote: >>> Basically the transaction looks like: >>> 1-a) PUT /blah.ics >>> 1-b) 205, etag ABC >>> 2-a) GET /blah.ics, if-match: etag=ABC >>> 2-bx) new content >>> or >>> 2-by) 419 Conflict (etag changed, some other user/client/server >>> changed the >>> item) >> > ... >> >> Me confused. Shouldn't that be...: >> >> 1-a) PUT /blah.ics >> 1-b) 205, etag ABC >> 2-a) GET /blah.ics, if-none-match: etag=ABC >> 2-bx) new content (200, etag did change) >> or >> 2-by) 304 Not Modified (etag did not change) >> ? > > No! :-) > > The 1-b 205 says that the server changed the content and the etag > represents the state of this content which in turn is a result of 1-a. > What 2-a does is (_reliably_) fetching the result of 1-a which is > unknown to the client at this point. > > If the if-match fails, the client knows that there is an actual conflict > (someone else wrote to the same resource in the meantime). > > > Your sequence is the one to be used for refreshes if the server does not > change the content, that is, if it returns a 201 or 200 in step 1-b. OK. If by "419 Conflict" you mean "412 Precondition Failed", then this may work :-) Best regards, Julian 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 345F27F6F0 for ; Thu, 22 Dec 2005 03:59:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD7191422FC for ; Thu, 22 Dec 2005 04:01:10 -0800 (PST) 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 15041-01 for ; Thu, 22 Dec 2005 04:01:10 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 690631422FB for ; Thu, 22 Dec 2005 04:01:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 14FE335D405 for ; Thu, 22 Dec 2005 11:48:33 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id A494E35D42A for ; Thu, 22 Dec 2005 11:48:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43AA4096.9080801@gmx.de> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <43AA4096.9080801@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74AC8015-4FC5-4EA2-8301-08A0FA268C4A@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 11:58:30 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 22 Dec 2005 11:59:42 -0000 On 22. Dez 2005, at 06:58 Uhr, Julian Reschke wrote: >> Basically the transaction looks like: >> 1-a) PUT /blah.ics >> 1-b) 205, etag ABC >> 2-a) GET /blah.ics, if-match: etag=ABC >> 2-bx) new content >> or >> 2-by) 419 Conflict (etag changed, some other user/client/server >> changed the >> item) > > ... > > Me confused. Shouldn't that be...: > > 1-a) PUT /blah.ics > 1-b) 205, etag ABC > 2-a) GET /blah.ics, if-none-match: etag=ABC > 2-bx) new content (200, etag did change) > or > 2-by) 304 Not Modified (etag did not change) > ? No! :-) The 1-b 205 says that the server changed the content and the etag represents the state of this content which in turn is a result of 1- a. What 2-a does is (_reliably_) fetching the result of 1-a which is unknown to the client at this point. If the if-match fails, the client knows that there is an actual conflict (someone else wrote to the same resource in the meantime). Your sequence is the one to be used for refreshes if the server does not change the content, that is, if it returns a 201 or 200 in step 1-b. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 650C97F76D for ; Wed, 21 Dec 2005 23:01:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33F301422FB for ; Wed, 21 Dec 2005 23:02:52 -0800 (PST) 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 29347-10 for ; Wed, 21 Dec 2005 23:02:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 75F281422FA for ; Wed, 21 Dec 2005 23:02:51 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2005 06:00:14 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp023) with SMTP; 22 Dec 2005 07:00:14 +0100 X-Authenticated: #1915285 Message-ID: <43AA4096.9080801@gmx.de> Date: Thu, 22 Dec 2005 06:58:46 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> In-Reply-To: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 07:01:23 -0000 Helge Hess wrote: > On 22. Dez 2005, at 00:51 Uhr, Mike Shaver wrote: >> On 12/21/05, Helge Hess wrote: >>> Yes, definitely. Any server which modifies content will be required >>> to respond with a 205 (with an etag?!). >> I don't think they should be required to send an ETag. > > The etag is a must-have for consistent updates. If the server doesn't > send an etag, the client can't know whether its a regular server side > update or a conflict on the subsequent GET (eg a recreation of the > resource under the same URL). > > Basically the transaction looks like: > 1-a) PUT /blah.ics > 1-b) 205, etag ABC > 2-a) GET /blah.ics, if-match: etag=ABC > 2-bx) new content > or > 2-by) 419 Conflict (etag changed, some other user/client/server changed the > item) > ... Me confused. Shouldn't that be...: 1-a) PUT /blah.ics 1-b) 205, etag ABC 2-a) GET /blah.ics, if-none-match: etag=ABC 2-bx) new content (200, etag did change) or 2-by) 304 Not Modified (etag did not change) ? 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 A86417F777 for ; Wed, 21 Dec 2005 17:20:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B40DE1422F1 for ; Wed, 21 Dec 2005 17:21:31 -0800 (PST) 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 29659-07 for ; Wed, 21 Dec 2005 17:21:31 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5258C1422F0 for ; Wed, 21 Dec 2005 17:21:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 9103D35D08C for ; Thu, 22 Dec 2005 01:08:50 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 2BE0F35A924 for ; Thu, 22 Dec 2005 01:08:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Thu, 22 Dec 2005 01:18:53 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 22 Dec 2005 01:20:02 -0000 On 22. Dez 2005, at 00:51 Uhr, Mike Shaver wrote: > On 12/21/05, Helge Hess wrote: >> Yes, definitely. Any server which modifies content will be required >> to respond with a 205 (with an etag?!). > I don't think they should be required to send an ETag. The etag is a must-have for consistent updates. If the server doesn't send an etag, the client can't know whether its a regular server side update or a conflict on the subsequent GET (eg a recreation of the resource under the same URL). Basically the transaction looks like: 1-a) PUT /blah.ics 1-b) 205, etag ABC 2-a) GET /blah.ics, if-match: etag=ABC 2-bx) new content or 2-by) 419 Conflict (etag changed, some other user/client/server changed the item) BTW: I think the issue of conflicts is very much underestimated. Conflicts are highly likely in synchronization setups of shared folders (just one example: rapidly synching some thousands of Palm records of several users at 9:00 AM). > I don't think > ETag-for-unknown-content is useful to a client, and I don't think it's > worth making the server perform the serialization work to compute the > ETag for the resulting bag-o'-bytes. Usually the etag will just be a content revision number (most likely matching the revision field of iCalendar, SEQUENCE) and is rather cheap to deliver. I'm not sure why you suggest that the etag must be computed, I know of no server which does this (I know that Apache can be optionally configured to compute a hash, but no one does it in RL ...). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 C35387F5F8 for ; Wed, 21 Dec 2005 16:52:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC43E1422F1 for ; Wed, 21 Dec 2005 16:53:40 -0800 (PST) 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 12754-09 for ; Wed, 21 Dec 2005 16:53:40 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id 88D7B1422F0 for ; Wed, 21 Dec 2005 16:53:40 -0800 (PST) Received: by zproxy.gmail.com with SMTP id m7so374904nzf for ; Wed, 21 Dec 2005 15:51:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mjk19yER/dT1IPLGUbGcN+HArMgGZNYEATr3ELARayOaFd8fIgsOPJCL72KLnzv8CzdzcN1nEaBs1zWgNCKJWD4QkeK0FmjeT6wZuUP0KiNOIEmxQYhXXB5/D5aSY3VhusStTOtWy0MS5cvZ7PgbMoesNP5+9Q9NJs5x9Ex/DBM= Received: by 10.65.155.11 with SMTP id h11mr10113qbo; Wed, 21 Dec 2005 15:51:04 -0800 (PST) Received: by 10.65.135.14 with HTTP; Wed, 21 Dec 2005 15:51:04 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2005 18:51:04 -0500 From: Mike Shaver To: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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, 22 Dec 2005 00:52:11 -0000 On 12/21/05, Helge Hess wrote: > Yes, definitely. Any server which modifies content will be required > to respond with a 205 (with an etag?!). I don't think they should be required to send an ETag. I don't think ETag-for-unknown-content is useful to a client, and I don't think it's worth making the server perform the serialization work to compute the ETag for the resulting bag-o'-bytes. Mike 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 968B97F74C for ; Wed, 21 Dec 2005 14:47:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B96AE1422EA for ; Wed, 21 Dec 2005 14:49:15 -0800 (PST) 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 25267-04 for ; Wed, 21 Dec 2005 14:49:15 -0800 (PST) Received: from S1.cableone.net (s1.cableone.net [24.116.0.227]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2314F1422CD for ; Wed, 21 Dec 2005 14:49:15 -0800 (PST) Received: from [192.168.168.10] (unverified [24.119.163.152]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 40932810 for ; Wed, 21 Dec 2005 14:47:05 -0700 Message-ID: <43A9CD3D.7080207@Royer.com> Date: Wed, 21 Dec 2005 14:46:37 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> <43A79A62.6030307@Royer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040200020206090503020203" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-Aspam: Words 0.0 -561-5848 -562-2131 -gagel -caledonia -theres -iis -generate -warned -scanning X-Aspam: URLS scored 0.8 verisign.com cnc.bc.ca X-Aspam: Best match was sample c:\good\1051592149.251_651.ball X-Aspam: Total 0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 1, in=19, out=16, spam=0 Known=true X-External-IP: 24.119.163.152 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 21 Dec 2005 22:47:46 -0000 This is a cryptographically signed message in MIME format. --------------ms040200020206090503020203 Content-Type: multipart/mixed; boundary="------------070109090807020203000400" This is a multi-part message in MIME format. --------------070109090807020203000400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mike Shaver wrote: > On 12/20/05, Doug Royer wrote: > >>Maybe not as part of the CALDAV work and not CALSIFY. We need >>a vendor container, something like: >> >> BEGIN:VENDOR-SPECIFIC-CLIENT > > > Forgive my naivete: is there a reason to specify "CLIENT" in there? I think there needs to be some way to specify vendor specific 'stuff' and I do not care what the name is. > As an erstwhile calendar implementor, though, your suggestion leaves > me somewhat cold, as I'll have to know if I'm dealing with a peer that > supports VENDOR-SPECIFIC when I push data out into the wild via IMIP > or WebDAV or whatever else. That is true of any component, property, parameter, or 2445 defined value. If I iMIP you a VJOURNAL, can any arbitrary peer handle it? I think there is a need to keep from cluttering up the components with multiple X- properties over time after applications start using shared calendars. X-MY-SYNC-VENDOR-NUMBER-132 in the same calendar over time. I do not think that it is needed now. I do think that it will be needed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070109090807020203000400 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------070109090807020203000400-- --------------ms040200020206090503020203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTIyMTIxNDYzN1owIwYJKoZIhvcNAQkEMRYEFP7jkUxde0n68kRx/6SZ58Hy 80cFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAFJQGI6brBxMlhWnFJNyG7YIIFWqU29B2BLDt8VVcdSKC2+tvtR+23ACWos/2tXnwhJC Z1VMk0wnRjzvfuSfOZRvOZs+jEAw4UD8MqKLcjSFFo2u6QkkUMNEuh6mAmMkPeFfhPre/a0d TxtngmAQ30lumF+qKe+OF/MYvd5mrjPy/LtRCm4GO7kPlzXj2PHLLjWcs7UUH77nJAQl8L7T 6JZKszMyS95a2q9hVHPz1c65Qe8YKID33oaMWjtdqJBq6rMGvSS4Tzgq5BsLoOrzZw6tEVxc BruuHt2P4NE4GicM4/faHSxVgCS5EL/4Z7WMlgucqU8Hr9zC7Y0DSPLC1qgAAAAAAAA= --------------ms040200020206090503020203-- 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 095E27F71F for ; Wed, 21 Dec 2005 13:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B43E1422EF for ; Wed, 21 Dec 2005 13:20:34 -0800 (PST) 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 30577-05 for ; Wed, 21 Dec 2005 13:20:34 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC12F1422C8 for ; Wed, 21 Dec 2005 13:20:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A0AC535C31C for ; Wed, 21 Dec 2005 21:08:17 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 3CAD835B3E2 for ; Wed, 21 Dec 2005 21:08:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Wed, 21 Dec 2005 21:17:55 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 21 Dec 2005 21:19:05 -0000 On 21. Dez 2005, at 17:39 Uhr, Lisa Dusseault wrote: > It turns out HTTP has had, all along, a response code very suited > to the server munging data on PUT: the 205 response. Yves Lafon > pointed it out. > > 10.2.6 205 Reset Content Hm. The explanation of 205 says something different, but I assume its title (reset content) is close enough to be used for our purposes? According to the content of spec item 10.2.6 the "reset content" has nothing to do with a cache or the entity which was uploaded. The "reset" applies to the referer page, not to the actual entity: "view which *caused* the request to be sent" In the context of CalDAV one might interpret the spec as "if an event editor performs a PUT due to a 'save' button and the server returns 205, the event editor should be cleared". But as mentioned, I think its close enough if its explained in CalDAV. > Should we reference this in CalDAV? Yes, definitely. Any server which modifies content will be required to respond with a 205 (with an etag?!). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 6332E7F727; Wed, 21 Dec 2005 12:44:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 995331422F1; Wed, 21 Dec 2005 12:46:24 -0800 (PST) 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 17679-05; Wed, 21 Dec 2005 12:46:24 -0800 (PST) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by laweleka.osafoundation.org (Postfix) with ESMTP id EE1631422EF; Wed, 21 Dec 2005 12:46:23 -0800 (PST) Received: from [192.168.168.10] (unverified [24.119.163.152]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 39844119 for multiple; Wed, 21 Dec 2005 13:04:05 -0700 Message-ID: <43A9B047.8020807@Royer.com> Date: Wed, 21 Dec 2005 12:43:03 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , CalDAV DevList , Calsify , www-rdf-calendar@w3.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070604030705000102070002" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 1, in=6, out=6, spam=0 Known=true X-External-IP: 24.119.163.152 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-caldav] [Fwd: RFC 4324 on Calendar Access Protocol (CAP)] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "ietf-calendar@imc.org" 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, 21 Dec 2005 20:44:55 -0000 This is a cryptographically signed message in MIME format. --------------ms070604030705000102070002 Content-Type: multipart/mixed; boundary="------------010600080700030008020301" This is a multi-part message in MIME format. --------------010600080700030008020301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit CAP is out !! Thanks EVERYONE for their help!! -------- Original Message -------- Subject: RFC 4324 on Calendar Access Protocol (CAP) Date: Wed, 21 Dec 2005 11:10:43 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 4324 Title: Calendar Access Protocol (CAP) Author(s): D. Royer, G. Babics, S. Mansour Status: Experimental Date: December 2005 Mailbox: Doug@IntelliCal.com, george.babics@oracle.com, smansour@ebay.com Pages: 131 Characters: 254638 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-royer-calsch-cap-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4324.txt The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------010600080700030008020301 Content-Type: Message/External-body; name="rfc4324.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rfc4324.txt" Content-Type: text/plain Content-ID: <051221110948.RFC@RFC-EDITOR.ORG> --------------010600080700030008020301 Content-Type: text/plain; name="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.asc" _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------010600080700030008020301 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------010600080700030008020301-- --------------ms070604030705000102070002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTIyMTE5NDMwM1owIwYJKoZIhvcNAQkEMRYEFJ3YR8GZtYBf/LyQpjdLonT+ 9PxLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAAsRHV2mFLbYeMSVc8WJsSCip+68hJpydA+ZMDxmm+hu7g0D0a7stfaKDuaX+16O2ce9 zWKXohYoEAGRwk2oX5YgZ0Is/3pUyuKSUOpF966FbTwWlkyrHhpXNHlz/3brvIhqBOFEN6Gk /xz2aSp2NY7lkcSDuv6ct+pv918xXewKQ8swwGubRhr7dqkK06sqR/4Lc/1jysB1zdM297fr XWB3DrtBEQ+rCfMee9sY5GSF+zFTRGTyAfzpMQE1h3I8Any87731JdhAThC6nRTISjjS2JbR tglssPN+kA/Tc9+Rka562dy8KrAnsqYmub+nfWLxek4ikLMxsbUvgO8rlCIAAAAAAAA= --------------ms070604030705000102070002-- 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 E5B857F62E for ; Wed, 21 Dec 2005 09:40:25 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2078E1422B1 for ; Wed, 21 Dec 2005 09:41:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) To: CalDAV DevList Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-11-109648613 From: Lisa Dusseault Date: Wed, 21 Dec 2005 08:39:14 -0800 X-Mailer: Apple Mail (2.623) Subject: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis 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, 21 Dec 2005 17:40:26 -0000 --Apple-Mail-11-109648613 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed It turns out HTTP has had, all along, a response code very suited to=20 the server munging data on PUT: the 205 response. Yves Lafon pointed=20 it out. 10.2.6 205 Reset Content The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity. Should we reference this in CalDAV? Lisa Begin forwarded message: > Resent-From: w3c-dist-auth@w3.org > From: Yves Lafon > Date: December 21, 2005 2:05:08 AM PST > To: Dan Brotsky > Cc: Julian Reschke , Wilfredo S=E1nchez Vega=20 > , Jim Whitehead , WebDav WG=20= > > Subject: RE: Summary of ETag related issues in RFC2518bis > > > On Tue, 20 Dec 2005, Dan Brotsky wrote: > >> >>> Depends on what the target platform is. Apache is built on >>> top of APR, (Apache Portable Runtime) as I recall, and that >>> API may not have a guarantee of a higher timer resolution. >>> What would be your proposal to the Apache guys how to handle that? >> >> I gave one below. >> >>> Second, even in filesystems with millisecond resolutions, >>> all the filesystem has to do is support exclusive >>> write-locking and you can build a compliant server. The >>> server must simply keep the file locked long enough to avoid >>> the milllisecond window and then set the time back to the >>> write time in order to ensure that any interference is noticeable. >>> >>> You mean "second" resolution, right? >> >> No, I meant millisecond. Perhaps you are sugggesting that APR only=20= >> supports 1-second resolution? Why would that be? I know of no=20 >> filesystems with that kind of resolution. > > Well, the issue started with Apache using weak ETags, then strong=20 > ones. Note that the ETag is an opaque string, the way it is computed=20= > is up to the server. If a server want to use the md5 sum as the ETag,=20= > it is entirely possible, the choice to use the timestamp and length is=20= > part of Apache's design. Try to use "ContentDigest on" on big files=20 > and you will understand why. > > My server knows how to handle x !=3D GET(PUT(x)) for subsequent = revision=20 > (well because cvs knows), it handles itself the issue, without any=20 > need from the client to know what's really going on behind the scene. > > The discussion boils down to: > After a PUT, is it safe to continue to edit the resource without doing=20= > a reload? > And the server should give the answer. 205 if it is not safe, 204=20 > otherwise, with the ETag that someone will get in a subsequent GET. > >> Yes: stop returning weak etags. See above. > > "on PUT". Agreed. > > --=20 > Yves Lafon - W3C > "Baroula que barouleras, au ti=E9u toujou t'entourneras." > --Apple-Mail-11-109648613 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 It turns out HTTP has had, all along, a response code very suited to the server munging data on PUT: the 205 response. Yves Lafon pointed it out. 10.2.6 205 Reset Content The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity. Should we reference this in CalDAV? Lisa Begin forwarded message: 0000,0000,0000Resent-From: w3c-dist-auth@w3.org 0000,0000,0000From: Yves Lafon < 0000,0000,0000Date: December 21, 2005 2:05:08 AM PST 0000,0000,0000To: Dan Brotsky < 0000,0000,0000Cc: Julian Reschke <, Wilfredo S=E1nchez Vega <, Jim Whitehead <, WebDav WG < 0000,0000,0000Subject: RE: Summary of ETag related issues in RFC2518bis On Tue, 20 Dec 2005, Dan Brotsky wrote: Depends on what the target platform is. Apache is built on top of APR, (Apache Portable Runtime) as I recall, and that API may not have a guarantee of a higher timer resolution. What would be your proposal to the Apache guys how to handle that? I gave one below. Second, even in filesystems with millisecond resolutions, all the filesystem has to do is support exclusive write-locking and you can build a compliant server. The server must simply keep the file locked long enough to avoid the milllisecond window and then set the time back to the write time in order to ensure that any interference is noticeable. You mean "second" resolution, right? No, I meant millisecond. Perhaps you are sugggesting that APR only supports 1-second resolution? Why would that be? I know of no filesystems with that kind of resolution. Well, the issue started with Apache using weak ETags, then strong ones. Note that the ETag is an opaque string, the way it is computed is up to the server. If a server want to use the md5 sum as the ETag, it is entirely possible, the choice to use the timestamp and length is part of Apache's design. Try to use "ContentDigest on" on big files and you will understand why. My server knows how to handle x !=3D GET(PUT(x)) for subsequent revision (well because cvs knows), it handles itself the issue, without any need from the client to know what's really going on behind the scene. The discussion boils down to: After a PUT, is it safe to continue to edit the resource without doing a reload? And the server should give the answer. 205 if it is not safe, 204 otherwise, with the ETag that someone will get in a subsequent GET. Yes: stop returning weak etags. See above. "on PUT". Agreed. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." = --Apple-Mail-11-109648613-- 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 4B7167F6D6 for ; Tue, 20 Dec 2005 08:16:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9322B1422D5 for ; Tue, 20 Dec 2005 08:17:46 -0800 (PST) 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 24861-04 for ; Tue, 20 Dec 2005 08:17:46 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AFB91422D2 for ; Tue, 20 Dec 2005 08:17:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3447035C2DE for ; Tue, 20 Dec 2005 16:06:14 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id BB95D35D0EB for ; Tue, 20 Dec 2005 16:06:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43A81871.6010903@adevsoft.com> References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> <43A79A62.6030307@Royer.com> <43A81871.6010903@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11D4828C-A5B6-4C15-A8E6-BB279914A18E@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Tue, 20 Dec 2005 16:15:02 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Tue, 20 Dec 2005 16:16:16 -0000 On 20. Dez 2005, at 15:42 Uhr, Kervin L. Pierre wrote: > Would a vendor adding their own XML namespace > also work? That way a client can simply > ignore that namespace, instead of modifying > their ICal parser. A server can do this. A client can't since PROPPATCH support for arbitary properties is not a MUST (just reread this thread from the beginning ...). Another issue of using properties is that you can't do atomic updates without locks (two operations are required to push a full object instead of just one). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 8ACB37F644 for ; Tue, 20 Dec 2005 07:43:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D705B1422D0 for ; Tue, 20 Dec 2005 07:45:04 -0800 (PST) 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 13968-02 for ; Tue, 20 Dec 2005 07:45:04 -0800 (PST) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by laweleka.osafoundation.org (Postfix) with SMTP id 6334D1422AE for ; Tue, 20 Dec 2005 07:45:04 -0800 (PST) Received: (qmail 61599 invoked from network); 20 Dec 2005 14:42:27 -0000 Received: from unknown (HELO ?192.168.0.70?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 20 Dec 2005 14:42:27 -0000 Message-ID: <43A81871.6010903@adevsoft.com> Date: Tue, 20 Dec 2005 09:42:57 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> <43A79A62.6030307@Royer.com> In-Reply-To: <43A79A62.6030307@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 20 Dec 2005 15:43:34 -0000 Hello Doug, Doug Royer wrote: > > Maybe not as part of the CALDAV work and not CALSIFY. We need > a vendor container, something like: > > BEGIN:VENDOR-SPECIFIC-CLIENT > VENDOR-ID:...some registered vendor id... > VENDOR-VERSION: ...value under vendor control... > ... Would a vendor adding their own XML namespace also work? That way a client can simply ignore that namespace, instead of modifying their ICal parser. Looks like Oracle already does this. Eg... http://cal.example.com/home/bernard/calendar/ev102.ics "23ba4d-ff11fb" ... ... BEGIN:VCALENDAR VERSION:2.0 ... Best Regards, Kervin 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 E76FB7F6BC for ; Tue, 20 Dec 2005 07:03:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4447B1422D2 for ; Tue, 20 Dec 2005 07:04:58 -0800 (PST) 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 28304-05 for ; Tue, 20 Dec 2005 07:04:58 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by laweleka.osafoundation.org (Postfix) with ESMTP id ED4E31422A8 for ; Tue, 20 Dec 2005 07:04:57 -0800 (PST) Received: by zproxy.gmail.com with SMTP id m7so2911230nzf for ; Tue, 20 Dec 2005 06:02:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mKdbmKS9FBgtNmgkIWzYVtLjXgHVpVFXGU406ICUF0VO5BOx5upWSq7jKexTi+jPj60GJOshP0ojIeItUTHBngo9eW6GkR9lABDah5eqy6Vp+cFa3WGB2asOKS4Em4dIrlVuRdGp7c6HHH1JtCWxQca2kgIvOtWBjrtlxMMBBEo= Received: by 10.64.27.1 with SMTP id a1mr973132qba; Tue, 20 Dec 2005 06:02:20 -0800 (PST) Received: by 10.65.135.14 with HTTP; Tue, 20 Dec 2005 06:02:17 -0800 (PST) Message-ID: Date: Tue, 20 Dec 2005 09:02:17 -0500 From: Mike Shaver To: CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <43A79A62.6030307@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> <43A79A62.6030307@Royer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: 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: Tue, 20 Dec 2005 15:03:28 -0000 On 12/20/05, Doug Royer wrote: > > Maybe not as part of the CALDAV work and not CALSIFY. We need > a vendor container, something like: > > BEGIN:VENDOR-SPECIFIC-CLIENT Forgive my naivete: is there a reason to specify "CLIENT" in there?=20 It seems to me that either we would want servers to be able to do something very very similar, or everything that touches iCalendar is considered an "iCalendar client" and the suffix is simply redundant. As an erstwhile calendar implementor, though, your suggestion leaves me somewhat cold, as I'll have to know if I'm dealing with a peer that supports VENDOR-SPECIFIC when I push data out into the wild via IMIP or WebDAV or whatever else. Mike 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 D79267F6DB for ; Mon, 19 Dec 2005 22:46:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85FCC1422D9 for ; Mon, 19 Dec 2005 22:47:45 -0800 (PST) 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 02338-04 for ; Mon, 19 Dec 2005 22:47:45 -0800 (PST) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25EDE1422D1 for ; Mon, 19 Dec 2005 22:47:45 -0800 (PST) Received: from [192.168.168.10] (unverified [24.119.163.152]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 39668507 for ; Mon, 19 Dec 2005 23:05:39 -0700 Message-ID: <43A79A62.6030307@Royer.com> Date: Mon, 19 Dec 2005 22:45:06 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> In-Reply-To: <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> Content-Type: multipart/mixed; boundary="------------020703090104020101010909" X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 0, in=1, out=1, spam=0 Known=true X-External-IP: 24.119.163.152 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 06:46:15 -0000 This is a multi-part message in MIME format. --------------020703090104020101010909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Maybe not as part of the CALDAV work and not CALSIFY. We need a vendor container, something like: BEGIN:VENDOR-SPECIFIC-CLIENT VENDOR-ID:...some registered vendor id... VENDOR-VERSION: ...value under vendor control... ... (Any additional properties in here do not need an x- prefix and do not need to be registered) ... END:VENDOR-SPECIFIC-CLIENT Then allow zero or more VENDOR-SPECIFIC-CIENT components in any VCALENDAR, VEVENT, VALARM, VTODO, ... In this way each vendor can store properties that are under their own realm without having to go through the iCal registration process for each property they need. This would be useful for persistent information that is unrelated to the event details and times. And we require that the contents of a VENDOR-SPECIFIC-CLIENT component be limited to components, properties, parameters, and values that do not effect the calendaring or scheduling objects when the VENDOR-SPECIFIC-CLIENT components are removed from the VCALENDAR. Just allow UI properties, synchronization properties, or whatever a specific client needs to persist that is not event details. Lisa Dusseault wrote: > From the reaction to my talk at ApacheCon about CalDav, I can tell you > a lot of people are excited about CalDAV just for personal use -- e.g. > for synching between a client at home and a client at work and possibly, > one day, a mobile device. So there's a powerful use case for allowing > clients to store their "own stuff". > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020703090104020101010909 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------020703090104020101010909-- 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 EE18C7F66E for ; Mon, 19 Dec 2005 12:49:53 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E0DD41422A3; Mon, 19 Dec 2005 12:51:24 -0800 (PST) In-Reply-To: <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <57b63070b7fa57eed98961e76c4182dc@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Mon, 19 Dec 2005 11:48:45 -0800 To: Helge Hess X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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: Mon, 19 Dec 2005 20:49:54 -0000 On Dec 19, 2005, at 5:00 AM, Helge Hess wrote: > On 19. Dez 2005, at 06:34 Uhr, douglm@rpi.edu wrote: >> We should be able to state quite explicitly the requirements for >> interoperability. > > There was plenty of discussion on that now and honestly I think > further discussion will lead to nowhere, everyone has stated his > opinion. > So far everyone seems to have a different opinion on that and I have > the impression that the topic will just get "dropped" as unresolvable? > Or is there some way to vote on the issue in a useful way? > > > In response to the valid issues raised by Julian (and others) I think > I've changed my opinion to: > - CalDAV servers are required to store verbatim copies > - PROPPATCH is a SHOULD just like in WebDAV > Why? Because HTTP/WebDAV is designed with that assumption in mind and > it keeps the CalDAV protocol clean. > I can go along with this proposal. > >> at least we can still see the events and invite people to our >> meetings and surely that's the main point. > > For inviting people to our meetings we can already use iMIP. IMHO the > main point of CalDAV is to provide a client/server calendar _storage_ > protocol. And if most/all clients will need an _additional_ storage to > save their "own" stuff, this would be extremely annoying. From the reaction to my talk at ApacheCon about CalDav, I can tell you a lot of people are excited about CalDAV just for personal use -- e.g. for synching between a client at home and a client at work and possibly, one day, a mobile device. So there's a powerful use case for allowing clients to store their "own stuff". thx, Lisa 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 ADD2F7F68F for ; Mon, 19 Dec 2005 06:26:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A02CA1422C5 for ; Mon, 19 Dec 2005 06:26:09 -0800 (PST) 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 21044-02 for ; Mon, 19 Dec 2005 06:26:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id E34871422B0 for ; Mon, 19 Dec 2005 06:26:08 -0800 (PST) Received: (qmail invoked by alias); 19 Dec 2005 14:26:07 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 19 Dec 2005 15:26:07 +0100 X-Authenticated: #1915285 Message-ID: <43A6C2A1.1060902@gmx.de> Date: Mon, 19 Dec 2005 15:24:33 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Mike Shaver Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> <43A6B4E3.2010700@gmx.de> <43A6BE44.9080608@adevsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 14:26:09 -0000 Mike Shaver wrote: > On 12/19/05, Kervin L. Pierre wrote: >> Or the client could assume that what it >> sent is not necessarily what the server >> will store, and that the ETag pertains >> to what was stored? Why won't that >> option work? > > What good does that do the client? It can't use that ETag in the > future to know if it needs an update, because it don't know what data > is signified by that ETag, right? You know that it's the data you have PUT, except for whatver the server felt rewriting. How does it matter, unless you want to do a subsequent GET with Range header? Best regards, Julian 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 76CB47F684 for ; Mon, 19 Dec 2005 06:21:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 690E71422C5 for ; Mon, 19 Dec 2005 06:21:13 -0800 (PST) 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 10883-04 for ; Mon, 19 Dec 2005 06:21:13 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BDCB1422A8 for ; Mon, 19 Dec 2005 06:21:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A297235ADF0 for ; Mon, 19 Dec 2005 15:12:10 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 4A21135A6F8 for ; Mon, 19 Dec 2005 15:12:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43A6BE44.9080608@adevsoft.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> <43A6B4E3.2010700@gmx.de> <43A6BE44.9080608@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <679F737A-C078-406E-A9B3-036C8CB8EB52@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Mon, 19 Dec 2005 15:21:10 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Mon, 19 Dec 2005 14:21:13 -0000 On 19. Dez 2005, at 15:05 Uhr, Kervin L. Pierre wrote: > Julian Reschke wrote: >> That is, CalDAV will need to figure out how servers can use strong >> ETags and still rewrite the content. > > Or the client could assume that what it > sent is not necessarily what the server > will store, and that the ETag pertains > to what was stored? As pointed out by Julian this is how it works right now. > Why won't that option work? This was explained in this subthread. The client will immediatly need to reget the content from the server to have the server changes (eg added server X- flags, flattened recurrences, whatever) for the next update operation. This is not necessarily a bad thing, but is not what WebDAV clients currently do and IMHO it would need to be pointed at in big letters in the CalDAV spec. (like "ATTENTION: clients which maintain in- memory or filesystem caches will need to perform a GET after any PUT to catch server side changes"). This is why I suggested that returning the "new content" as the PUT response might be a viable option. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 3CD6F7F684 for ; Mon, 19 Dec 2005 06:20:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 305DA1422C5 for ; Mon, 19 Dec 2005 06:20:56 -0800 (PST) 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 00663-09 for ; Mon, 19 Dec 2005 06:20:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 748F91422A8 for ; Mon, 19 Dec 2005 06:20:55 -0800 (PST) Received: (qmail invoked by alias); 19 Dec 2005 14:20:53 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 19 Dec 2005 15:20:53 +0100 X-Authenticated: #1915285 Message-ID: <43A6C167.3060408@gmx.de> Date: Mon, 19 Dec 2005 15:19:19 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> <43A6B4E3.2010700@gmx.de> <43A6BE44.9080608@adevsoft.com> In-Reply-To: <43A6BE44.9080608@adevsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 14:20:56 -0000 Kervin L. Pierre wrote: > Julian Reschke wrote: >> That is, CalDAV will need to figure out how servers can use strong >> ETags and still rewrite the content. >> > > Or the client could assume that what it > sent is not necessarily what the server > will store, and that the ETag pertains > to what was stored? Why won't that > option work? That would work, it just needs a clarification in RFC2616's errata (about what the ETag means upon PUT). Best regards, Julian 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 E370D7F67B for ; Mon, 19 Dec 2005 06:18:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D63371422C5 for ; Mon, 19 Dec 2005 06:18:43 -0800 (PST) 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 17755-09 for ; Mon, 19 Dec 2005 06:18:43 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by laweleka.osafoundation.org (Postfix) with ESMTP id 880F71422A8 for ; Mon, 19 Dec 2005 06:18:43 -0800 (PST) Received: by zproxy.gmail.com with SMTP id m7so2308173nzf for ; Mon, 19 Dec 2005 06:18:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YB0wRdQQmF34smr3N9WLDPEoxlXs+ZVxc2Hf7TU+ODH+J82PEwAgzBrLVoPySE48RyQw7SlONVhQgDWTS1FXGB948af11wMGIrnaCSAYxWf6qooKV6U/rj3hcUn8L/xw0YKbw4OxrJxhWq4JmVoY3svjFcVn/p9mT5/tSuqGk/Y= Received: by 10.65.116.16 with SMTP id t16mr3047586qbm; Mon, 19 Dec 2005 06:18:42 -0800 (PST) Received: by 10.65.135.14 with HTTP; Mon, 19 Dec 2005 06:18:42 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 09:18:42 -0500 From: Mike Shaver To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <43A6BE44.9080608@adevsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> <43A6B4E3.2010700@gmx.de> <43A6BE44.9080608@adevsoft.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 14:18:44 -0000 On 12/19/05, Kervin L. Pierre wrote: > Or the client could assume that what it > sent is not necessarily what the server > will store, and that the ETag pertains > to what was stored? Why won't that > option work? What good does that do the client? It can't use that ETag in the future to know if it needs an update, because it don't know what data is signified by that ETag, right? Mike 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 5D06D7F67D for ; Mon, 19 Dec 2005 06:05:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 548B11422C5 for ; Mon, 19 Dec 2005 06:05:28 -0800 (PST) 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 10328-01 for ; Mon, 19 Dec 2005 06:05:28 -0800 (PST) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by laweleka.osafoundation.org (Postfix) with SMTP id D534B1422A8 for ; Mon, 19 Dec 2005 06:05:27 -0800 (PST) Received: (qmail 1299 invoked from network); 19 Dec 2005 14:05:27 -0000 Received: from unknown (HELO ?192.168.0.70?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 19 Dec 2005 14:05:27 -0000 Message-ID: <43A6BE44.9080608@adevsoft.com> Date: Mon, 19 Dec 2005 09:05:56 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> <43A6B4E3.2010700@gmx.de> In-Reply-To: <43A6B4E3.2010700@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 14:05:28 -0000 Julian Reschke wrote: > That is, CalDAV will need to figure out how servers can use strong ETags > and still rewrite the content. > Or the client could assume that what it sent is not necessarily what the server will store, and that the ETag pertains to what was stored? Why won't that option work? Best Regards, Kervin 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 D425F7F659 for ; Mon, 19 Dec 2005 05:27:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFC031422CA for ; Mon, 19 Dec 2005 05:27:27 -0800 (PST) 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 13289-02 for ; Mon, 19 Dec 2005 05:27:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 1E5181422C5 for ; Mon, 19 Dec 2005 05:27:26 -0800 (PST) Received: (qmail invoked by alias); 19 Dec 2005 13:27:24 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 19 Dec 2005 14:27:24 +0100 X-Authenticated: #1915285 Message-ID: <43A6B4E3.2010700@gmx.de> Date: Mon, 19 Dec 2005 14:25:55 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> In-Reply-To: <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 13:27:27 -0000 Helge Hess wrote: > On 19. Dez 2005, at 13:57 Uhr, Julian Reschke wrote: >>> So far I've usually implemented etags as markers for content which is >>> "semantically" equivalent. Which of course is wrong if you implement >>> HTTP strictly. In practice it works well _for me_ since clients >>> usually do no range requests on calendar items and those would be the >>> only case where verbatim representation matters? >> Right. So why don't you use weak etags? > > Because > > "The weak comparison function can only be used with GET or HEAD requests" Right. Thanks. > But I actually need etags to ensure consistent updates. This could be > worked around by using LOCKs, but then those would need to be a MUST for > CalDAV servers ... That is, CalDAV will need to figure out how servers can use strong ETags and still rewrite the content. >>> Sidenote: what about returning the server side content in the PUT >>> response if it changed, 201 + etag if it stayed the same and 200 + >>> etag + content if it wasn't stored verbatim by the server. Might be >>> an OK workaround? >> Well, you can't use 201 here, unless the resource is new. > > Right. A 204 (No Content) would be OK for existing items? I would think so. >> Using the response body for PUT may work, but it may cause unnecessary >> traffic for those clients that do not care. > > Only in the case when the server actually changed the entity. And if the > client doesn't care, it can just stop reading the response content and > quite after a 200? But then it will have to close the connection, and the server will get an IO error... Best regards, Julian 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 869E87F65F for ; Mon, 19 Dec 2005 05:12:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 838E81422CD for ; Mon, 19 Dec 2005 05:12:51 -0800 (PST) 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 11624-01 for ; Mon, 19 Dec 2005 05:12:51 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by laweleka.osafoundation.org (Postfix) with ESMTP id 01E6B1422B0 for ; Mon, 19 Dec 2005 05:12:50 -0800 (PST) Received: by zproxy.gmail.com with SMTP id m7so2280963nzf for ; Mon, 19 Dec 2005 05:12:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NapaKR1bbxoxc27aWbYTRuQKO2O/MOI2QyvisgjlcqdMzurTq5wkNb2qLXYUTJd8EguSFVXFM9HEpCYXyuyx7CRrXQRveH9nvLV1fdsc72bUUHzuNcGTdkvYwRG6fGHahtEkSsg/6DswNfXaHTX4KhLpwhpndCHLR90i7kPwH/0= Received: by 10.65.132.20 with SMTP id j20mr2955380qbn; Mon, 19 Dec 2005 05:12:49 -0800 (PST) Received: by 10.65.135.14 with HTTP; Mon, 19 Dec 2005 05:12:49 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 08:12:49 -0500 From: Mike Shaver To: douglm@rpi.edu Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: 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: Mon, 19 Dec 2005 13:12:51 -0000 On 12/19/05, douglm@rpi.edu wrote: > MS used this field (I think to deal with groups in some way) then > required anybody who wanted to interface to a windows domain to sign > their souls away to gain access to the secrets. They still advertised > themselves as using kerberos but it was unusable to anybody else. > > If being interoperable also implies supporting any random x-attrubute you > want to throw at a server then we're open to the same thing. Open to the same what thing? Someone layering semantics on top of a standard protocol and requiring those semantics be honoured for the interaction to proceed? We can't _not_ be open to that; EvilCalendarCo can require that the SUMMARY contain some magic value that "requires" a license to compute. It's a battle that's already lost, and we should focus on making CalDAV useful for people who want to interoperate; people who don't want to interoperate already have tons of choices, and I don't think that we have the ability to deny them "the CalDAV Mark" even if we decided that we wanted to police such things. But what we're talking about here is _preserving_ arbitrary X-attributes, not _providing_ or _manipulating_ or _interpreting_ them. > If the main point of caldav is being interoperable then we shouldn't > allow something which extends caldav to be called caldav - sun didn't > even let ms get away with java+. > As a server impelementor I don't like the idea of being open to anything > clients want to send to me in the guise of an x attribute. It can be > surprising to those who haven't seen it how quickly students figure out > they can use the calendar as an image repository Why wouldn't they just use VATTACHMENT or SUMMARY? If you want a size-limiting capability, then let's talk about that.=20 CAP provides a mechanism for restricting size, and IMIP has one implicitly from its SMTP transport. A pair of "component too large" and "property too large" error codes would be fine, and then we wouldn't have to pretend that X-PROPERTIES are special in this regard. Want to start another thread on that? > I'm open to the idea of extensions but I'd like to see an extension > mechanism defined so I have a chance of understanding what's coming. I've > suggested before (not here) some kind of profile mechanism which would > allow cooperating clients/servers to advertise/ask for support for > specific extensions. That way we could have the mozilla profile, the hula > profile, the skical profile and anything outside of what we support we > reject as experimental (unless we are feeling experimental) If you have a different profile per client or server, why bother with a standard? We're not doing anything here but stating as a requirement that servers maintain properties that we _know_ to be used by existing iCalendar clients to preserve application-specific state when interoperating with other iCalendar stores and manipulators. The extension mechanism here _is_ defined, as I understand it, by iCalendar, and it seems to work as well as anything else in that standard. Mike 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 159B47F638 for ; Mon, 19 Dec 2005 05:09:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 133DE1422CD for ; Mon, 19 Dec 2005 05:09:45 -0800 (PST) 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 18400-06 for ; Mon, 19 Dec 2005 05:09:44 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 79F751422B0 for ; Mon, 19 Dec 2005 05:09:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1F31735A9F5; Mon, 19 Dec 2005 14:00:42 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 9652835AC64; Mon, 19 Dec 2005 14:00:41 +0100 (CET) In-Reply-To: <43A6AE31.7060408@gmx.de> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> <43A6AE31.7060408@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24370A96-AA2D-4896-8666-81DF4C8ABE74@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Mon, 19 Dec 2005 14:09:42 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 13:09:45 -0000 On 19. Dez 2005, at 13:57 Uhr, Julian Reschke wrote: >> So far I've usually implemented etags as markers for content which >> is "semantically" equivalent. Which of course is wrong if you >> implement HTTP strictly. In practice it works well _for me_ since >> clients usually do no range requests on calendar items and those >> would be the only case where verbatim representation matters? > Right. So why don't you use weak etags? Because "The weak comparison function can only be used with GET or HEAD requests" But I actually need etags to ensure consistent updates. This could be worked around by using LOCKs, but then those would need to be a MUST for CalDAV servers ... >> Sidenote: what about returning the server side content in the PUT >> response if it changed, 201 + etag if it stayed the same and 200 + >> etag + content if it wasn't stored verbatim by the server. Might >> be an OK workaround? > Well, you can't use 201 here, unless the resource is new. Right. A 204 (No Content) would be OK for existing items? > Using the response body for PUT may work, but it may cause > unnecessary traffic for those clients that do not care. Only in the case when the server actually changed the entity. And if the client doesn't care, it can just stop reading the response content and quite after a 200? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 3763B7F65A for ; Mon, 19 Dec 2005 05:00:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33CC91422CE for ; Mon, 19 Dec 2005 05:00:54 -0800 (PST) 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 23920-08 for ; Mon, 19 Dec 2005 05:00:53 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 90F591422CD for ; Mon, 19 Dec 2005 05:00:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id DF82635B78F for ; Mon, 19 Dec 2005 13:51:50 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 477D935A78D for ; Mon, 19 Dec 2005 13:51:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> References: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49759DF7-32A5-418E-9343-A08AB13A981F@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Mon, 19 Dec 2005 14:00:50 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Mon, 19 Dec 2005 13:00:54 -0000 On 19. Dez 2005, at 06:34 Uhr, douglm@rpi.edu wrote: > We should be able to state quite explicitly the requirements for > interoperability. There was plenty of discussion on that now and honestly I think further discussion will lead to nowhere, everyone has stated his opinion. So far everyone seems to have a different opinion on that and I have the impression that the topic will just get "dropped" as unresolvable? Or is there some way to vote on the issue in a useful way? In response to the valid issues raised by Julian (and others) I think I've changed my opinion to: - CalDAV servers are required to store verbatim copies - PROPPATCH is a SHOULD just like in WebDAV Why? Because HTTP/WebDAV is designed with that assumption in mind and it keeps the CalDAV protocol clean. If a server doesn't comply with all strict requirements of CalDAV it is very likely to work with real world clients nevertheless. But to be fully-CalDAV compliant, it would need to work exactly as described in the spec. This is how it works in the real-world for WebDAV. Few do 100% correct implementations but still interoperability is quite good. > at least we can still see the events and invite people to our > meetings and surely that's the main point. For inviting people to our meetings we can already use iMIP. IMHO the main point of CalDAV is to provide a client/server calendar _storage_ protocol. And if most/all clients will need an _additional_ storage to save their "own" stuff, this would be extremely annoying. Eg if our Outlook storage provider can't store additional Outlook information in X- fields there is no other way but to require the user to enter a CalDAV URL _and_ another URL where additional data will get stored. Then it will also need to keep those in-sync. Major bummer ... Greets, Helge PS: this "abuse" subthread is IMHO indeed paranoid. M$ will modify/ call a mixup derivate CalDAV whenever they like, this isn't bound to any specific feature in CalDAV. (Windows WebFolders is a prime example ...) -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 AF3017F656 for ; Mon, 19 Dec 2005 04:58:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A22301422CE for ; Mon, 19 Dec 2005 04:58:53 -0800 (PST) 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 15345-08 for ; Mon, 19 Dec 2005 04:58:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id DB3DC1422CD for ; Mon, 19 Dec 2005 04:58:52 -0800 (PST) Received: (qmail invoked by alias); 19 Dec 2005 12:58:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp018) with SMTP; 19 Dec 2005 13:58:50 +0100 X-Authenticated: #1915285 Message-ID: <43A6AE31.7060408@gmx.de> Date: Mon, 19 Dec 2005 13:57:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Mon, 19 Dec 2005 12:58:53 -0000 Helge Hess wrote: >> Hm. >> >> If it did that, and the server would return the ETag as described >> above (representing the entity that the client would get upon GET), >> then doing that refetch wouldn't help at all (because by definition >> the result would be a 304). >> >> If the client really needs to know the exact octet stream he'd get, >> there's no way to avoid GETting the resource. On the other hand, why >> exactly would the client care unless it's going to use GET with Range >> request headers? > > Another very good point :-) I think many might not be aware that etags > require an exact octet representation and I tend to forget that myself ... > > The implication of this is that we cannot use etags in clients except > with servers which actually store verbatim copies. Hm, not good?! Or > maybe it is good and just puts more restrictions on the server (to store > verbatim-copies), this would also render the whole x- discussion void. > > So far I've usually implemented etags as markers for content which is > "semantically" equivalent. Which of course is wrong if you implement > HTTP strictly. In practice it works well _for me_ since clients usually > do no range requests on calendar items and those would be the only case > where verbatim representation matters? Right. So why don't you use weak etags? > Sidenote: what about returning the server side content in the PUT > response if it changed, 201 + etag if it stayed the same and 200 + etag > + content if it wasn't stored verbatim by the server. Might be an OK > workaround? Well, you can't use 201 here, unless the resource is new. Using the response body for PUT may work, but it may cause unnecessary traffic for those clients that do not care. Best regards, Julian 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 188577F630 for ; Mon, 19 Dec 2005 04:47:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 000631422CD for ; Mon, 19 Dec 2005 04:47:08 -0800 (PST) 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 09629-08 for ; Mon, 19 Dec 2005 04:47:08 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 55DC91422CA for ; Mon, 19 Dec 2005 04:47:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A556135B53B for ; Mon, 19 Dec 2005 13:38:05 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 4D65935B4FF for ; Mon, 19 Dec 2005 13:38:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43A58C26.2070201@gmx.de> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> <43A58C26.2070201@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Mon, 19 Dec 2005 13:47:05 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Mon, 19 Dec 2005 12:47:09 -0000 On 18. Dez 2005, at 17:19 Uhr, Julian Reschke wrote: > Helge Hess wrote: >> On 18. Dez 2005, at 17:01 Uhr, Julian Reschke wrote: >>> This is a known specification issue: it's rather silent what it >>> means to return an ETag upon PUT. You seem to think it's for the >>> entity the client sent in the PUT request (this is what I thought >>> as well), while many people on the HTTP mailing list think it's >>> the ETag you would get upon a subsequent GET >> You are right. >> And yes, it reduces the issue. But still the implication is that >> an HTTP client MUST perform an immediate GET after the operation, >> eg with an if-match: put-result-etag. Otherwise there is no way to >> know the state the etag refers too and subsequent updates will be >> done based on incorrect assumptions? > > Hm. > > If it did that, and the server would return the ETag as described > above (representing the entity that the client would get upon GET), > then doing that refetch wouldn't help at all (because by definition > the result would be a 304). > > If the client really needs to know the exact octet stream he'd get, > there's no way to avoid GETting the resource. On the other hand, > why exactly would the client care unless it's going to use GET with > Range request headers? Another very good point :-) I think many might not be aware that etags require an exact octet representation and I tend to forget that myself ... The implication of this is that we cannot use etags in clients except with servers which actually store verbatim copies. Hm, not good?! Or maybe it is good and just puts more restrictions on the server (to store verbatim-copies), this would also render the whole x- discussion void. So far I've usually implemented etags as markers for content which is "semantically" equivalent. Which of course is wrong if you implement HTTP strictly. In practice it works well _for me_ since clients usually do no range requests on calendar items and those would be the only case where verbatim representation matters? Sidenote: what about returning the server side content in the PUT response if it changed, 201 + etag if it stayed the same and 200 + etag + content if it wasn't stored verbatim by the server. Might be an OK workaround? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 95F7B7F624 for ; Sun, 18 Dec 2005 22:24:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85E2B1422BE for ; Sun, 18 Dec 2005 22:24:50 -0800 (PST) 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 01393-10 for ; Sun, 18 Dec 2005 22:24:50 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 35706142293 for ; Sun, 18 Dec 2005 22:24:50 -0800 (PST) Received: from smtp2.server.rpi.edu (localhost.localdomain [127.0.0.1]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jBJ6Omj8022097 for ; Mon, 19 Dec 2005 01:24:49 -0500 Received: (from defang@localhost) by smtp2.server.rpi.edu (8.13.0/8.13.0/Submit) id jBJ6OEOI022030 for ; Mon, 19 Dec 2005 01:24:14 -0500 Message-Id: <200512190624.jBJ6OEOI022030@smtp2.server.rpi.edu> Received: from localhost.localdomain (webmail1.server.rpi.edu [128.113.2.131]) by smtp2.server.rpi.edu (envelope-sender ) (MIMEDefang) with ESMTP id jBJ6OEg7022026; Mon, 19 Dec 2005 01:24:14 -0500 (EST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Originating-Ip: 72.224.113.204 X-Http_host: webmail.rpi.edu Date: Mon, 19 Dec 2005 1:24:14 -0500 MIME-Version: 1.0 Organization: Rensselaer Polytechnic Institute Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders X-Mailer: EMUmail 6.0.1.19 From: douglm@rpi.edu X-Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 X-Webmail-User: douglm@imap.server.rpi.edu To: douglm@rpi.edu X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO, MSGID_FROM_MTA_HEADER, NO_REAL_NAME, URI_REDIRECTOR X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: douglm@rpi.edu List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 06:24:50 -0000 That should have been http://www.networkworld.com/news/2000/0511kerberos.html http://news.com.com/2100-1001-240422.html (webmail ate my lfs) ==============Original message text=============== On Mon, 19 Dec 2005 0:34:53 EST douglm@rpi.edu wrote: http://www.networkworld.com/news/2000/0511kerberos.htmlhttp://news.com.com/2100-1001-240422.html... 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 94AE17F630 for ; Sun, 18 Dec 2005 21:34:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A8421422C2 for ; Sun, 18 Dec 2005 21:34:57 -0800 (PST) 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 14051-02 for ; Sun, 18 Dec 2005 21:34:57 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1918A1422C1 for ; Sun, 18 Dec 2005 21:34:57 -0800 (PST) Received: from localhost.localdomain (webmail1.server.rpi.edu [128.113.2.131]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jBJ5YrWm026078 for ; Mon, 19 Dec 2005 00:34:53 -0500 Message-Id: <200512190534.jBJ5YrWm026078@smtp4.server.rpi.edu> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Originating-Ip: 72.224.113.204 X-Http_host: webmail.rpi.edu Date: Mon, 19 Dec 2005 0:34:53 -0500 MIME-Version: 1.0 Organization: Rensselaer Polytechnic Institute Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders X-Mailer: EMUmail 6.0.1.19 From: douglm@rpi.edu X-Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 X-Webmail-User: douglm@imap.server.rpi.edu To: ietf-caldav@osafoundation.org X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO, NO_REAL_NAME, URI_REDIRECTOR X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: douglm@rpi.edu List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 05:34:57 -0000 http://www.networkworld.com/news/2000/0511kerberos.htmlhttp://news.com.com/2100-1001-240422.html Sort of old news but there is a vendor field defined in Kerberos for vendor specific features. MS used this field (I think to deal with groups in some way) then required anybody who wanted to interface to a windows domain to sign their souls away to gain access to the secrets. They still advertised themselves as using kerberos but it was unusable to anybody else. If being interoperable also implies supporting any random x-attrubute you want to throw at a server then we're open to the same thing. If the main point of caldav is being interoperable then we shouldn't allow something which extends caldav to be called caldav - sun didn't even let ms get away with java+. We should be able to state quite explicitly the requirements for interoperability. It might not allow all the fancy bits some client people want to drop in our servers but at least we can still see the events and invite people to our meetings and surely that's the main point. That doesn't stop people modifying servers or finding cooperative servers to try new stuff. And if it's good enough people will want to adopt it. But I don't think I want people experimenting with my production system. As a server impelementor I don't like the idea of being open to anything clients want to send to me in the guise of an x attribute. It can be surprising to those who haven't seen it how quickly students figure out they can use the calendar as an image repository I'm open to the idea of extensions but I'd like to see an extension mechanism defined so I have a chance of understanding what's coming. I've suggested before (not here) some kind of profile mechanism which would allow cooperating clients/servers to advertise/ask for support for specific extensions. That way we could have the mozilla profile, the hula profile, the skical profile and anything outside of what we support we reject as experimental (unless we are feeling experimental) It should be fairly easy to define a way to specify what the extensions are: their names; their types; etc. ==============Original message text=============== On Sun, 18 Dec 2005 10:13:41 EST Helge Hess wrote: On 16. Dez 2005, at 16:15 Uhr, Mike Douglass wrote: > Am I being paranoid or does this open the way for vendor x to > develop proprietary licenced extensions to caldav? Is it possible to license a protocol? What do you have in mind here (what kind of extension to CalDAV?) Greets, Helge -- http://docs.opengroupware.org/Members/helge/OpenGroupware.org ===========End of original message text=========== 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 A57107F6DD for ; Sun, 18 Dec 2005 08:21:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9667D1422B2 for ; Sun, 18 Dec 2005 08:21:29 -0800 (PST) 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 09915-02 for ; Sun, 18 Dec 2005 08:21:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id DD2401422B1 for ; Sun, 18 Dec 2005 08:21:28 -0800 (PST) Received: (qmail invoked by alias); 18 Dec 2005 16:21:27 -0000 Received: from p508F8112.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.18] by mail.gmx.net (mp036) with SMTP; 18 Dec 2005 17:21:27 +0100 X-Authenticated: #1915285 Message-ID: <43A58C26.2070201@gmx.de> Date: Sun, 18 Dec 2005 17:19:50 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> In-Reply-To: <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Sun, 18 Dec 2005 16:21:29 -0000 Helge Hess wrote: > On 18. Dez 2005, at 17:01 Uhr, Julian Reschke wrote: >> This is a known specification issue: it's rather silent what it means >> to return an ETag upon PUT. You seem to think it's for the entity the >> client sent in the PUT request (this is what I thought as well), while >> many people on the HTTP mailing list think it's the ETag you would get >> upon a subsequent GET > > You are right. > > And yes, it reduces the issue. But still the implication is that an HTTP > client MUST perform an immediate GET after the operation, eg with an > if-match: put-result-etag. Otherwise there is no way to know the state > the etag refers too and subsequent updates will be done based on > incorrect assumptions? Hm. If it did that, and the server would return the ETag as described above (representing the entity that the client would get upon GET), then doing that refetch wouldn't help at all (because by definition the result would be a 304). If the client really needs to know the exact octet stream he'd get, there's no way to avoid GETting the resource. On the other hand, why exactly would the client care unless it's going to use GET with Range request headers? Best regards, Julian 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 CA3347F6B6 for ; Sun, 18 Dec 2005 08:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BB67D1422AD for ; Sun, 18 Dec 2005 08:15:00 -0800 (PST) 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 09328-01 for ; Sun, 18 Dec 2005 08:15:00 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B07614229D for ; Sun, 18 Dec 2005 08:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3E0CE35B01C; Sun, 18 Dec 2005 17:06:19 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id D8FC335A794; Sun, 18 Dec 2005 17:06:18 +0100 (CET) In-Reply-To: <43A587D8.6050803@gmx.de> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> <43A587D8.6050803@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84D27BF7-E0BB-42E1-B12E-45D7798CC957@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Sun, 18 Dec 2005 17:14:58 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Sun, 18 Dec 2005 16:15:02 -0000 On 18. Dez 2005, at 17:01 Uhr, Julian Reschke wrote: > This is a known specification issue: it's rather silent what it > means to return an ETag upon PUT. You seem to think it's for the > entity the client sent in the PUT request (this is what I thought > as well), while many people on the HTTP mailing list think it's the > ETag you would get upon a subsequent GET You are right. And yes, it reduces the issue. But still the implication is that an HTTP client MUST perform an immediate GET after the operation, eg with an if-match: put-result-etag. Otherwise there is no way to know the state the etag refers too and subsequent updates will be done based on incorrect assumptions? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 BC7097F70C for ; Sun, 18 Dec 2005 08:03:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA6AA1422AD for ; Sun, 18 Dec 2005 08:03:07 -0800 (PST) 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 07327-04 for ; Sun, 18 Dec 2005 08:03:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id E76361422A9 for ; Sun, 18 Dec 2005 08:03:06 -0800 (PST) Received: (qmail invoked by alias); 18 Dec 2005 16:03:05 -0000 Received: from p508F8112.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.18] by mail.gmx.net (mp017) with SMTP; 18 Dec 2005 17:03:05 +0100 X-Authenticated: #1915285 Message-ID: <43A587D8.6050803@gmx.de> Date: Sun, 18 Dec 2005 17:01:28 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> In-Reply-To: <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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: Sun, 18 Dec 2005 16:03:07 -0000 Helge Hess wrote: > On 16. Dez 2005, at 19:52 Uhr, Wilfredo Sánchez Vega wrote: >> If you say that a server MUST not modify X- properties then you are >> removing the flexibility on the server side that you are requesting on >> the client side. > > It must not delete/touch unknown X- properties, it might modify the set > of X- properties or change X- properties it knows. This doesn't limit > the flexibility on the server side. > > But it has serious consequences if you choose to do any change to > PUT'ted entities on the server side. Every subsequent consistent-update > [etag] request must fail as per HTTP (even if the change is just a > result of the PUT issued by the client). > > Eg a client would show an "someone has changed your item in the server" > warning / conflict resolution panel prior submitting _any_ next request. > In short: if you want to allow server-side modifications, you should > specify that a client MUST immediatly reget the entity after a > change/creation request. This is a known specification issue: it's rather silent what it means to return an ETag upon PUT. You seem to think it's for the entity the client sent in the PUT request (this is what I thought as well), while many people on the HTTP mailing list think it's the ETag you would get upon a subsequent GET (see discussion at ). I think this question needs to be clarified (by an agreed-upon erratum to be included into before WebDAV or related specs are going to make normative statements about this). > ... Best regards, Julian 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 2AFCB7F6F6 for ; Sun, 18 Dec 2005 07:52:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1EB771422AD for ; Sun, 18 Dec 2005 07:52:16 -0800 (PST) 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 00691-04 for ; Sun, 18 Dec 2005 07:52:15 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 760EA1422A9 for ; Sun, 18 Dec 2005 07:52:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 7C29E35BB02 for ; Sun, 18 Dec 2005 16:43:33 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 2319635BBA3 for ; Sun, 18 Dec 2005 16:43:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6FFE4DAB-19A8-4C8C-B33E-08D8108E40EB@opengroupware.org> Content-Transfer-Encoding: quoted-printable From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Sun, 18 Dec 2005 16:52:10 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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: Sun, 18 Dec 2005 15:52:16 -0000 On 16. Dez 2005, at 19:52 Uhr, Wilfredo S=E1nchez Vega wrote: > If you say that a server MUST not modify X- properties then you are =20= > removing the flexibility on the server side that you are requesting =20= > on the client side. It must not delete/touch unknown X- properties, it might modify the =20 set of X- properties or change X- properties it knows. This doesn't =20 limit the flexibility on the server side. But it has serious consequences if you choose to do any change to =20 PUT'ted entities on the server side. Every subsequent consistent-=20 update [etag] request must fail as per HTTP (even if the change is =20 just a result of the PUT issued by the client). Eg a client would show an "someone has changed your item in the =20 server" warning / conflict resolution panel prior submitting _any_ =20 next request. In short: if you want to allow server-side =20 modifications, you should specify that a client MUST immediatly reget =20= the entity after a change/creation request. > A server might, for example, want to define some of its own X- =20 > properties, or interact with a client or with another server =20 > through X- properties in a way that involves updating a property =20 > that the client originally set. Sure. Exactly the same restriction of the server applies to the =20 client. It must not modify/delete unknown X- properties and preserve =20 them in the next update operation. (This already works fine with Kontact and Evolution) Greets, Helge --=20 http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 335247F76F for ; Sat, 17 Dec 2005 14:45:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 283141422BE for ; Sat, 17 Dec 2005 14:45:57 -0800 (PST) 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 00308-04 for ; Sat, 17 Dec 2005 14:45:56 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by laweleka.osafoundation.org (Postfix) with ESMTP id B26AF1422B6 for ; Sat, 17 Dec 2005 14:45:56 -0800 (PST) Received: by wproxy.gmail.com with SMTP id 70so831574wra for ; Sat, 17 Dec 2005 14:45:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ikfQwzDlXPs6H9rhwOK7xopnxVy2U3Rq7GKTeICQhd2Cr96TeWoBQmM8XGIAz1vk8Jkpg+CIdJVtjYK3mgVMA5aG91L4RTWDcf0F9J+EM/mUTHipJ/EtAzEDn/V9qJk13n4f/CiGfmQyXRlkn8rFqJrhIT3EPHHl4HKakdOC3is= Received: by 10.65.141.7 with SMTP id t7mr3400127qbn; Sat, 17 Dec 2005 14:45:55 -0800 (PST) Received: by 10.65.135.14 with HTTP; Sat, 17 Dec 2005 14:45:55 -0800 (PST) Message-ID: Date: Sat, 17 Dec 2005 17:45:55 -0500 From: Mike Shaver To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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: Sat, 17 Dec 2005 22:45:57 -0000 On 12/16/05, Wilfredo S=E1nchez Vega wrote: > If you say that a server MUST not modify X- properties then you > are removing the flexibility on the server side that you are > requesting on the client side. A server might, for example, want to > define some of its own X- properties, or interact with a client or > with another server through X- properties in a way that involves > updating a property that the client originally set. What I'm really saying is that it MUST not modify unknown X- properties. If it "knows about" them, then it can obviously modify them -- that's really what they're for. And I would expect that a client MUST round-trip X- properties that are found on what it gets back from the server. > A server author might also decide that X-MOZILLA-GIANT-TURD > contains no data useful to the application at hand and is willing to > lose some user functionality in Mozzila in order to save server > resources. A server author might also decide that about attachments and timezone data, both of which are more likely to consume server resources than some random X-PROP, IMO. I'll happily admit that I think the X-PROPERTY support is more useful than most of the alarm functionality, in a shared-calendar environment. It turns out that any server implementor can work around even the strongest MUST, as long as they are allowed to delete or create events without the explicit action of a given client: they can delete the event and create a new, identical-but-for-X-MOZILLA-WORLD-PEACE event. (Probably in that order to avoid duplicate-ID issues, though the operation could be atomic as seen by clients, and therefore can benefit from an implementation optimization that simply mutates the first event. :) ) > Obviously, I'm making up stuff, but let's not assume that we know > what either client or server authors will need to be able to do in > the future. Indeed not, which is why I think it's important to preserve the reliability of a key iCalendar extension mechanism. Are there _any_ iCalendar-using clients that don't produce (and consume) their own X-WHATEVERs, for tracking things like sync versions, event colouration, or such? I would be surprised, though that's happened before with calendaring technology. Mike 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 A98917F7CE for ; Fri, 16 Dec 2005 12:43:43 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4495E1422A5; Fri, 16 Dec 2005 12:43:43 -0800 (PST) In-Reply-To: <43A32499.2020604@adevsoft.com> References: <4341DC51.4050401@oracle.com> <4341DE3B.8050204@osafoundation.org> <4341F2D4.1000503@oracle.com> <43A32499.2020604@adevsoft.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <088d48fd047acb92e280b68d3fca7e9c@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt] Date: Fri, 16 Dec 2005 12:43:41 -0800 To: "Kervin L. Pierre" X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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: Fri, 16 Dec 2005 20:43:43 -0000 On Dec 16, 2005, at 12:33 PM, Kervin L. Pierre wrote: > Bernard Desruisseaux wrote: > >> Note that principal resources still have a CALDAV:calendar-home-set >> property. > > The client may not have the principal's URL. And also, > 'calendar-home-set' looks like a SHOULD. It should be pretty easy to get the principal's URL from the owner property on the collection. (not that this answer addresses everything in your question, just the part about having the owner's principal URL) Lisa 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 83DFA7F7C5; Fri, 16 Dec 2005 12:33:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 879BE142302; Fri, 16 Dec 2005 12:33:08 -0800 (PST) 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 28673-09; Fri, 16 Dec 2005 12:33:08 -0800 (PST) Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 460AE1422FB; Fri, 16 Dec 2005 12:33:08 -0800 (PST) Received: from rrcs-24-227-116-130.se.biz.rr.com ([24.227.116.130]:18560 helo=[10.55.10.51]) by svr59.edns1.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EnMGE-0008FP-Mq; Fri, 16 Dec 2005 12:33:02 -0800 Message-ID: <43A32499.2020604@adevsoft.com> Date: Fri, 16 Dec 2005 15:33:29 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-08.txt] References: <4341DC51.4050401@oracle.com> <4341DE3B.8050204@osafoundation.org> <4341F2D4.1000503@oracle.com> In-Reply-To: <4341F2D4.1000503@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HELO-Warning: Remote host 24.227.116.130 (rrcs-24-227-116-130.se.biz.rr.com) incorrectly presented itself as [10.55.10.51] X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Fri, 16 Dec 2005 20:33:08 -0000 Bernard Desruisseaux wrote: > >> d. Removed resource type CALDAV:calendar-home. > > > > > > why? > > We could not justify a new resource type for calendar home. > It may be useful for the CalDAV client to differentiate between a calendar and a calendar home. Both types of collections can ( as far as I know ) advertise 'calendar' and 'collection' in their resourcetype property, so the client can not use that. We could try MKCALENDAR support but that's optional. > figured that CalDAV clients willing to browse a CalDAV server to > find calendar data would simply look for collections with the > CALDAV:calendar resource type... > It seems that Oracle CalDAV server is adverting 'calendar' in resourcetype of its 'calendar home' collection. Is that not allowed? > Note that principal resources still have a CALDAV:calendar-home-set > property. > The client may not have the principal's URL. And also, 'calendar-home-set' looks like a SHOULD. PS. Please CC me in responses Best Regards, Kervin 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 4D0847F7C7 for ; Fri, 16 Dec 2005 11:09:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4917B142310 for ; Fri, 16 Dec 2005 11:09:00 -0800 (PST) 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 20681-07 for ; Fri, 16 Dec 2005 11:08:59 -0800 (PST) Received: from S3.cableone.net (s3.cableone.net [24.116.0.229]) by laweleka.osafoundation.org (Postfix) with ESMTP id D1EAC14230D for ; Fri, 16 Dec 2005 11:08:59 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S3.cableone.net (CableOne SMTP Service S3) with ESMTP id 40313055 for ; Fri, 16 Dec 2005 12:28:13 -0700 Message-ID: <43A310CA.3060505@Royer.com> Date: Fri, 16 Dec 2005 12:08:58 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> In-Reply-To: <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> Content-Type: multipart/mixed; boundary="------------030706010709070102030805" X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 1, First 126, in=266, out=221, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2005 19:09:00 -0000 This is a multi-part message in MIME format. --------------030706010709070102030805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If a vendor wishes to use its own properties, it should go through the registration process and avoid these conflicts; A server written in 2005 can not already know about a component, property, or parameter registered in 2006. If a server does not allows for unknown objects, then there better be some kind of capability support built into the server so the client can tell if it can use each server on each initial connection. A guiding purpose of CALDAV is that you can mix clients and servers - interoperability. If a client adds X-MOZILLA-EVENT-COLOUR the user will expect it to work when the REQUEST get forwarded to other users. It should be up to the client documentation to somehow inform the user which non-registered features the client uses. Users will expect COLOR or any other property to work across vendors. And users often do not read the RFCs. I think that it needs to be a SHOULD for X- objects, as that may be the only way to resolve X-NAME usage conflicts. I think that unknown NON-'X-' objects should be a MUST, as they may be registered the month after a server is released and CUAs would then have the right to use them. Wilfredo S=E1nchez Vega wrote: > These are valid points, but I think this warrants a SHOULD in the =20 > same vain as WebDAV's suggestion on dead props. >=20 > If you say that a server MUST not modify X- properties then you are = > removing the flexibility on the server side that you are requesting on= =20 > the client side. A server might, for example, want to define some of = > its own X- properties, or interact with a client or with another serve= r=20 > through X- properties in a way that involves updating a property that = > the client originally set. >=20 > A server author might also decide that X-MOZILLA-GIANT-TURD contains= =20 > no data useful to the application at hand and is willing to lose some = > user functionality in Mozzila in order to save server resources. >=20 > Obviously, I'm making up stuff, but let's not assume that we know =20 > what either client or server authors will need to be able to do in the= =20 > future. >=20 > -wsv >=20 --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030706010709070102030805 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------030706010709070102030805-- 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 C8DA97F777 for ; Fri, 16 Dec 2005 10:57:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C440C142310 for ; Fri, 16 Dec 2005 10:57:12 -0800 (PST) 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 01604-04; Fri, 16 Dec 2005 10:57:12 -0800 (PST) Received: from [192.168.101.23] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DF1D1422B7; Fri, 16 Dec 2005 10:57:12 -0800 (PST) Message-ID: <43A30DF8.5060407@osafoundation.org> Date: Fri, 16 Dec 2005 10:56:56 -0800 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] calendar-home property References: <43A2F794.7060205@adevsoft.com> <43A2FB2F.5070102@osafoundation.org> <865DC978-19EA-45F4-A9FF-0B0D0C392825@apple.com> In-Reply-To: <865DC978-19EA-45F4-A9FF-0B0D0C392825@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Fri, 16 Dec 2005 18:57:12 -0000 Wilfredo Sánchez Vega wrote: > I thought we got rid of the calendar home collection concept, > including the resource type. you're right, that was in draft 08. 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 C0E807F7C7 for ; Fri, 16 Dec 2005 10:52:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B7E041422BF for ; Fri, 16 Dec 2005 10:52:21 -0800 (PST) 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 01949-03 for ; Fri, 16 Dec 2005 10:52:21 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 634CB1422A2 for ; Fri, 16 Dec 2005 10:52:21 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBGIqJTQ007623; Fri, 16 Dec 2005 10:52:19 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id CF9A136F; Fri, 16 Dec 2005 10:52:18 -0800 (PST) In-Reply-To: References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15A4ED4B-A46F-4EC1-BFCF-635E2421ACC5@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Fri, 16 Dec 2005 10:52:18 -0800 To: Mike Shaver X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Fri, 16 Dec 2005 18:52:21 -0000 These are valid points, but I think this warrants a SHOULD in the same vain as WebDAV's suggestion on dead props. If you say that a server MUST not modify X- properties then you are removing the flexibility on the server side that you are requesting on the client side. A server might, for example, want to define some of its own X- properties, or interact with a client or with another server through X- properties in a way that involves updating a property that the client originally set. A server author might also decide that X-MOZILLA-GIANT-TURD contains no data useful to the application at hand and is willing to lose some user functionality in Mozzila in order to save server resources. Obviously, I'm making up stuff, but let's not assume that we know what either client or server authors will need to be able to do in the future. -wsv On Dec 15, 2005, at 9:08 PM, Mike Shaver wrote: > On 12/15/05, Bernard Desruisseaux > wrote: >> You want MUST level requirements to make sure interoperability >> will be >> achieved. It is obvious that are not seeking interoperability when >> you >> start using non-standards components, properties or parameters... > > It's not about semantic interoperability of those properties between > clients, it's about servers (and clients!) doing no harm to incoming > data. I don't expect the Oracle CalDAV server to do anything > interesting with X-MOZILLA-EVENT-COLOUR, but I definitely _do_ expect > that if I put that on an event and then later change the time of that > event, I'll get the same X-MOZILLA-EVENT-COLOUR when I fetch the > changed event. > > I absolutely roll the dice when I make some part of the user > experience depend on my property name not colliding with someone > else's totally different property. And if Kontact were to use > X-MOZILLA-EVENT-COLOUR to store localization data, I'd have no > standards basis for complaining, I suppose. But it turns out that I > can make those dice a pretty safe gamble by picking a good namespace > and trusting my fellow implementors to not be complete dorks about > their similar choices. > > It shouldn't matter if you're a server or a client, you should (and by > "should" I mean MUST if we get a chance to write that language now) do > your utmost to preserve X-PROPERTIES when manipulating an item. I > think that should extend to propagating them from repeating events > into exceptions, etc., but I will readily admit that reasonable people > could disagree about that, and can construct imaginary scenarios in > which that would break existing clients, etc. (Though not existing > CalDAV clients who wouldn't get fixed, I bet! Yay for fresh starts!) > > Mike > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 03A787F787; Fri, 16 Dec 2005 10:41:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E454D14230D; Fri, 16 Dec 2005 10:41:00 -0800 (PST) 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 18167-04; Fri, 16 Dec 2005 10:41:00 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AF9731422A2; Fri, 16 Dec 2005 10:41:00 -0800 (PST) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBGIet66029389; Fri, 16 Dec 2005 10:40:55 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id 734AC3B2; Fri, 16 Dec 2005 10:40:55 -0800 (PST) In-Reply-To: <43A2FB2F.5070102@osafoundation.org> References: <43A2F794.7060205@adevsoft.com> <43A2FB2F.5070102@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <865DC978-19EA-45F4-A9FF-0B0D0C392825@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] calendar-home property Date: Fri, 16 Dec 2005 10:40:54 -0800 To: Brian Moseley X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Fri, 16 Dec 2005 18:41:01 -0000 I thought we got rid of the calendar home collection concept, including the resource type. -wsv On Dec 16, 2005, at 9:36 AM, Brian Moseley wrote: > Kervin L. Pierre wrote: > >> Given the URL of a collection. How should a >> client determine if that collection is a >> calendar home, ie. a collection which may >> contain calendars and the type of collection >> the 'calendar-home-set' property would point >> to or an empty calendar? >> Maybe "calendar homes" ( lack of a better name, >> unless "calendar collection collection" is >> more appropriate ), should have a special >> identifying property or property value. Or >> does it have already? > > check the dav resourcetype property; there's a special value for > calendar home collections there. > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 BA8497F7BB for ; Fri, 16 Dec 2005 09:56:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE8161422FB for ; Fri, 16 Dec 2005 09:56:20 -0800 (PST) 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 32606-02 for ; Fri, 16 Dec 2005 09:56:20 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8660C1422F1 for ; Fri, 16 Dec 2005 09:56:20 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBGHuFnt019999; Fri, 16 Dec 2005 09:56:16 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 2A693324002; Fri, 16 Dec 2005 09:56:15 -0800 (PST) In-Reply-To: <58fd44a97a7998b54a0bbaba2003dc14@opengroupware.org> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <58fd44a97a7998b54a0bbaba2003dc14@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40894863-72A8-4FCF-9760-EFECF01D7333@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 16:04:22 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, DATE_IN_PAST_12_24 X-Spam-Level: Cc: CalDAV DevList 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: Fri, 16 Dec 2005 17:56:20 -0000 Not allowing a client to edit a specific property (or any but a known set of properties) is not equivalent to having no support for PROPPATCH. 501 is not appropriate here, and removing PROPPATCH from OPTIONS is certainly not either. I don't see any reason why we should go down a different patch from WebDAV here. In fact, doing so would put CalDAV out of alignment with WebDAV. -wsv On Dec 15, 2005, at 3:16 PM, Helge Hess wrote: > On Dec 15, 2005, at 22:49, Bernard Desruisseaux wrote: >> If the server is unable to set a given dead property the response >> status of the PROPPATCH request MUST be a 403 (Forbidden). > > If you don't support PROPPATCH I would say you MUST return 501 (not > implemented) and remove PROPPATCH from the OPTIONS allowed header. > > This way the client at least has a chance to discover the fact in > advance instead of being required to deal with per-property errors > (which really only makes sense if the property is a separate, > protected resource [eg for per-user properties]). 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 16E237F79F for ; Fri, 16 Dec 2005 09:36:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1108F1422FB for ; Fri, 16 Dec 2005 09:36:49 -0800 (PST) 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 12653-06; Fri, 16 Dec 2005 09:36:48 -0800 (PST) Received: from [10.0.1.6] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5A4F01422BD; Fri, 16 Dec 2005 09:36:47 -0800 (PST) Message-ID: <43A2FB2F.5070102@osafoundation.org> Date: Fri, 16 Dec 2005 09:36:47 -0800 From: Brian Moseley User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] calendar-home property References: <43A2F794.7060205@adevsoft.com> In-Reply-To: <43A2F794.7060205@adevsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Fri, 16 Dec 2005 17:36:49 -0000 Kervin L. Pierre wrote: > Given the URL of a collection. How should a > client determine if that collection is a > calendar home, ie. a collection which may > contain calendars and the type of collection > the 'calendar-home-set' property would point > to or an empty calendar? > > Maybe "calendar homes" ( lack of a better name, > unless "calendar collection collection" is > more appropriate ), should have a special > identifying property or property value. Or > does it have already? check the dav resourcetype property; there's a special value for calendar home collections there. 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 6D0C57F776 for ; Fri, 16 Dec 2005 09:21:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D7C41422B6 for ; Fri, 16 Dec 2005 09:21:02 -0800 (PST) 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 26708-04 for ; Fri, 16 Dec 2005 09:21:02 -0800 (PST) Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2472F14229B for ; Fri, 16 Dec 2005 09:21:02 -0800 (PST) Received: from [12.8.36.193] (port=2415 helo=[192.168.0.70]) by svr59.edns1.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1EnJGL-0000pY-OZ for ietf-caldav@osafoundation.org; Fri, 16 Dec 2005 09:20:58 -0800 Message-ID: <43A2F794.7060205@adevsoft.com> Date: Fri, 16 Dec 2005 12:21:24 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HELO-Warning: Remote host 12.8.36.193 incorrectly presented itself as [192.168.0.70] X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] calendar-home property 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: Fri, 16 Dec 2005 17:21:02 -0000 Hello, Given the URL of a collection. How should a client determine if that collection is a calendar home, ie. a collection which may contain calendars and the type of collection the 'calendar-home-set' property would point to or an empty calendar? Maybe "calendar homes" ( lack of a better name, unless "calendar collection collection" is more appropriate ), should have a special identifying property or property value. Or does it have already? PS. Please CC me on replies. Best Regards, Kervin 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 230807F794 for ; Thu, 15 Dec 2005 21:08:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08F1A14230A for ; Thu, 15 Dec 2005 21:08:13 -0800 (PST) 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 28268-02 for ; Thu, 15 Dec 2005 21:08:12 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BB5B142309 for ; Thu, 15 Dec 2005 21:08:12 -0800 (PST) Received: by zproxy.gmail.com with SMTP id i11so550826nzh for ; Thu, 15 Dec 2005 21:08:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NfmRcq3+xtfu/DVhJ3Zer5SIOgSHpgf7F9gwXjTWQrJ3GIEKI2VGHlMiM2th8KYBasmaY18X553udMRi1YQgSeL+VKg8jD2DbJ/y3Bq4uUC3EpA8pTLiLdsI9MR5UpQZDN4Y9KxJLQ791vouK0lnU+TeLjKbc3pla00ATL8Gizc= Received: by 10.65.59.11 with SMTP id m11mr1820311qbk; Thu, 15 Dec 2005 21:08:11 -0800 (PST) Received: by 10.65.135.14 with HTTP; Thu, 15 Dec 2005 21:08:11 -0800 (PST) Message-ID: Date: Fri, 16 Dec 2005 00:08:11 -0500 From: Mike Shaver To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <43A1F470.1000106@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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: Fri, 16 Dec 2005 05:08:13 -0000 On 12/15/05, Bernard Desruisseaux wrote: > You want MUST level requirements to make sure interoperability will be > achieved. It is obvious that are not seeking interoperability when you > start using non-standards components, properties or parameters... It's not about semantic interoperability of those properties between clients, it's about servers (and clients!) doing no harm to incoming data. I don't expect the Oracle CalDAV server to do anything interesting with X-MOZILLA-EVENT-COLOUR, but I definitely _do_ expect that if I put that on an event and then later change the time of that event, I'll get the same X-MOZILLA-EVENT-COLOUR when I fetch the changed event. I absolutely roll the dice when I make some part of the user experience depend on my property name not colliding with someone else's totally different property. And if Kontact were to use X-MOZILLA-EVENT-COLOUR to store localization data, I'd have no standards basis for complaining, I suppose. But it turns out that I can make those dice a pretty safe gamble by picking a good namespace and trusting my fellow implementors to not be complete dorks about their similar choices. It shouldn't matter if you're a server or a client, you should (and by "should" I mean MUST if we get a chance to write that language now) do your utmost to preserve X-PROPERTIES when manipulating an item. I think that should extend to propagating them from repeating events into exceptions, etc., but I will readily admit that reasonable people could disagree about that, and can construct imaginary scenarios in which that would break existing clients, etc. (Though not existing CalDAV clients who wouldn't get fixed, I bet! Yay for fresh starts!) Mike 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 9C4A47F796 for ; Thu, 15 Dec 2005 16:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7401A1422FB for ; Thu, 15 Dec 2005 16:04:28 -0800 (PST) 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 20636-01 for ; Thu, 15 Dec 2005 16:04:28 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 369991422F1 for ; Thu, 15 Dec 2005 16:04:28 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBG04NjW016686; Thu, 15 Dec 2005 16:04:23 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 83BCA4AB; Thu, 15 Dec 2005 16:04:23 -0800 (PST) In-Reply-To: <58fd44a97a7998b54a0bbaba2003dc14@opengroupware.org> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <58fd44a97a7998b54a0bbaba2003dc14@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40894863-72A8-4FCF-9760-EFECF01D7333@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 16:04:22 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Dec 2005 09:02:09 -0800 Cc: CalDAV DevList 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: Fri, 16 Dec 2005 00:04:28 -0000 Not allowing a client to edit a specific property (or any but a known set of properties) is not equivalent to having no support for PROPPATCH. 501 is not appropriate here, and removing PROPPATCH from OPTIONS is certainly not either. I don't see any reason why we should go down a different patch from WebDAV here. In fact, doing so would put CalDAV out of alignment with WebDAV. -wsv On Dec 15, 2005, at 3:16 PM, Helge Hess wrote: > On Dec 15, 2005, at 22:49, Bernard Desruisseaux wrote: >> If the server is unable to set a given dead property the response >> status of the PROPPATCH request MUST be a 403 (Forbidden). > > If you don't support PROPPATCH I would say you MUST return 501 (not > implemented) and remove PROPPATCH from the OPTIONS allowed header. > > This way the client at least has a chance to discover the fact in > advance instead of being required to deal with per-property errors > (which really only makes sense if the property is a separate, > protected resource [eg for per-user properties]). 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 4F7D47F7AB; Thu, 15 Dec 2005 16:01:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 401051422FB; Thu, 15 Dec 2005 16:01:25 -0800 (PST) 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 12237-05; Thu, 15 Dec 2005 16:01:25 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A4DA1422F1; Thu, 15 Dec 2005 16:01:25 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBG01NnM020735; Thu, 15 Dec 2005 16:01:23 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 1B3C51A5; Thu, 15 Dec 2005 16:01:23 -0800 (PST) In-Reply-To: References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B9985D4-6C2D-41E2-A39A-143FA36F1D5F@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 16:01:22 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Dec 2005 09:02:09 -0800 Cc: CalDAV DevList 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: Fri, 16 Dec 2005 00:01:25 -0000 On Dec 15, 2005, at 2:09 PM, Lisa Dusseault wrote: > On Dec 15, 2005, at 1:49 PM, Bernard Desruisseaux wrote: > >> Proposal: >> >> For (1) I would stick to what is said in Section 8.2 of RFC 2518: >> >> "DAV compliant resources SHOULD support the setting of >> arbitrary dead properties." >> >> If the server is unable to set a given dead property the response >> status of the PROPPATCH request MUST be a 403 (Forbidden). I don't >> believe the CalDAV draft need to say anything about all this. > > If we had a chair to declare consensus I would guess it would be > for MUST (and put this in CalDAV spec as such) as you're the only > one saying SHOULD :) Any other inputs? > > Lisa I don't think that enough opinions had been stated to justify such a declaration of consensus. Anyway, I agree with Bernard on both PROPPATCH and X- iCal properties, in that SHOULD is appropriate in both cases, and WebDAV says enough about the former. -wsv 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 C77687F78A; Thu, 15 Dec 2005 15:16:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B813C1422EC; Thu, 15 Dec 2005 15:16:30 -0800 (PST) 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 07920-10; Thu, 15 Dec 2005 15:16:30 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F2C31422D7; Thu, 15 Dec 2005 15:16:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 7B4D035ABC4; Fri, 16 Dec 2005 00:08:50 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 3AFC135ABC3; Fri, 16 Dec 2005 00:08:50 +0100 (CET) In-Reply-To: <43A1E507.9090209@oracle.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58fd44a97a7998b54a0bbaba2003dc14@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Fri, 16 Dec 2005 00:16:40 +0100 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList 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, 15 Dec 2005 23:16:31 -0000 On Dec 15, 2005, at 22:49, Bernard Desruisseaux wrote: > If the server is unable to set a given dead property the response > status of the PROPPATCH request MUST be a 403 (Forbidden). If you don't support PROPPATCH I would say you MUST return 501 (not implemented) and remove PROPPATCH from the OPTIONS allowed header. This way the client at least has a chance to discover the fact in advance instead of being required to deal with per-property errors (which really only makes sense if the property is a separate, protected resource [eg for per-user properties]). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 BACEC7F79D for ; Thu, 15 Dec 2005 15:12:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AB3CE1422D7 for ; Thu, 15 Dec 2005 15:12:17 -0800 (PST) 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 12559-04 for ; Thu, 15 Dec 2005 15:12:17 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4CD581422C8 for ; Thu, 15 Dec 2005 15:12:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6C4B535ABB5 for ; Fri, 16 Dec 2005 00:04:37 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 1430A35ABC7 for ; Fri, 16 Dec 2005 00:04:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <43A1F470.1000106@oracle.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Fri, 16 Dec 2005 00:12:23 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 15 Dec 2005 23:12:17 -0000 On Dec 15, 2005, at 23:55, Bernard Desruisseaux wrote: > I don't see why we would want to make that a MUST level requirement. It doesn't need to be a MUST, but it needs to be explicitly specified what is allowed. This is important for PROPPATCHes but even more so for X- attributes which are widely used in practice. > You want MUST level requirements to make sure interoperability will be > achieved. It is obvious that are not seeking interoperability when you > start using non-standards components, properties or parameters... I honestly can't follow you here at all. If a client doesn't know a property, it just doesn't touch it. If a set of clients use the same property, an extension spec can be written. With properties additional resource annotations are definitely cleaner than X-something (since we have namespaces, since props are by concept additional annotations, since property content can be arbitary XML, etc). My opinion so far: a PROPPATCH might be a MAY (not available for use in clients except non-crucial functionality), but X- should be a MUST. Since the Oracle server already supports this to a degree (though with sizing limitations), this should be acceptable for you. No? ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 711237F795 for ; Thu, 15 Dec 2005 15:02:42 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C2A51422C8; Thu, 15 Dec 2005 15:02:42 -0800 (PST) In-Reply-To: <43A1F470.1000106@oracle.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> <43A1F470.1000106@oracle.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 15:02:35 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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, 15 Dec 2005 23:02:42 -0000 It's so that clients have a chance of innovating. We've seen the problems with clients doing bizarre things with protocols like IMAP or simply being locked into a restricted model. Innovation and differentiation *does* affect interop because if we don't allow good channels, clients will be forced to pick bad ways to do this. Lisa On Dec 15, 2005, at 2:55 PM, Bernard Desruisseaux wrote: > Are there any use cases where the use of non-standards components, > properties and parameters are required to achieve interoperability > in CalDAV? > > I don't see why we would want to make that a MUST level requirement. > > You want MUST level requirements to make sure interoperability will be > achieved. It is obvious that are not seeking interoperability when you > start using non-standards components, properties or parameters... > > Cheers, > Bernard > > Lisa Dusseault wrote: >> On Dec 15, 2005, at 1:49 PM, Bernard Desruisseaux wrote: >>> Proposal: >>> >>> For (1) I would stick to what is said in Section 8.2 of RFC 2518: >>> >>> "DAV compliant resources SHOULD support the setting of >>> arbitrary dead properties." >>> >>> If the server is unable to set a given dead property the response >>> status of the PROPPATCH request MUST be a 403 (Forbidden). I don't >>> believe the CalDAV draft need to say anything about all this. >> If we had a chair to declare consensus I would guess it would be for >> MUST (and put this in CalDAV spec as such) as you're the only one >> saying SHOULD :) Any other inputs? >> Lisa > > > 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 42CBA7F77C for ; Thu, 15 Dec 2005 15:01:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25A7B1422C8 for ; Thu, 15 Dec 2005 15:01:28 -0800 (PST) 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 31518-10 for ; Thu, 15 Dec 2005 15:01:27 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85F251422B8 for ; Thu, 15 Dec 2005 15:01:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6AF8835ABA3 for ; Thu, 15 Dec 2005 23:53:47 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 07C5035AB08 for ; Thu, 15 Dec 2005 23:53:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <025323ef26cb8e4b4ea6e13add832e0b@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Fri, 16 Dec 2005 00:01:37 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 15 Dec 2005 23:01:28 -0000 On Dec 15, 2005, at 23:09, Lisa Dusseault wrote: >> For (1) I would stick to what is said in Section 8.2 of RFC 2518: >> >> "DAV compliant resources SHOULD support the setting of >> arbitrary dead properties." >> >> If the server is unable to set a given dead property the response >> status of the PROPPATCH request MUST be a 403 (Forbidden). I don't >> believe the CalDAV draft need to say anything about all this. > > If we had a chair to declare consensus I would guess it would be for > MUST (and put this in CalDAV spec as such) as you're the only one > saying SHOULD :) Any other inputs? Maybe you misunderstood me, I'm not in favor or against either of the options, I'm also perfectly fine with a SHOULD (well, a SHOULD is rather useless, either a MUST or a MAY). Indeed the regular OGo is in pretty much the same situation like the Oracle server (currently no support for storage of arbitary additional fields). The reason I raised this topic is that I just want to ensure that it is explicitly outlined in the CalDAV spec (this discussion just demonstrates why) and therefore _obvious_ to the client author what he can expect and what not. Its a very important design choice where to store additional fields / state (I think I gave a perfectly valid example). Indeed my greatest fear in this context is that people develop against a build-from-scratch CalDAV server as a reference just to find out that their clients are not CalDAV compatible but actually require optional features ... (better strip all MAYs and SHOULDs and move them to an additional spec). Now back to more practical issues. If a client does a PUT of an iCalendar entity which contains X- attributes but the server doesn't support them. What will happen? Will the server return a 501? A 403? etc. This MUST be described in the spec. In GroupDAV we say that a client MUST reGET an entity to catch losses and server side changes (eg a common change we assume is flattening of recurrence rules). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 191897F771; Thu, 15 Dec 2005 14:55:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 094851422C8; Thu, 15 Dec 2005 14:55:57 -0800 (PST) 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 01886-05; Thu, 15 Dec 2005 14:55:56 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B56351422B8; Thu, 15 Dec 2005 14:55:56 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBFMtsfx020918; Thu, 15 Dec 2005 15:55:54 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBFMtrOl013148; Thu, 15 Dec 2005 15:55:54 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-136.vpn.oracle.com [141.144.96.136]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBFMtcfH013060; Thu, 15 Dec 2005 15:55:43 -0700 Message-ID: <43A1F470.1000106@oracle.com> Date: Thu, 15 Dec 2005 17:55:44 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 15 Dec 2005 22:55:57 -0000 Are there any use cases where the use of non-standards components, properties and parameters are required to achieve interoperability in CalDAV? I don't see why we would want to make that a MUST level requirement. You want MUST level requirements to make sure interoperability will be achieved. It is obvious that are not seeking interoperability when you start using non-standards components, properties or parameters... Cheers, Bernard Lisa Dusseault wrote: > > On Dec 15, 2005, at 1:49 PM, Bernard Desruisseaux wrote: > >> Proposal: >> >> For (1) I would stick to what is said in Section 8.2 of RFC 2518: >> >> "DAV compliant resources SHOULD support the setting of >> arbitrary dead properties." >> >> If the server is unable to set a given dead property the response >> status of the PROPPATCH request MUST be a 403 (Forbidden). I don't >> believe the CalDAV draft need to say anything about all this. > > > If we had a chair to declare consensus I would guess it would be for > MUST (and put this in CalDAV spec as such) as you're the only one saying > SHOULD :) Any other inputs? > > Lisa > 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 CCCBD7F76F for ; Thu, 15 Dec 2005 14:09:17 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B979B1422A0; Thu, 15 Dec 2005 14:09:16 -0800 (PST) In-Reply-To: <43A1E507.9090209@oracle.com> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> <43A1E507.9090209@oracle.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 14:09:06 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.623) Cc: CalDAV DevList 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, 15 Dec 2005 22:09:18 -0000 On Dec 15, 2005, at 1:49 PM, Bernard Desruisseaux wrote: > Proposal: > > For (1) I would stick to what is said in Section 8.2 of RFC 2518: > > "DAV compliant resources SHOULD support the setting of > arbitrary dead properties." > > If the server is unable to set a given dead property the response > status of the PROPPATCH request MUST be a 403 (Forbidden). I don't > believe the CalDAV draft need to say anything about all this. If we had a chair to declare consensus I would guess it would be for MUST (and put this in CalDAV spec as such) as you're the only one saying SHOULD :) Any other inputs? Lisa 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 DCD267F52D; Thu, 15 Dec 2005 13:50:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CCE011422FB; Thu, 15 Dec 2005 13:50:12 -0800 (PST) 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 02325-03; Thu, 15 Dec 2005 13:50:12 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 692251422F6; Thu, 15 Dec 2005 13:50:12 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jBFLo8VR007265; Thu, 15 Dec 2005 14:50:08 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jBFLo7jq013447; Thu, 15 Dec 2005 14:50:08 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBFLo1lx013396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 Dec 2005 14:50:02 -0700 Message-ID: <43A1E507.9090209@oracle.com> Date: Thu, 15 Dec 2005 16:49:59 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 15 Dec 2005 21:50:13 -0000 I agree that both WebDAV dead properties and iCalendar X-properties MUST be preserved by CalDAV servers... that is, if the CalDAV servers allowed them to be stored in the first place. I also agree that X- properties MUST be supported in the calendar-query REPORT as valid properties that the client can ask the server to return in the results. Of course, you can ask the server whatever you want but it doesn't mean you'll get back what you are expecting. Sorry! :-) I think the real questions are: 1- Whether a CalDAV server is REQUIRED to support the setting of arbitrary dead properties with the PROPPATCH method. 2- Whether a CalDAV server is REQUIRED to support the setting of non-standard components, properties and parameters in calendar object resources with the PUT method. Proposal: For (1) I would stick to what is said in Section 8.2 of RFC 2518: "DAV compliant resources SHOULD support the setting of arbitrary dead properties." If the server is unable to set a given dead property the response status of the PROPPATCH request MUST be a 403 (Forbidden). I don't believe the CalDAV draft need to say anything about all this. For (2) I would go with the same approach: Calendar object resources SHOULD support the setting of non-standard components, properties and parameters. If a CalDAV server is unable to set a given non-standard component, property or parameter the response status of the PUT request MUST be a 403 (Forbidden). Perhaps the CalDAV server could return an XML response body with a DAV:error element that would specify that the CALDAV:supported-calendar-data is not satisfied and point out the "offending" non-standard token... Cheers, Bernard Lisa Dusseault wrote: > My view is that *both* WebDAV dead properties and iCalendar X-properties > MUST be preserved by CalDAV servers (they're completely different, in > case anybody is confusing them together). Further, X- properties MUST > be supported in the calendar-query REPORT as valid properties that the > client can ask the server to return in the results. > > Lisa > > On Dec 15, 2005, at 9:08 AM, Brian Moseley wrote: > >> Mike Douglass wrote: >> >>> As a server I won't know if an x property is supposed to be >>> multi-valued for example. I would take the position that I shouldn't >>> have to preserve any x-properties. >> >> >> why should you care? just store the property value opaquely. >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 705F27F75D; Thu, 15 Dec 2005 13:26:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 553581422FB; Thu, 15 Dec 2005 13:26:52 -0800 (PST) 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 31518-01; Thu, 15 Dec 2005 13:26:52 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E94571422F6; Thu, 15 Dec 2005 13:26:51 -0800 (PST) Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id jBFLu9UV028631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2005 16:56:11 -0500 Date: Thu, 15 Dec 2005 16:26:45 -0500 From: Cyrus Daboo To: Lisa Dusseault , CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Message-ID: In-Reply-To: References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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, 15 Dec 2005 21:26:52 -0000 Hi Lisa, --On December 15, 2005 10:30:22 AM -0800 Lisa Dusseault wrote: > My view is that *both* WebDAV dead properties and iCalendar X-properties > MUST be preserved by CalDAV servers (they're completely different, in > case anybody is confusing them together). Further, X- properties MUST be > supported in the calendar-query REPORT as valid properties that the > client can ask the server to return in the results. I want to go further and say iCalendar X- components, properties and parameters MUST be preserved and usable in REPORTs. -- Cyrus Daboo 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 DB2207F75E for ; Thu, 15 Dec 2005 10:56:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC4131422DC for ; Thu, 15 Dec 2005 10:56:16 -0800 (PST) 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 10668-01 for ; Thu, 15 Dec 2005 10:56:16 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E2891422D7 for ; Thu, 15 Dec 2005 10:56:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1FED0359BA2 for ; Thu, 15 Dec 2005 19:48:35 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id B29C1357F07 for ; Thu, 15 Dec 2005 19:48:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 19:56:14 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 15 Dec 2005 18:56:17 -0000 On 15. Dez 2005, at 19:30 Uhr, Lisa Dusseault wrote: > My view is that *both* WebDAV dead properties and iCalendar X- > properties MUST be preserved by CalDAV servers (they're completely > different, in case anybody is confusing them together). If this is the opinion the CalDAV authors agree upon, could this be stated explicitly in the spec? I suppose we probably also need something like "if a PUT succeeds w/o a 403, a PROPPATCH must not return 403"? Or is there a better way to ensure that implementations actually allow (aka implement) PROPPATCHes? Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 0DE867F752 for ; Thu, 15 Dec 2005 10:30:33 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E61AC1422E8 for ; Thu, 15 Dec 2005 10:30:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <43A1A304.80605@osafoundation.org> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> <43A1A304.80605@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 10:30:22 -0800 To: CalDAV DevList X-Mailer: Apple Mail (2.623) 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, 15 Dec 2005 18:30:33 -0000 My view is that *both* WebDAV dead properties and iCalendar X-properties MUST be preserved by CalDAV servers (they're completely different, in case anybody is confusing them together). Further, X- properties MUST be supported in the calendar-query REPORT as valid properties that the client can ask the server to return in the results. Lisa On Dec 15, 2005, at 9:08 AM, Brian Moseley wrote: > Mike Douglass wrote: > >> As a server I won't know if an x property is supposed to be >> multi-valued for example. I would take the position that I shouldn't >> have to preserve any x-properties. > > why should you care? just store the property value opaquely. > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 4DB157F700 for ; Thu, 15 Dec 2005 09:08:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D3781422A9 for ; Thu, 15 Dec 2005 09:08:21 -0800 (PST) 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 19581-04 for ; Thu, 15 Dec 2005 09:08:21 -0800 (PST) Received: from [10.0.1.6] (c-67-188-209-63.hsd1.ca.comcast.net [67.188.209.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D0EF1422A4 for ; Thu, 15 Dec 2005 09:08:21 -0800 (PST) Message-ID: <43A1A304.80605@osafoundation.org> Date: Thu, 15 Dec 2005 09:08:20 -0800 From: Brian Moseley User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> In-Reply-To: <43A191B3.7010302@rpi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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, 15 Dec 2005 17:08:21 -0000 Mike Douglass wrote: > As a server I won't know if an x property is supposed to be multi-valued > for example. I would take the position that I shouldn't have to preserve > any x-properties. why should you care? just store the property value opaquely. 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 771CA7F746 for ; Thu, 15 Dec 2005 08:56:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5A2F31422F1 for ; Thu, 15 Dec 2005 08:56:17 -0800 (PST) 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 25232-10 for ; Thu, 15 Dec 2005 08:56:17 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id A8AF11422EC for ; Thu, 15 Dec 2005 08:56:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id F1E4D357382 for ; Thu, 15 Dec 2005 17:48:34 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 9F23035A814 for ; Thu, 15 Dec 2005 17:48:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43A191B3.7010302@rpi.edu> References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders Date: Thu, 15 Dec 2005 17:56:14 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: 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, 15 Dec 2005 16:56:17 -0000 On 15. Dez 2005, at 16:54 Uhr, Mike Douglass wrote: > As a server I won't know if an x property is supposed to be multi- > valued for example. Well, then just store all properties as multivalued ... I don't understand the issue, you are not supposed to handle the content of x- attributes, you just need to store them as is. > I would take the position that I shouldn't have to preserve any x- > properties. Your quoting of the iCalendar spec suggests that, I agree. But then iCalendar was not intended for storage and that shows in various places. Anyway, as mentioned I would personally prefer not to use X- but instead add the explicit requirement that dead properties as per WebDAV spec must be supported. > I think it would also be a problem to require that the server store > arbitarry non-calendar I don't understand this sentence, could you rephrase? > - that would make it more diffficult to interface existing calendar > systems with a caldav front-end In the past I was told that the primary concern of CalDAV is not trivial implementation in servers. It certainly doesn't need to be harder than necessary, but the requirement to support dead properties might be a viable request for a WebDAV based protocol? On 15. Dez 2005, at 17:06 Uhr, Mike Shaver wrote: > Doesn't discarding X-properties break round tripping, in the general > case? I thought that a lot of calendaring clients stuck extra data > that was useful or even necessary to their user experience there, > because there's no other reliable way to have it travel with iCalendar > bits around the world. Yes, X- properties are widely used for various purposes. Eg in Kontact you can even build plugin editors for custom attributes in QtDesigner w/o writing any code. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 301C57F752 for ; Thu, 15 Dec 2005 08:06:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 209961422E8 for ; Thu, 15 Dec 2005 08:06:02 -0800 (PST) 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 15394-09 for ; Thu, 15 Dec 2005 08:06:01 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by laweleka.osafoundation.org (Postfix) with ESMTP id C6BC21422DC for ; Thu, 15 Dec 2005 08:06:01 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i31so397122wra for ; Thu, 15 Dec 2005 08:06:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ppzOqlkPMfzzVHP4cdTqY7IhZyWzOxtPyjpWV8zvF7tS+gwovyoJxufAyW1zp4lvQY0iXqSDEqFPVW84xkFUlh85LDyKnTyUNdQPSN/4CePKo5QH87BKsL6PRMDz7HQB4pcz0ytOjoWXv9QrdJmg2mCdzgA/djP3kUlvX5Yx9Q4= Received: by 10.65.222.3 with SMTP id z3mr1070928qbq; Thu, 15 Dec 2005 08:06:00 -0800 (PST) Received: by 10.65.135.14 with HTTP; Thu, 15 Dec 2005 08:06:00 -0800 (PST) Message-ID: Date: Thu, 15 Dec 2005 11:06:00 -0500 From: Mike Shaver To: Mike Douglass Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders In-Reply-To: <43A191B3.7010302@rpi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> <43A191B3.7010302@rpi.edu> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: CalDAV DevList 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, 15 Dec 2005 16:06:02 -0000 On 12/15/05, Mike Douglass wrote: > As it say's in the rfc > > x-name =3D "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reservered for experimental use. Not intended for use in > ; released products. > > > As a server I won't know if an x property is supposed to be multi-valued > for example. I would take the position that I shouldn't have to preserve > any x-properties. Doesn't discarding X-properties break round tripping, in the general case? I thought that a lot of calendaring clients stuck extra data that was useful or even necessary to their user experience there, because there's no other reliable way to have it travel with iCalendar bits around the world. Mike 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 B77F47F708 for ; Thu, 15 Dec 2005 07:54:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A7F791422EF for ; Thu, 15 Dec 2005 07:54:42 -0800 (PST) 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 01182-03 for ; Thu, 15 Dec 2005 07:54:42 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 471A01422DC for ; Thu, 15 Dec 2005 07:54:42 -0800 (PST) Received: from [128.113.124.140] (crustacean-12.dynamic.rpi.edu [128.113.124.140]) by smtp1.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jBFFsWZb016610; Thu, 15 Dec 2005 10:54:32 -0500 Message-ID: <43A191B3.7010302@rpi.edu> Date: Thu, 15 Dec 2005 10:54:27 -0500 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Dead properties on CalDAV events / folders References: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> In-Reply-To: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.1 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 15 Dec 2005 15:54:42 -0000 As it say's in the rfc x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. As a server I won't know if an x property is supposed to be multi-valued for example. I would take the position that I shouldn't have to preserve any x-properties. I think it would also be a problem to require that the server store arbitarry non-calendar - that would make it more diffficult to interface existing calendar systems with a caldav front-end Helge Hess wrote: > Hi, > > I think it would be good if the CalDAV spec would be very specific on > whether or not a CalDAV server is required to support arbitary dead > properties for authenticated users. > Some WebDAV implementations simply reject PROPPATCHes with a 403 > Forbidden (usually because they do not support custom properties [501 > would be more appropriate, but with a 403 the operation can be > rejected while still being "formally compliant" ...]). > > > This is important to resolve because a client developer must know > whether he can rely on using dead properties to store non-iCal > associated state in the server (which seems natural) or whether he > must resort to use x- properties. And even for the latter it would be > good if CalDAV would explicitly specify whether the server is > required to preserve arbitary iCalendar x- attributes in the content. > > To give a real world example, a MAPI storage provider would need some > place to store additional MAPI properties not covered by plain > iCalendar (for example the color label in OL 2003). > The same goes for folder information (eg MAPI associated contents of > a folder which are used to store the last selected view). > > Greets, > Helge -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 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 883A67F741 for ; Thu, 15 Dec 2005 07:17:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 79AC31422F1 for ; Thu, 15 Dec 2005 07:17:21 -0800 (PST) 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 07089-09 for ; Thu, 15 Dec 2005 07:17:21 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A6991422EF for ; Thu, 15 Dec 2005 07:17:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5740E35A6DE for ; Thu, 15 Dec 2005 16:09:38 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id F1EEC35A5F3 for ; Thu, 15 Dec 2005 16:09:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <2DFC2144-A97A-42F1-8E8C-57665F8426F3@opengroupware.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: CalDAV DevList From: Helge Hess Date: Thu, 15 Dec 2005 16:17:18 +0100 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Subject: [Ietf-caldav] Dead properties on CalDAV events / folders 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, 15 Dec 2005 15:17:21 -0000 Hi, I think it would be good if the CalDAV spec would be very specific on whether or not a CalDAV server is required to support arbitary dead properties for authenticated users. Some WebDAV implementations simply reject PROPPATCHes with a 403 Forbidden (usually because they do not support custom properties [501 would be more appropriate, but with a 403 the operation can be rejected while still being "formally compliant" ...]). This is important to resolve because a client developer must know whether he can rely on using dead properties to store non-iCal associated state in the server (which seems natural) or whether he must resort to use x- properties. And even for the latter it would be good if CalDAV would explicitly specify whether the server is required to preserve arbitary iCalendar x- attributes in the content. To give a real world example, a MAPI storage provider would need some place to store additional MAPI properties not covered by plain iCalendar (for example the color label in OL 2003). The same goes for folder information (eg MAPI associated contents of a folder which are used to store the last selected view). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 0D2557F5B5 for ; Mon, 12 Dec 2005 11:21:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F13CE1422D4 for ; Mon, 12 Dec 2005 11:21:45 -0800 (PST) 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 03298-05 for ; Mon, 12 Dec 2005 11:21:45 -0800 (PST) Received: from S1.cableone.net (s1.cableone.net [24.116.0.227]) by laweleka.osafoundation.org (Postfix) with ESMTP id 338A41422D3 for ; Mon, 12 Dec 2005 11:21:45 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 39942259 for ; Mon, 12 Dec 2005 12:22:10 -0700 Message-ID: <439DCDC7.70709@Royer.com> Date: Mon, 12 Dec 2005 12:21:43 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] iCal to XML Schema mapping proposal References: <13AC4E67178F4D4EA31BB1BA64530313E79CEF@amereast-ems2.IONAGLOBAL.COM> In-Reply-To: <13AC4E67178F4D4EA31BB1BA64530313E79CEF@amereast-ems2.IONAGLOBAL.COM> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010006010205080705020202" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-Aspam: Words 0.0 -561-5848 -562-2131 -gagel -caledonia -theres -iis -generate -warned -scanning X-Aspam: URLS scored 0.8 verisign.com cnc.bc.ca X-Aspam: Best match was sample c:\good\1051592149.251_651.ball X-Aspam: Total 0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 124, in=223, out=187, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Mon, 12 Dec 2005 19:21:46 -0000 This is a cryptographically signed message in MIME format. --------------ms010006010205080705020202 Content-Type: multipart/mixed; boundary="------------030902090206060409030305" This is a multi-part message in MIME format. --------------030902090206060409030305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The XML representation of calendaring discussion is taking place on xcal@inet-consulting.com. And that might be the best place to discuss XML and calendaring. The http://inet-consulting/mailman/admindb/xcal sign up page is working. The web site is having some problems - working on that now. Zbarcea, Hadrian wrote: > Hi, > > I would like to propose an XML Schema Mapping for the iCalendar format > (RFC2445). > > Calendars and scheduling information are an extremely important aspect > of any business process. The need for business process automation is > increasing. SOA based architectures are increasingly popular and > already provide measurable benefits to many companies around the world. > There is a wide range of use cases involving automated decision making > that would benefit from calendaring information of resources or people > participating to a business process being available. > > While RFC2445 is the de facto standard for calendaring data interchange > it is not well suited for use in SOA and Web Services (WS) which are > based on XML technologies. Previous attempts were made to provide such > mappings (such as xCal - > http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt) but > they are not sufficient for use in WS (which depend on WSDL and XML > Schema). The CalDAV effort is also approaching calendaring data > interchange from a different perspective from what I could gather. > > A standard mapping of iCalandar to XML is needed and long overdue. > Based on my research there is nothing to fill the gap. Please find > attached an (incomplete) draft of an XML Schema. > > There are 2 types that need to be mapped: VTimeZoneType and VAlarmType. > I will finish them in the coming days. There are probably other details > to be sorted out and I am looking forward to any feedback you might > have. > > Please let me know if your group has an interest in incorporating this > schema or if you have any suggestion about how it could be used. > > Thank you, > > Hadrian Zbarcea > Senior Engineer > IONA Technologies > 200 West St, #400 > Waltham, MA 02451 > (781) 902-8322 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030902090206060409030305 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------030902090206060409030305-- --------------ms010006010205080705020202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTIxMjE5MjE0M1owIwYJKoZIhvcNAQkEMRYEFLuN7lDUfjdcWLkC1kb45juk N4aOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBABFofzyzRJMWquVaRNRqpiUsO69E9pTqRcoyBUBHxZS3bhJ2bCrThOPSEEIhmoHypgv0 hpp3fKQztqovZSYjGmt2KOBpwL8gO1MmhVMJ6m6OGUpFA9lZDjSunL+eeQeRtIjzlDPtA4DY Chgt/ZkxrdQpHjgDVXA12tueJnCfIgJnISUmhoz2YrC6dMPi2DObyi9wOI1MXWIeUXWXljdg czRA1li+9ZnppHf6FBIwwwEJTfPVMVddtZFfct4O6vXRZMIlS4USfmtDWQRvCNUQZkfZm8gk jtAK4Xff2ZAIRkPHho9GCaF/qHZ3AP6bm+TNCXDuJW0ukbaaquyQw9alVQwAAAAAAAA= --------------ms010006010205080705020202-- 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 7444D7F593 for ; Mon, 12 Dec 2005 07:57:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D2361422D5 for ; Mon, 12 Dec 2005 07:57:17 -0800 (PST) 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 26345-07 for ; Mon, 12 Dec 2005 07:57:17 -0800 (PST) Received: from amereast-smg2.iona.com (amereast-smg2.iona.com [63.65.132.112]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A65381422D6 for ; Mon, 12 Dec 2005 07:57:16 -0800 (PST) Received: from amereast-ems2.IONAGLOBAL.COM ([10.65.6.84]) by amereast-smg2.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBCFvFJu018612 for ; Mon, 12 Dec 2005 10:57:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5FF34.B87ED731" Date: Mon, 12 Dec 2005 10:57:14 -0500 Message-ID: <13AC4E67178F4D4EA31BB1BA64530313E79CEF@amereast-ems2.IONAGLOBAL.COM> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: iCal to XML Schema mapping proposal Thread-Index: AcX/MutWT94zIjfFQ5aMHmZ319Hr4AAAZbFg From: "Zbarcea, Hadrian" To: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-caldav] iCal to XML Schema mapping proposal 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: Mon, 12 Dec 2005 15:57:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5FF34.B87ED731 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I would like to propose an XML Schema Mapping for the iCalendar format (RFC2445). Calendars and scheduling information are an extremely important aspect of any business process. The need for business process automation is increasing. SOA based architectures are increasingly popular and already provide measurable benefits to many companies around the world. There is a wide range of use cases involving automated decision making that would benefit from calendaring information of resources or people participating to a business process being available. While RFC2445 is the de facto standard for calendaring data interchange it is not well suited for use in SOA and Web Services (WS) which are based on XML technologies. Previous attempts were made to provide such mappings (such as xCal - http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt) but they are not sufficient for use in WS (which depend on WSDL and XML Schema). The CalDAV effort is also approaching calendaring data interchange from a different perspective from what I could gather. A standard mapping of iCalandar to XML is needed and long overdue. Based on my research there is nothing to fill the gap. Please find attached an (incomplete) draft of an XML Schema. =20 There are 2 types that need to be mapped: VTimeZoneType and VAlarmType. I will finish them in the coming days. There are probably other details to be sorted out and I am looking forward to any feedback you might have. Please let me know if your group has an interest in incorporating this schema or if you have any suggestion about how it could be used. Thank you, Hadrian Zbarcea Senior Engineer IONA Technologies 200 West St, #400 Waltham, MA 02451 (781) 902-8322 ------_=_NextPart_001_01C5FF34.B87ED731 Content-Type: application/octet-stream; name="xmlcal.xsd" Content-Transfer-Encoding: base64 Content-Description: xmlcal.xsd Content-Disposition: attachment; filename="xmlcal.xsd" PHhzOnNjaGVtYSB0YXJnZXROYW1lc3BhY2U9Imh0dHA6Ly9uYW1lc3BhY2UtVEJEIiANCiAgeG1s bnM6eG1sPSJodHRwOi8vd3d3LnczLm9yZy9YTUwvMTk5OC9uYW1lc3BhY2UiDQogIHhtbG5zOnhz PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgDQogIHhtbG5zOnRucz0iaHR0cDov L25hbWVzcGFjZS1UQkQiPg0KDQogIDx4czppbXBvcnQgbmFtZXNwYWNlPSJodHRwOi8vd3d3Lncz Lm9yZy9YTUwvMTk5OC9uYW1lc3BhY2UiIHNjaGVtYUxvY2F0aW9uPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAxL3htbC54c2QiLz4NCiAgPHhzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cudzMu b3JnLzIwMDEvWE1MU2NoZW1hIiBzY2hlbWFMb2NhdGlvbj0iaHR0cDovL3d3dy53My5vcmcvMjAw MS9YTUxTY2hlbWEiLz4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iSUNhbGVuZGFyVHlwZSI+ DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idmNhbGVuZGFyIiB0 eXBlPSJ0bnM6VkNhbGVuZGFyVHlwZSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICA8L3hz OnNlcXVlbmNlPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KICA8eHM6ZWxlbWVudCBuYW1lPSJpY2Fs ZW5kYXIiIHR5cGU9InRuczpJQ2FsZW5kYXJUeXBlIi8+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5h bWU9IlZDYWxlbmRhclR5cGUiPg0KICAgIDx4czpjaG9pY2UgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCI+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ2ZXZlbnQiIHR5cGU9InRu czpWRXZlbnRUeXBlIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ2dG9kbyIgdHlwZT0idG5z OlZUb2RvVHlwZSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idmpvdXJuYWwiIHR5cGU9InRu czpWSm91cm5hbFR5cGUiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InZmcmVlYnVzeSIgdHlw ZT0idG5zOlZGcmVlQnVzeVR5cGUiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InZ0aW1lem9u ZSIgdHlwZT0idG5zOlZUaW1lWm9uZVR5cGUiLz4NCiAgICAgIDwhLS1zdXBwb3J0IGZvciBpYW5h LWNvbXAgfCB4LWNvbXAgZXh0ZW5zaW9ucyAtLT4NCiAgICAgIDx4czphbnkgbmFtZXNwYWNlPSIj I290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCIvPg0KICAgIDwveHM6Y2hvaWNlPg0KICAgIDx4 czphdHRyaWJ1dGUgbmFtZT0idmVyc2lvbiIgdHlwZT0ieHM6c3RyaW5nIiB1c2U9InJlcXVpcmVk Ii8+DQogICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJwcm9kaWQiIHR5cGU9InhzOnN0cmluZyIgdXNl PSJyZXF1aXJlZCIvPg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0ibWV0aG9kIiB0eXBlPSJ4czpz dHJpbmciIHVzZT0ib3B0aW9uYWwiLz4NCiAgICA8eHM6YXR0cmlidXRlIHJlZj0ieG1sOmxhbmci Lz4NCiAgPC94czpjb21wbGV4VHlwZT4NCiAgDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJWRXZl bnRUeXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8IS0tIEZvbGxvd2luZyBlbGVtZW50 cyBhcmUgb3B0aW9uYWwgYW5kIGNhbiBhcHBlYXJlIG9ubHkgb25jZSAtLT4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9InVpZCIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZHRzdGFtcCIgdHlwZT0ieHM6ZGF0ZVRp bWUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1l PSJkdHN0YXJ0IiB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEi Lz4NCiAgICAgIDx4czpjaG9pY2UgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiPg0KICAgICAg ICA8eHM6ZWxlbWVudCBuYW1lPSJkdGVuZCIgdHlwZT0ieHM6ZGF0ZVRpbWUiLz4NCiAgICAgICAg PHhzOmVsZW1lbnQgbmFtZT0iZHVyYXRpb24iIHR5cGU9InhzOmR1cmF0aW9uIi8+DQogICAgICA8 L3hzOmNob2ljZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InN1bW1hcnkiIHR5cGU9InhzOnN0 cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5h bWU9ImNsYXNzIiB0eXBlPSJ0bnM6Q2xhc3NUeXBlIiBkZWZhdWx0PSJQVUJMSUMiIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJwcmlvcml0eSIg dHlwZT0idG5zOlByaW9yaXR5VHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAg ICAgIDx4czplbGVtZW50IG5hbWU9InNlcXVlbmNlIiB0eXBlPSJ4czppbnRlZ2VyIiBtaW5PY2N1 cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ib3JnYW5pemVy IiB0eXBlPSJ4czphbnlVUkkiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8 eHM6ZWxlbWVudCBuYW1lPSJjcmVhdGVkIiB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9Imxhc3QtbW9kaWZpZWQi IHR5cGU9InhzOmRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAg PHhzOmVsZW1lbnQgbmFtZT0idXJsIiB0eXBlPSJ4czphbnlVUkkiIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkZXNjcmlwdGlvbiIgdHlwZT0i eHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1l bnQgbmFtZT0ibG9jYXRpb24iIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InN0YXR1cyIgdHlwZT0idG5zOlZFdmVu dFN0YXR1c1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxl bWVudCBuYW1lPSJ0cmFuc3AiIHR5cGU9InRuczpUcmFuc3BhcmVuY3lUeXBlIiBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVjdXJyZW5jZS1p ZCIgdHlwZT0idG5zOlJlY3VycmVuY2VJRFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIx Ii8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJnZW8iIHR5cGU9InRuczpHZW9UeXBlIiBtaW5P Y2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPCEtLSBGb2xsb3dpbmcgZWxlbWVudHMg YXJlIG9wdGlvbmFsIGFuZCBjYW4gYXBwZWFyZSBtb3JlIHRoYW4gb25jZSAtLT4NCiAgICAgIDx4 czplbGVtZW50IG5hbWU9ImNhdGVnb3JpZXMiIHR5cGU9InRuczpTdHJpbmdWYWx1ZXNUeXBlIiBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBu YW1lPSJhdHRlbmRlZSIgdHlwZT0idG5zOkNhbEFkZHJlc3NUeXBlIiBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJyZWxhdGVkLXRv IiB0eXBlPSJ0bnM6UmVsYXRlZFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImNvbnRhY3QiIHR5cGU9InRuczpUZXh0V2l0 aEFsdFJlcFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAg IDx4czplbGVtZW50IG5hbWU9ImNvbW1lbnQiIHR5cGU9InRuczpUZXh0V2l0aEFsdFJlcFR5cGUi IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50 IG5hbWU9InJkYXRlIiB0eXBlPSJ0bnM6UkRhdGVUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJycnVsZSIgdHlwZT0idG5z OlJSdWxlVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAg PHhzOmVsZW1lbnQgbmFtZT0iZXhkYXRlIiB0eXBlPSJ0bnM6RGF0ZU9yRGF0ZVRpbWVUeXBlIiBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBu YW1lPSJleHJ1bGUiIHR5cGU9InRuczpSUnVsZVR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InJlcXVlc3Qtc3RhdHVzIiB0 eXBlPSJ0bnM6UmVxdWVzdFN0YXR1c1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImF0dGFjaCIgdHlwZT0idG5zOkF0dGFj aFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9InJlc291cmNlcyIgdHlwZT0idG5zOlN0cmluZ1ZhbHVlc1R5cGUiIG1pbk9j Y3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCg0KICAgICAgPHhzOmVsZW1lbnQgbmFt ZT0idmFsYXJtIiB0eXBlPSJ0bnM6VkFsYXJtVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 InVuYm91bmRlZCIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQoN CiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IlZUb2RvVHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0K ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idWlkIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0i MCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkdHN0YW1wIiB0eXBl PSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9ImR0c3RhcnQiIHR5cGU9InhzOmRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iY29tcGxldGVkIiB0eXBlPSJ4 czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVt ZW50IG5hbWU9InBlcmNlbnQtY29tcGxldGUiIHR5cGU9InRuczpQZXJjZW50VHlwZSIgbWluT2Nj dXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czpjaG9pY2UgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9IjEiPg0KICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkdWUiIHR5cGU9InhzOmRh dGVUaW1lIi8+DQogICAgICAgIDx4czplbGVtZW50IG5hbWU9ImR1cmF0aW9uIiB0eXBlPSJ4czpk dXJhdGlvbiIvPg0KICAgICAgPC94czpjaG9pY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJz dW1tYXJ5IiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJjbGFzcyIgdHlwZT0idG5zOkNsYXNzVHlwZSIgZGVmYXVs dD0iUFVCTElDIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1l bnQgbmFtZT0icHJpb3JpdHkiIHR5cGU9InRuczpQcmlvcml0eVR5cGUiIG1pbk9jY3Vycz0iMCIg bWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzZXF1ZW5jZSIgdHlwZT0i eHM6aW50ZWdlciIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVt ZW50IG5hbWU9Im9yZ2FuaXplciIgdHlwZT0ieHM6YW55VVJJIiBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iY3JlYXRlZCIgdHlwZT0ieHM6ZGF0 ZVRpbWUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBu YW1lPSJsYXN0LW1vZGlmaWVkIiB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InVybCIgdHlwZT0ieHM6YW55VVJJ IiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i ZGVzY3JpcHRpb24iIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEi Lz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImxvY2F0aW9uIiB0eXBlPSJ4czpzdHJpbmciIG1p bk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzdGF0 dXMiIHR5cGU9InRuczpWVG9kb1N0YXR1c1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIx Ii8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJyZWN1cnJlbmNlLWlkIiB0eXBlPSJ0bnM6UmVj dXJyZW5jZUlEVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9ImdlbyIgdHlwZT0idG5zOkdlb1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2Nj dXJzPSIxIi8+DQogICAgICA8IS0tIEZvbGxvd2luZyBlbGVtZW50cyBhcmUgb3B0aW9uYWwgYW5k IGNhbiBhcHBlYXJlIG1vcmUgdGhhbiBvbmNlIC0tPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i Y2F0ZWdvcmllcyIgdHlwZT0idG5zOlN0cmluZ1ZhbHVlc1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImF0dGVuZGVlIiB0 eXBlPSJ0bnM6Q2FsQWRkcmVzc1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InJlbGF0ZWQtdG8iIHR5cGU9InRuczpSZWxh dGVkVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhz OmVsZW1lbnQgbmFtZT0iY29udGFjdCIgdHlwZT0idG5zOlRleHRXaXRoQWx0UmVwVHlwZSIgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFt ZT0iY29tbWVudCIgdHlwZT0idG5zOlRleHRXaXRoQWx0UmVwVHlwZSIgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmRhdGUiIHR5 cGU9InRuczpSRGF0ZVR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4N CiAgICAgIDx4czplbGVtZW50IG5hbWU9InJydWxlIiB0eXBlPSJ0bnM6UlJ1bGVUeXBlIiBtaW5P Y2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1l PSJleGRhdGUiIHR5cGU9InRuczpEYXRlT3JEYXRlVGltZVR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImV4cnVsZSIgdHlw ZT0idG5zOlJSdWxlVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0K ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVxdWVzdC1zdGF0dXMiIHR5cGU9InRuczpSZXF1ZXN0 U3RhdHVzVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAg PHhzOmVsZW1lbnQgbmFtZT0iYXR0YWNoIiB0eXBlPSJ0bnM6QXR0YWNoVHlwZSIgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVz b3VyY2VzIiB0eXBlPSJ0bnM6U3RyaW5nVmFsdWVzVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCIvPg0KDQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ2YWxhcm0iIHR5cGU9 InRuczpWQWxhcm1UeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQog ICAgPC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5 cGUgbmFtZT0iVkpvdXJuYWxUeXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxl bWVudCBuYW1lPSJ1aWQiIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImR0c3RhbXAiIHR5cGU9InhzOmRhdGVUaW1l IiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i ZHRzdGFydCIgdHlwZT0ieHM6ZGF0ZVRpbWUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+ DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzdW1tYXJ5IiB0eXBlPSJ4czpzdHJpbmciIG1pbk9j Y3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJjbGFzcyIg dHlwZT0idG5zOkNsYXNzVHlwZSIgZGVmYXVsdD0iUFVCTElDIiBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ic2VxdWVuY2UiIHR5cGU9InhzOmlu dGVnZXIiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBu YW1lPSJvcmdhbml6ZXIiIHR5cGU9InhzOmFueVVSSSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImNyZWF0ZWQiIHR5cGU9InhzOmRhdGVUaW1l IiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i bGFzdC1tb2RpZmllZCIgdHlwZT0ieHM6ZGF0ZVRpbWUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ1cmwiIHR5cGU9InhzOmFueVVSSSIgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImRlc2Ny aXB0aW9uIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJzdGF0dXMiIHR5cGU9InRuczpWSm91cm5hbFN0YXR1c1R5 cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1l PSJyZWN1cnJlbmNlLWlkIiB0eXBlPSJ0bnM6UmVjdXJyZW5jZUlEVHlwZSIgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDwhLS0gRm9sbG93aW5nIGVsZW1lbnRzIGFyZSBvcHRp b25hbCBhbmQgY2FuIGFwcGVhcmUgbW9yZSB0aGFuIG9uY2UgLS0+DQogICAgICA8eHM6ZWxlbWVu dCBuYW1lPSJjYXRlZ29yaWVzIiB0eXBlPSJ0bnM6U3RyaW5nVmFsdWVzVHlwZSIgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iYXR0 ZW5kZWUiIHR5cGU9InRuczpDYWxBZGRyZXNzVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVsYXRlZC10byIgdHlwZT0i dG5zOlJlbGF0ZWRUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJjb250YWN0IiB0eXBlPSJ0bnM6VGV4dFdpdGhBbHRSZXBU eXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxl bWVudCBuYW1lPSJjb21tZW50IiB0eXBlPSJ0bnM6VGV4dFdpdGhBbHRSZXBUeXBlIiBtaW5PY2N1 cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJy ZGF0ZSIgdHlwZT0idG5zOlJEYXRlVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91 bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icnJ1bGUiIHR5cGU9InRuczpSUnVsZVR5 cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVt ZW50IG5hbWU9ImV4ZGF0ZSIgdHlwZT0idG5zOkRhdGVPckRhdGVUaW1lVHlwZSIgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZXhy dWxlIiB0eXBlPSJ0bnM6UlJ1bGVUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3Vu ZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJyZXF1ZXN0LXN0YXR1cyIgdHlwZT0idG5z OlJlcXVlc3RTdGF0dXNUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJhdHRhY2giIHR5cGU9InRuczpBdHRhY2hUeXBlIiBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgPC94czpzZXF1ZW5jZT4N CiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iVkZyZWVCdXN5 VHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idWlkIiB0 eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICA8eHM6 ZWxlbWVudCBuYW1lPSJkdHN0YW1wIiB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImR0c3RhcnQiIHR5cGU9Inhz OmRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1l bnQgbmFtZT0iZHRlbmQiIHR5cGU9InhzOmRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZHVyYXRpb24iIHR5cGU9InhzOmR1cmF0 aW9uIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFt ZT0ib3JnYW5pemVyIiB0eXBlPSJ4czphbnlVUkkiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIx Ii8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJjcmVhdGVkIiB0eXBlPSJ4czpkYXRlVGltZSIg bWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InVy bCIgdHlwZT0ieHM6YW55VVJJIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgICAg PCEtLSBGb2xsb3dpbmcgZWxlbWVudHMgYXJlIG9wdGlvbmFsIGFuZCBjYW4gYXBwZWFyZSBtb3Jl IHRoYW4gb25jZSAtLT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImF0dGVuZGVlIiB0eXBlPSJ0 bnM6Q2FsQWRkcmVzc1R5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4N CiAgICAgIDx4czplbGVtZW50IG5hbWU9ImNvbW1lbnQiIHR5cGU9InRuczpUZXh0V2l0aEFsdFJl cFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9ImZyZWVidXN5IiB0eXBlPSJ0bnM6UGVyaW9kVHlwZSIgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0icmVxdWVz dC1zdGF0dXMiIHR5cGU9InRuczpSZXF1ZXN0U3RhdHVzVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5 cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IlZUaW1lWm9uZVR5cGUiPg0KICAgIDx4czpz ZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InVuZGVmaW5lZCIgdHlwZT0ieHM6c3Ry aW5nIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQog IDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IlZBbGFybVR5cGUi Pg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InVuZGVmaW5lZCIg dHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgIDwveHM6 c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0i VXJpTGlzdFR5cGUiPg0KICAgIDx4czpsaXN0IGl0ZW1UeXBlPSJ4czphbnlVUkkiLz4gDQogIDwv eHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJDbGFzc1R5cGUiPg0KICAg IDx4czphbm5vdGF0aW9uPg0KICAgICAgPHhzOmRvY3VtZW50YXRpb24+Q0xBU1MgcHJvcGVydHkg YXMgZGVmaW5lZCBieSBSRkMyNDQ1LjwveHM6ZG9jdW1lbnRhdGlvbj4NCiAgICA8L3hzOmFubm90 YXRpb24+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6 ZW51bWVyYXRpb24gdmFsdWU9IlBVQkxJQyIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVl PSJQUklWQVRFIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNPTkZJREVOVElBTCIv Pg0KICAgIDwveHM6cmVzdHJpY3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2lt cGxlVHlwZSBuYW1lPSJWRXZlbnRTdGF0dXNUeXBlIj4NCiAgICA8eHM6cmVzdHJpY3Rpb24gYmFz ZT0ieHM6c3RyaW5nIj4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iVEVOVEFUSVZFIi8+ DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNPTkZJUk1FRCIvPg0KICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJDQU5DRUxMRUQiLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8 L3hzOnNpbXBsZVR5cGU+DQoNCiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iVlRvZG9TdGF0dXNUeXBl Ij4NCiAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4NCiAgICAgIDx4czplbnVt ZXJhdGlvbiB2YWx1ZT0iTkVFRFMtQUNUSU9OIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFs dWU9IkNPTVBMRVRFRCIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJJTi1QUk9DRVNT Ii8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNBTkNFTExFRCIvPg0KICAgIDwveHM6 cmVzdHJpY3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1l PSJWSm91cm5hbFN0YXR1c1R5cGUiPg0KICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJp bmciPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEUkFGVCIvPg0KICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJGSU5BTCIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJD QU5DRUxMRUQiLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoN CiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iRnJlZUJ1c3lUeXBlVHlwZSI+DQogICAgPHhzOnJlc3Ry aWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkZS RUUiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQlVTWSIvPg0KICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJCVVNZLVVOQVZBSUxBQkxFIi8+DQogICAgICA8eHM6ZW51bWVyYXRp b24gdmFsdWU9IkJVU1ktVEVOVEFUSVZFIi8+DQogICAgPC94czpyZXN0cmljdGlvbj4NCiAgPC94 czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5hbWU9IlRyYW5zcGFyZW5jeVR5cGUi Pg0KICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KICAgICAgPHhzOmVudW1l cmF0aW9uIHZhbHVlPSJUUkFOU1BBUkVOVCIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVl PSJPUEFRVUUiLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoN CiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iUHJpb3JpdHlUeXBlIj4NCiAgICA8eHM6cmVzdHJpY3Rp b24gYmFzZT0ieHM6aW50ZWdlciI+DQogICAgICA8eHM6bWluSW5jbHVzaXZlIHZhbHVlPSIwIi8+ DQogICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSI5Ii8+DQogICAgPC94czpyZXN0cmljdGlv bj4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5hbWU9IlJJRFBhcmFt VmFsdWVUeXBlIj4NCiAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4NCiAgICAg IDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iREFURS1USU1FIi8+DQogICAgICA8eHM6ZW51bWVyYXRp b24gdmFsdWU9IkRBVEUiLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5 cGU+DQoNCiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iUmFuZ2VQYXJhbVZhbHVlVHlwZSI+DQogICAg PHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24g dmFsdWU9IlRISVNBTkRQUklPUiIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJUSElT QU5ERlVUVVJFIi8+DQogICAgPC94czpyZXN0cmljdGlvbj4NCiAgPC94czpzaW1wbGVUeXBlPg0K DQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJSZWN1cnJlbmNlSURUeXBlIj4NCiAgICA8eHM6YXR0 cmlidXRlIG5hbWU9InZhbHVlIiB0eXBlPSJ0bnM6UklEUGFyYW1WYWx1ZVR5cGUiIHVzZT0ib3B0 aW9uYWwiLz4NCiAgICA8eHM6YXR0cmlidXRlIG5hbWU9InJhbmdlIiB0eXBlPSJ0bnM6UmFuZ2VQ YXJhbVZhbHVlVHlwZSIgdXNlPSJvcHRpb25hbCIvPg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0i dHppZCIgdHlwZT0ieHM6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+DQogIDwveHM6Y29tcGxleFR5 cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9Ikdlb1R5cGUiPg0KICAgIDx4czphdHRyaWJ1 dGUgbmFtZT0ibGF0IiB0eXBlPSJ4czpmbG9hdCIgdXNlPSJvcHRpb25hbCIvPg0KICAgIDx4czph dHRyaWJ1dGUgbmFtZT0ibG9uZyIgdHlwZT0ieHM6ZmxvYXQiIHVzZT0ib3B0aW9uYWwiLz4NCiAg ICA8eHM6YXR0cmlidXRlIG5hbWU9ImFsdCIgdHlwZT0ieHM6ZmxvYXQiIHVzZT0ib3B0aW9uYWwi Lz4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iQ2FsQWRk cmVzc1R5cGUiPg0KICAgIDx4czpzaW1wbGVDb250ZW50Pg0KICAgICAgPHhzOmV4dGVuc2lvbiBi YXNlPSJ4czphbnlVUkkiPg0KICAgICAgICA8eHM6YXR0cmlidXRlIHJlZj0ieG1sOmxhbmciLz4N CiAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJjdXR5cGUiIHR5cGU9InRuczpDVVBhcmFtVmFs dWVUeXBlIiB1c2U9Im9wdGlvbmFsIiBkZWZhdWx0PSJJTkRJVklEVUFMIi8+DQogICAgICAgIDx4 czphdHRyaWJ1dGUgbmFtZT0ibWVtYmVyIiB0eXBlPSJ0bnM6VXJpTGlzdFR5cGUiIHVzZT0ib3B0 aW9uYWwiLz4NCiAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJyb2xlIiB0eXBlPSJ0bnM6Um9s ZVBhcmFtVmFsdWVUeXBlIiB1c2U9Im9wdGlvbmFsIiBkZWZhdWx0PSJSRVEtUEFSVElDSVBBTlQi Lz4NCiAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJwYXJ0c3RhdCIgdHlwZT0idG5zOlZFdmVu dFBhcnRpY2lwYXRpb25TdGF0dXNWYWx1ZVR5cGUiIHVzZT0ib3B0aW9uYWwiIGRlZmF1bHQ9Ik5F RURTLUFDVElPTiIvPg0KICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InJzdnAiIHR5cGU9Inhz OmJvb2xlYW4iIHVzZT0ib3B0aW9uYWwiIGRlZmF1bHQ9ImZhbHNlIi8+DQogICAgICAgIDx4czph dHRyaWJ1dGUgbmFtZT0iZGVsZWdhdGVkLWZyb20iIHR5cGU9InRuczpVcmlMaXN0VHlwZSIgdXNl PSJvcHRpb25hbCIvPg0KICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9ImRlbGVnYXRlZC10byIg dHlwZT0idG5zOlVyaUxpc3RUeXBlIiB1c2U9Im9wdGlvbmFsIi8+DQogICAgICAgIDx4czphdHRy aWJ1dGUgbmFtZT0ic2VudC1ieSIgdHlwZT0ieHM6YW55VVJJIiB1c2U9Im9wdGlvbmFsIi8+DQog ICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iY24iIHR5cGU9InhzOnN0cmluZyIgdXNlPSJvcHRp b25hbCIvPg0KICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9ImRpciIgdHlwZT0ieHM6YW55VVJJ IiB1c2U9Im9wdGlvbmFsIi8+DQogICAgICAgIDx4czphbnlBdHRyaWJ1dGUgbmFtZXNwYWNlPSIj I290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCIvPg0KICAgICAgPC94czpleHRlbnNpb24+DQog ICAgPC94czpzaW1wbGVDb250ZW50Pg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpjb21w bGV4VHlwZSBuYW1lPSJSZWxhdGVkVHlwZSI+DQogICAgPHhzOnNpbXBsZUNvbnRlbnQ+DQogICAg ICA8eHM6ZXh0ZW5zaW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICAgIDx4czphdHRyaWJ1dGUg bmFtZT0icmVsdHlwZSIgdHlwZT0idG5zOlJlbFR5cGVUeXBlIiB1c2U9Im9wdGlvbmFsIiBkZWZh dWx0PSJQQVJFTlQiLz4NCiAgICAgIDwveHM6ZXh0ZW5zaW9uPg0KICAgIDwveHM6c2ltcGxlQ29u dGVudD4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iVGV4 dFdpdGhBbHRSZXBUeXBlIj4NCiAgICA8eHM6c2ltcGxlQ29udGVudD4NCiAgICAgIDx4czpleHRl bnNpb24gYmFzZT0ieHM6c3RyaW5nIj4NCiAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJhbHRy ZXAiIHR5cGU9InhzOmFueVVSSSIgdXNlPSJvcHRpb25hbCIvPg0KICAgICAgICA8eHM6YXR0cmli dXRlIHJlZj0ieG1sOmxhbmciLz4NCiAgICAgIDwveHM6ZXh0ZW5zaW9uPg0KICAgIDwveHM6c2lt cGxlQ29udGVudD4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFt ZT0iRGF0ZU9yRGF0ZVRpbWVUeXBlIj4NCiAgICA8eHM6Y2hvaWNlPg0KICAgICAgPHhzOmVsZW1l bnQgbmFtZT0iZGF0ZSIgdHlwZT0ieHM6ZGF0ZSIgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVu Ym91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGF0ZS10aW1lIiB0eXBlPSJ4czpk YXRlVGltZSIgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgIDwveHM6 Y2hvaWNlPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJQ ZXJpb2RUeXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJz dGFydCIgdHlwZT0ieHM6ZGF0ZVRpbWUiLz4NCiAgICAgIDx4czpjaG9pY2U+DQogICAgICAgIDx4 czplbGVtZW50IG5hbWU9ImVuZCIgdHlwZT0ieHM6ZGF0ZVRpbWUiLz4NCiAgICAgICAgPHhzOmVs ZW1lbnQgbmFtZT0iZHVyYXRpb24iIHR5cGU9InhzOmR1cmF0aW9uIi8+DQogICAgICA8L3hzOmNo b2ljZT4NCiAgICA8L3hzOnNlcXVlbmNlPg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0idHlwZSIg dHlwZT0idG5zOkZyZWVCdXN5VHlwZVR5cGUiLz4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8 eHM6Y29tcGxleFR5cGUgbmFtZT0iUkRhdGVUeXBlIj4NCiAgICA8eHM6Y29tcGxleENvbnRlbnQ+ DQogICAgICA8eHM6ZXh0ZW5zaW9uIGJhc2U9InRuczpEYXRlT3JEYXRlVGltZVR5cGUiPg0KICAg ICAgICA8eHM6Y2hvaWNlPg0KICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9InBlcmlvZCIgdHlw ZT0ieHM6ZHVyYXRpb24iIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAg ICAgICAgPC94czpjaG9pY2U+DQogICAgICA8L3hzOmV4dGVuc2lvbj4NCiAgICA8L3hzOmNvbXBs ZXhDb250ZW50Pg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpjb21wbGV4VHlwZSBuYW1l PSJSUnVsZVR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9 ImZyZXEiIHR5cGU9InRuczpSZWN1cnJlbmNlRnJlcXVlbmN5VHlwZSIvPg0KICAgICAgPHhzOmNo b2ljZT4NCiAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idW50aWwiIHR5cGU9InRuczpEYXRlT3JE YXRlVGltZVR5cGUiLz4NCiAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iY291bnQiIHR5cGU9Inhz OmludGVnZXIiLz4NCiAgICAgIDwveHM6Y2hvaWNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0i aW50ZXJ2YWwiIHR5cGU9InhzOmludGVnZXIiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+ DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJieXNlY29uZCIgdHlwZT0idG5zOlRpbWVTZWNvbmRU eXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxl bWVudCBuYW1lPSJieW1pbnV0ZSIgdHlwZT0idG5zOlRpbWVNaW51dGVUeXBlIiBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJieWhv dXIiIHR5cGU9InRuczpUaW1lSG91clR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImJ5ZGF5IiB0eXBlPSJ0bnM6VGltZVdl ZWtEYXlUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8 eHM6ZWxlbWVudCBuYW1lPSJieW1vbnRoZGF5IiB0eXBlPSJ0bnM6VGltZU1vbnRoRGF5VHlwZSIg bWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iYnl5ZWFyZGF5IiB0eXBlPSJ0bnM6VGltZVllYXJEYXlUeXBlIiBtaW5PY2N1cnM9IjAi IG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJieXdlZWtu byIgdHlwZT0idG5zOlRpbWVXZWVrT3JkaW5hbFR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImJ5bW9udGgiIHR5cGU9InRu czpUaW1lTW9udGhPcmRpbmFsVHlwZSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRl ZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iYnlzZXRwb3MiIHR5cGU9InRuczpUaW1lWWVh ckRheVR5cGUiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDx4 czplbGVtZW50IG5hbWU9ImJ5d2tzdCIgdHlwZT0idG5zOldlZWtEYXlUeXBlIiBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5 cGU+DQogDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJTdHJpbmdWYWx1ZXNUeXBlIj4NCiAgICA8 eHM6Y29tcGxleENvbnRlbnQ+DQogICAgICA8eHM6ZXh0ZW5zaW9uIGJhc2U9InhzOm9wZW5BdHRy cyI+DQogICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ2 YWx1ZSIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0idW5ib3VuZGVk Ii8+DQogICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAgIDx4czphdHRyaWJ1dGUgcmVmPSJ4 bWw6bGFuZyIvPg0KICAgICAgPC94czpleHRlbnNpb24+DQogICAgPC94czpjb21wbGV4Q29udGVu dD4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVxdWVz dFN0YXR1c1R5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9 ImNvZGUiPg0KICAgICAgICA8eHM6c2ltcGxlVHlwZT4NCiAgICAgICAgICA8eHM6cmVzdHJpY3Rp b24gYmFzZT0ieHM6c3RyaW5nIj4NCiAgICAgICAgICAgIDx4czpwYXR0ZXJuIHZhbHVlPSJbMC05 XSsoXC5bMC05XSspPyIvPg0KICAgICAgICAgIDwveHM6cmVzdHJpY3Rpb24+DQogICAgICAgIDwv eHM6c2ltcGxlVHlwZT4NCiAgICAgIDwveHM6ZWxlbWVudD4NCiAgICAgIDx4czplbGVtZW50IG5h bWU9ImRlc2NyaXB0aW9uIiB0eXBlPSJ4czpzdHJpbmciLz4NCiAgICAgIDx4czplbGVtZW50IG5h bWU9ImV4dGRhdGEiIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEi Lz4NCiAgICA8L3hzOnNlcXVlbmNlPg0KICAgIDx4czphdHRyaWJ1dGUgcmVmPSJ4bWw6bGFuZyIv Pg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJBdHRhY2hU eXBlIj4NCiAgICA8eHM6Y2hvaWNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0idXJpIiB0eXBl PSJ4czphbnlVUkkiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InZhbHVlIiB0eXBlPSJ4czpi YXNlNjRCaW5hcnkiLz4NCiAgICA8L3hzOmNob2ljZT4NCiAgICA8eHM6YXR0cmlidXRlIG5hbWU9 InR5cGUiIHR5cGU9InhzOnN0cmluZyIvPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpz aW1wbGVUeXBlIG5hbWU9IlJlbFR5cGVUeXBlIj4NCiAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0i eHM6c3RyaW5nIj4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iUEFSRU5UIi8+DQogICAg ICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNISUxEIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24g dmFsdWU9IlNJQkxJTkciLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5 cGU+DQoNCiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iQ1VQYXJhbVZhbHVlVHlwZSI+DQogICAgPHhz OnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFs dWU9IklORElWSURVQUwiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iR1JPVVAiLz4N CiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iUkVTT1VSQ0UiLz4NCiAgICAgIDx4czplbnVt ZXJhdGlvbiB2YWx1ZT0iUk9PTSIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJVTktO T1dOIi8+DQogICAgPC94czpyZXN0cmljdGlvbj4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4 czpzaW1wbGVUeXBlIG5hbWU9IlJvbGVQYXJhbVZhbHVlVHlwZSI+DQogICAgPHhzOnJlc3RyaWN0 aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNIQUlS Ii8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlJFUS1QQVJUSUNJUEFOVCIvPg0KICAg ICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJPUFQtUEFSVElDSVBBTlQiLz4NCiAgICAgIDx4czpl bnVtZXJhdGlvbiB2YWx1ZT0iTk9OLVBBUlRJQ0lQQU5UIi8+DQogICAgPC94czpyZXN0cmljdGlv bj4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5hbWU9IlZFdmVudFBh cnRpY2lwYXRpb25TdGF0dXNWYWx1ZVR5cGUiPg0KICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4 czpzdHJpbmciPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJORUVEUy1BQ1RJT04iLz4N CiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQUNDRVBURUQiLz4NCiAgICAgIDx4czplbnVt ZXJhdGlvbiB2YWx1ZT0iREVDTElORUQiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0i VEVOVEFUSVZFIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkRFTEVHQVRFRCIvPg0K ICAgIDwveHM6cmVzdHJpY3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxl VHlwZSBuYW1lPSJWVG9kb1BhcnRpY2lwYXRpb25TdGF0dXNWYWx1ZVR5cGUiPg0KICAgIDx4czpy ZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVl PSJORUVEUy1BQ1RJT04iLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQUNDRVBURUQi Lz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iREVDTElORUQiLz4NCiAgICAgIDx4czpl bnVtZXJhdGlvbiB2YWx1ZT0iVEVOVEFUSVZFIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFs dWU9IkRFTEVHQVRFRCIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJERUxFR0FURUQi Lz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iREVMRUdBVEVEIi8+DQogICAgPC94czpy ZXN0cmljdGlvbj4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5hbWU9 IlZKb3VybmFsUGFydGljaXBhdGlvblN0YXR1c1ZhbHVlVHlwZSI+DQogICAgPHhzOnJlc3RyaWN0 aW9uIGJhc2U9InhzOnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9Ik5FRURT LUFDVElPTiIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJBQ0NFUFRFRCIvPg0KICAg ICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJERUNMSU5FRCIvPg0KICAgIDwveHM6cmVzdHJpY3Rp b24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJSZWN1cnJl bmNlRnJlcXVlbmN5VHlwZSI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+ DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlNFQ09ORExZIi8+DQogICAgICA8eHM6ZW51 bWVyYXRpb24gdmFsdWU9Ik1JTlVURUxZIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9 IkhPVVJMWSIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEQUlMWSIvPg0KICAgICAg PHhzOmVudW1lcmF0aW9uIHZhbHVlPSJXRUVLTFkiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2 YWx1ZT0iTU9OVEhMWSIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJZRUFSTFkiLz4N CiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoNCiAgPHhzOnNpbXBs ZVR5cGUgbmFtZT0iV2Vla0RheVR5cGUiPg0KICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpz dHJpbmciPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJTVU4iLz4NCiAgICAgIDx4czpl bnVtZXJhdGlvbiB2YWx1ZT0iTU9OIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlRV RSIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJXRUQiLz4NCiAgICAgIDx4czplbnVt ZXJhdGlvbiB2YWx1ZT0iVEhVIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkZSSSIv Pg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJTQVQiLz4NCiAgICA8L3hzOnJlc3RyaWN0 aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoNCiAgPHhzOnNpbXBsZVR5cGUgbmFtZT0iVGltZVNl Y29uZFR5cGUiPg0KICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzaG9ydCI+DQogICAgICA8 eHM6bWluSW5jbHVzaXZlIHZhbHVlPSIwIi8+DQogICAgICA8eHM6bWF4RXhjbHVzaXZlIHZhbHVl PSI2MCIvPg0KICAgIDwveHM6cmVzdHJpY3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8 eHM6c2ltcGxlVHlwZSBuYW1lPSJUaW1lTWludXRlVHlwZSI+DQogICAgPHhzOnJlc3RyaWN0aW9u IGJhc2U9InhzOnNob3J0Ij4NCiAgICAgIDx4czptaW5JbmNsdXNpdmUgdmFsdWU9IjAiLz4NCiAg ICAgIDx4czptYXhFeGNsdXNpdmUgdmFsdWU9IjYwIi8+DQogICAgPC94czpyZXN0cmljdGlvbj4N CiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5hbWU9IlRpbWVIb3VyVHlw ZSI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOmludGVnZXIiPg0KICAgICAgPHhzOm1p bkluY2x1c2l2ZSB2YWx1ZT0iMCIvPg0KICAgICAgPHhzOm1heEV4Y2x1c2l2ZSB2YWx1ZT0iMjQi Lz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoNCiAgPHhzOnNp bXBsZVR5cGUgbmFtZT0iVGltZVdlZWtPcmRpbmFsVHlwZSI+DQogICAgPHhzOnVuaW9uPg0KICAg ICAgPHhzOnNpbXBsZVR5cGU+DQogICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzaG9y dCI+DQogICAgICAgICAgPHhzOm1pbkluY2x1c2l2ZSB2YWx1ZT0iLTUzIi8+DQogICAgICAgICAg PHhzOm1heEluY2x1c2l2ZSB2YWx1ZT0iLTEiLz4NCiAgICAgICAgPC94czpyZXN0cmljdGlvbj4N CiAgICAgIDwveHM6c2ltcGxlVHlwZT4NCiAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICA8 eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c2hvcnQiPg0KICAgICAgICAgIDx4czptaW5JbmNsdXNp dmUgdmFsdWU9IjEiLz4NCiAgICAgICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSI1MyIvPg0K ICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgIDwv eHM6dW5pb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJU aW1lTW9udGhPcmRpbmFsVHlwZSI+DQogICAgPHhzOnVuaW9uPg0KICAgICAgPHhzOnNpbXBsZVR5 cGU+DQogICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzaG9ydCI+DQogICAgICAgICAg PHhzOm1pbkluY2x1c2l2ZSB2YWx1ZT0iLTEyIi8+DQogICAgICAgICAgPHhzOm1heEluY2x1c2l2 ZSB2YWx1ZT0iLTEiLz4NCiAgICAgICAgPC94czpyZXN0cmljdGlvbj4NCiAgICAgIDwveHM6c2lt cGxlVHlwZT4NCiAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICA8eHM6cmVzdHJpY3Rpb24g YmFzZT0ieHM6c2hvcnQiPg0KICAgICAgICAgIDx4czptaW5JbmNsdXNpdmUgdmFsdWU9IjEiLz4N CiAgICAgICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSIxMiIvPg0KICAgICAgICA8L3hzOnJl c3RyaWN0aW9uPg0KICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgIDwveHM6dW5pb24+DQogIDwv eHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iVGltZVdlZWtEYXlUeXBl Ij4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJwb3MiIHR5cGU9 InRuczpUaW1lV2Vla09yZGluYWxUeXBlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0K ICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGF5IiB0eXBlPSJ0bnM6V2Vla0RheVR5cGUiLz4NCiAg ICA8L3hzOnNlcXVlbmNlPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KICANCiAgPHhzOnNpbXBsZVR5 cGUgbmFtZT0iVGltZU1vbnRoRGF5VHlwZSI+DQogICAgPHhzOnVuaW9uPg0KICAgICAgPHhzOnNp bXBsZVR5cGU+DQogICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzaG9ydCI+DQogICAg ICAgICAgPHhzOm1pbkluY2x1c2l2ZSB2YWx1ZT0iLTMxIi8+DQogICAgICAgICAgPHhzOm1heElu Y2x1c2l2ZSB2YWx1ZT0iLTEiLz4NCiAgICAgICAgPC94czpyZXN0cmljdGlvbj4NCiAgICAgIDwv eHM6c2ltcGxlVHlwZT4NCiAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICA8eHM6cmVzdHJp Y3Rpb24gYmFzZT0ieHM6c2hvcnQiPg0KICAgICAgICAgIDx4czptaW5JbmNsdXNpdmUgdmFsdWU9 IjEiLz4NCiAgICAgICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSIzMSIvPg0KICAgICAgICA8 L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgIDwveHM6dW5pb24+ DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJUaW1lWWVhckRh eVR5cGUiPg0KICAgIDx4czp1bmlvbj4NCiAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICA8 eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c2hvcnQiPg0KICAgICAgICAgIDx4czptaW5JbmNsdXNp dmUgdmFsdWU9Ii0zNjYiLz4NCiAgICAgICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSItMSIv Pg0KICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAg ICAgPHhzOnNpbXBsZVR5cGU+DQogICAgICAgIDx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzaG9y dCI+DQogICAgICAgICAgPHhzOm1pbkluY2x1c2l2ZSB2YWx1ZT0iMSIvPg0KICAgICAgICAgIDx4 czptYXhJbmNsdXNpdmUgdmFsdWU9IjM2NiIvPg0KICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPg0K ICAgICAgPC94czpzaW1wbGVUeXBlPg0KICAgIDwveHM6dW5pb24+DQogIDwveHM6c2ltcGxlVHlw ZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJQZXJjZW50VHlwZSI+DQogICAgPHhzOnJlc3Ry aWN0aW9uIGJhc2U9InhzOnNob3J0Ij4NCiAgICAgIDx4czptaW5JbmNsdXNpdmUgdmFsdWU9IjAi Lz4NCiAgICAgIDx4czptYXhJbmNsdXNpdmUgdmFsdWU9IjEwMCIvPg0KICAgIDwveHM6cmVzdHJp Y3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCg0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJQcmVk ZWZpbmVkQ2F0ZWdvcmllcyI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+ DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkFOTklWRVJTQVJZIi8+DQogICAgICA8eHM6 ZW51bWVyYXRpb24gdmFsdWU9IkFQUE9JTlRNRU5UIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24g dmFsdWU9IkJVU0lORVNTIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkVEVUNBVElP TiIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJIT0xJREFZIi8+DQogICAgICA8eHM6 ZW51bWVyYXRpb24gdmFsdWU9Ik1FRVRJTkciLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1 ZT0iTUlTQ0VMTEFORU9VUyIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJOT04tV09S S0lORyBIT1VSUyIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJOT1QgSU4gT0ZGSUNF Ii8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlBFUlNPTkFMIi8+DQogICAgICA8eHM6 ZW51bWVyYXRpb24gdmFsdWU9IlBIT05FIENBTEwiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2 YWx1ZT0iU0lDSyBEQVkiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iU1BFQ0lBTCBP Q0NBU0lPTiIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJUUkFWRUwiLz4NCiAgICAg IDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iVkFDQVRJT04iLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9u Pg0KICA8L3hzOnNpbXBsZVR5cGU+DQogIA0KICA8eHM6c2ltcGxlVHlwZSBuYW1lPSJQcmVkZWZp bmVkUmVzb3VyY2VzIj4NCiAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4NCiAg ICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQ0FURVJJTkciLz4NCiAgICAgIDx4czplbnVtZXJh dGlvbiB2YWx1ZT0iQ0hBSVJTIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNPTVBV VEVSIFBST0pFQ1RPUiIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJFQVNFTCIvPg0K ICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJPVkVSSEVBRCBQUk9KRUNUT1IiLz4NCiAgICAg IDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iU1BFQUtFUiBQSE9ORSIvPg0KICAgICAgPHhzOmVudW1l cmF0aW9uIHZhbHVlPSJUQUJMRSIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJUViIv Pg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJWQ1IiLz4NCiAgICAgIDx4czplbnVtZXJh dGlvbiB2YWx1ZT0iVklERU8gUEhPTkUiLz4NCiAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0i VkVISUNMRSIvPg0KICAgIDwveHM6cmVzdHJpY3Rpb24+DQogIDwveHM6c2ltcGxlVHlwZT4NCiAg DQo8L3hzOnNjaGVtYT4= ------_=_NextPart_001_01C5FF34.B87ED731-- 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 5677E7F576 for ; Thu, 8 Dec 2005 17:42:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F563142306 for ; Thu, 8 Dec 2005 17:42:24 -0800 (PST) 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 24136-02 for ; Thu, 8 Dec 2005 17:42:24 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 21D54142304 for ; Thu, 8 Dec 2005 17:42:24 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jB91gNJu005051 for ; Thu, 8 Dec 2005 17:42:23 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id BEFD6324002 for ; Thu, 8 Dec 2005 17:42:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ietf-caldav@osafoundation.org From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 8 Dec 2005 17:42:23 -0800 X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] ApacheCon lightning lottery talks 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: Fri, 09 Dec 2005 01:42:24 -0000 A lightning lottery talk (5 minutes) about CalDAV would be most welcome. If you are attending ApacheCon and would like to submit a topic (CalDAV or otherwise), find me at the conference at or before the start of the session. The session is a plenary on Tuesday at 7:30 PM. I'd volunteer but I'm hosting, so I should do a talk, and if I did a talk, it would be about the evils of XML elements in DAV properties. ;-) *duck* -wsv