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 18B117F74D for ; Thu, 29 Jun 2006 04:39:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0B3AC1422F2 for ; Thu, 29 Jun 2006 04:39:51 -0700 (PDT) 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 12640-06 for ; Thu, 29 Jun 2006 04:39:46 -0700 (PDT) Received: from male.aldigital.co.uk (male.thebunker.net [213.129.64.13]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6097B1422A2 for ; Thu, 29 Jun 2006 04:39:46 -0700 (PDT) Received: from [10.71.5.45] (unknown [66.251.110.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by male.aldigital.co.uk (Postfix) with ESMTP id 5C3F8976FC for ; Thu, 29 Jun 2006 12:39:44 +0100 (BST) Message-ID: <44A3BBD4.4020608@thebunker.net> Date: Thu, 29 Jun 2006 12:39:00 +0100 From: Adam Laurie User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] What happened to the CalDav website? 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.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-Mailman-Approved-At: Sun, 02 Jul 2006 21:31:00 -0700 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, 29 Jun 2006 11:39:51 -0000 For the past couple of weeks I've been trying to find a download with no joy... All URLS previously mentioned appear to be down: http://ietf.cse.ucsc.edu/caldav http://caldav.org/ http://www.caldav.org/ http://ietf.webdav.org/caldav/ Is there CVS or some other access, or is the distribution site likely to come back any time soon? BTW, please copy me on replies - I'm not subscribed to this list. cheers, Adam -- Adam Laurie Tel: +44 (0) 1304 814800 The Bunker Secure Hosting Ltd. Fax: +44 (0) 1304 814899 Ash Radar Station http://www.thebunker.net Marshborough Road Sandwich mailto:adam@thebunker.net Kent CT13 0PL UNITED KINGDOM PGP key on keyservers 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 3F9BE7F77E for ; Mon, 26 Jun 2006 16:16:47 -0700 (PDT) Received: from [192.168.1.100] (unknown [86.42.130.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 46A121422A5; Mon, 26 Jun 2006 16:16:46 -0700 (PDT) In-Reply-To: <20060626222310.13183.qmail@web509.biz.mail.mud.yahoo.com> References: <20060626222310.13183.qmail@web509.biz.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Global Address Book Date: Tue, 27 Jun 2006 00:16:38 +0100 To: "Kervin L. Pierre" X-Mailer: Apple Mail (2.750) 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, 26 Jun 2006 23:16:47 -0000 On Jun 26, 2006, at 11:23 PM, Kervin L. Pierre wrote: > > We did not want to introduce LDAP as a > dependency for using the client, but would > like to provide a global address book. So far it sounds to me like you can rely on the WebDAV Principal namespace for that purpose. That may of course not be available in all situations, because it can be a matter of configuration how much of that is readable/searchable and to whom, but in the situations where there's no access to the principal namespace you wouldn't be getting access to that information anyway. So for good interoperability, your client would attempt to get this global address book through the principal namespace, but not fail badly if searching/listing were disallowed. 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 534F97F8C6 for ; Mon, 26 Jun 2006 15:23:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 446531422C5 for ; Mon, 26 Jun 2006 15:23:12 -0700 (PDT) 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 10773-09 for ; Mon, 26 Jun 2006 15:23:11 -0700 (PDT) Received: from web509.biz.mail.mud.yahoo.com (web509.biz.mail.mud.yahoo.com [209.191.86.220]) by laweleka.osafoundation.org (Postfix) with SMTP id 45F061422C2 for ; Mon, 26 Jun 2006 15:23:11 -0700 (PDT) Received: (qmail 13185 invoked by uid 60001); 26 Jun 2006 22:23:10 -0000 Message-ID: <20060626222310.13183.qmail@web509.biz.mail.mud.yahoo.com> Received: from [163.118.10.164] by web509.biz.mail.mud.yahoo.com via HTTP; Mon, 26 Jun 2006 15:23:10 PDT Date: Mon, 26 Jun 2006 15:23:10 -0700 (PDT) From: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] CalDAV Global Address Book To: Cyrus Daboo , Julian Reschke In-Reply-To: <7B85FBDD321CD801726D3878@Cyrus-Daboo.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.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: Mon, 26 Jun 2006 22:23:13 -0000 Hello Group, --- Cyrus Daboo wrote: > > What's wrong with simply putting calendar attributes > in the organization's > directory? Nothing at all, but the organization may not have an organizational directory or someone who can administer one. Keep in mind, that this issue is resolved by adding a 'default calendar' property on the principal. We did not want to introduce LDAP as a dependency for using the client, but would like to provide a global address book. The next option is to have the user provide a default calendar name to try, or choose one for them. A bit of a hack, but seems preferable to requiring LDAP. Also note that a CalDAV GAB is not meant to replace a LDAP GAB, but to provide base functionality so that administering a LDAP server is optional. > when there will likely be a directory that will > contain all the other > useful communication related attributes too (email, > im, web page etc). If > the directory is sufficient, then RFC 2739 defines a > set of attributes that can be used. It's a useful dependency, I agree, but I don't think it should be manatory for GAB functionality. > Well, a client could expose the calendar hierarchy > and allow users to > browse that - that is what I did in Mulberry and > matches the UI we had for > browsing shared mailboxes on the email side. The > client can offer searching > on that if it wanted - no need to go to principals. > The calendar collections for a single organization may exist on separate servers. Also, I think the calendar browsing scheme is too complicated for the types of users we run into. But this is a judgement call. Many people are easily confused by URLS, folder hierarchies, etc. We'd like to offer them a simple list of names in the organization; if they have permission to view that list. > The purpose of the SRV is to allow outside users to > locate a CalAV server I understand, thanks. At any rate, consider adding the ability to add a 'default calendar' URL to the principal. That's how MAPI does it, so there is some 'precedence' if that matters. It would allow a principal<->calendar, 1-to-1 relationship that simple clients can use to simplify interaction with the CalDAV server. 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 1F15A7F8C9 for ; Mon, 26 Jun 2006 08:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 10CD71422D0 for ; Mon, 26 Jun 2006 08:07:21 -0700 (PDT) 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 08737-03 for ; Mon, 26 Jun 2006 08:07:20 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BF041422C5 for ; Mon, 26 Jun 2006 08:07:20 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 024ECD87886; Mon, 26 Jun 2006 11:07:19 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Mon, 26 Jun 2006 11:07:19 -0400 X-Sasl-enc: ulbnhdtSyPWb8bFKSISNAVDOaDMNP3xGPDT90Uywpnpt 1151334439 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 79F446504; Mon, 26 Jun 2006 11:07:18 -0400 (EDT) Date: Mon, 26 Jun 2006 11:07:14 -0400 From: Cyrus Daboo To: "Kervin L. Pierre" , Julian Reschke Subject: Re: [Ietf-caldav] CalDAV Global Address Book Message-ID: <7B85FBDD321CD801726D3878@Cyrus-Daboo.local> In-Reply-To: <20060626145100.46080.qmail@web513.biz.mail.mud.yahoo.com> References: <20060626145100.46080.qmail@web513.biz.mail.mud.yahoo.com> X-Mailer: Mulberry/4.0.5 (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.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, 26 Jun 2006 15:07:21 -0000 Hi Kervin, --On June 26, 2006 7:51:00 AM -0700 "Kervin L. Pierre" wrote: >> There are situations where access to the principal >> hierarchy may be denied >> entirely (whether directly or by a REPORT). For >> example, consider an ISP > > That is true. What about department or > organizational servers? Is denying authenticated > users access to the principal hierarchy common? > Is it some sought of best practise? > > If it is not then we can take our chances and > simply list that permission as a prequisite for > using the CalDAV global address book. What's wrong with simply putting calendar attributes in the organization's directory? Having a 'special' address book just for CalDAV seems silly, when there will likely be a directory that will contain all the other useful communication related attributes too (email, im, web page etc). If the directory is sufficient, then RFC 2739 defines a set of attributes that can be used. >> Question: is your intent here to have a general way >> to find anybody's >> calendar given some identifier? > > Exactly. And to also return a list of everybody > in the organization ( or more precisely on the > server ), that has a calendar ( ie. Browse users ). Again - a proper directory is a better bet. > Basically how Microsoft Outlook shares calendars... > > (i) Type in a term > (ii) Get a list of principal matches > (iii) Click on a match to retrieve that calendar > Or > (i) Browse the Global Address Book > (ii) Select the principal you need > (iii) Click on their row to retrieve their calendar > > Btw. That is probably how most clients are going > to share calendars, I'd wager. Well, a client could expose the calendar hierarchy and allow users to browse that - that is what I did in Mulberry and matches the UI we had for browsing shared mailboxes on the email side. The client can offer searching on that if it wanted - no need to go to principals. >> Do you actually want >> their calendar as >> opposed to wanting to do scheduling operations with >> them (as in free-busy >> lookups, booking meetings etc)? > > We need the calendar, definitely. This is used > for delegating calendar duties to secretaries, > browsing a colleague's schedule, etc. OK. >> gone on in Calconnect. Right now the feeling is that >> there needs to be a >> new 'scheduleto' URI scheme with appropriate lookup >> rules (SRV records) to >> find the calendar service for a particular address. > > This seems to be slightly different from what > we're doing, if I am not mistaken, but please > correct me if I am wrong... > > A SRV record will be useful in providing the > appropriate CalDAV server given a principle > or a domain. Eg. Answering "Where is example.com's > CalDAV server" with "It's cal.example.com". > > But after the client initiates the session > with cal.example.com, it still doesn't know > where the user's 'primary' calendar is. > And it still can't provide the user with a > list of available principals. Correct? The purpose of the SRV is to allow outside users to locate a CalAV server that supports the calendar-schedule feature so that they can carry out scheduling operations. That does not expose individual user calendars within the organization - merely a 'public' URL to which calendar-schedule requests can be sent and response returned. Scheduling like that is more likely to be what people want to do for their personal calendars - i.e. not expose those to anyone on the outside but allow them to schedule. Discovery of actual 'public' calendars is a slightly different issue and does need to be addressed in some fashion. Various possibilities for that have been mentioned, including use of ATOM feeds etc. Of course a similar type of problem exists for discovering public mailing lists - that is usually addressed by simply having a webpage listing them with links to initiate subscription etc. -- 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 A13CA7F780 for ; Mon, 26 Jun 2006 07:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 918841422D4 for ; Mon, 26 Jun 2006 07:51:01 -0700 (PDT) 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 05568-06 for ; Mon, 26 Jun 2006 07:51:00 -0700 (PDT) Received: from web513.biz.mail.mud.yahoo.com (web513.biz.mail.mud.yahoo.com [209.191.86.224]) by laweleka.osafoundation.org (Postfix) with SMTP id BF6111422D0 for ; Mon, 26 Jun 2006 07:51:00 -0700 (PDT) Received: (qmail 46082 invoked by uid 60001); 26 Jun 2006 14:51:00 -0000 Message-ID: <20060626145100.46080.qmail@web513.biz.mail.mud.yahoo.com> Received: from [12.8.36.251] by web513.biz.mail.mud.yahoo.com via HTTP; Mon, 26 Jun 2006 07:51:00 PDT Date: Mon, 26 Jun 2006 07:51:00 -0700 (PDT) From: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] CalDAV Global Address Book To: Cyrus Daboo , Julian Reschke In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: 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, 26 Jun 2006 14:51:01 -0000 Hello, --- Cyrus Daboo wrote: > There are situations where access to the principal > hierarchy may be denied > entirely (whether directly or by a REPORT). For > example, consider an ISP That is true. What about department or organizational servers? Is denying authenticated users access to the principal hierarchy common? Is it some sought of best practise? If it is not then we can take our chances and simply list that permission as a prequisite for using the CalDAV global address book. > Question: is your intent here to have a general way > to find anybody's > calendar given some identifier? Exactly. And to also return a list of everybody in the organization ( or more precisely on the server ), that has a calendar ( ie. Browse users ). Basically how Microsoft Outlook shares calendars... (i) Type in a term (ii) Get a list of principal matches (iii) Click on a match to retrieve that calendar Or (i) Browse the Global Address Book (ii) Select the principal you need (iii) Click on their row to retrieve their calendar Btw. That is probably how most clients are going to share calendars, I'd wager. > Do you actually want > their calendar as > opposed to wanting to do scheduling operations with > them (as in free-busy > lookups, booking meetings etc)? We need the calendar, definitely. This is used for delegating calendar duties to secretaries, browsing a colleague's schedule, etc. > gone on in Calconnect. Right now the feeling is that > there needs to be a > new 'scheduleto' URI scheme with appropriate lookup > rules (SRV records) to > find the calendar service for a particular address. This seems to be slightly different from what we're doing, if I am not mistaken, but please correct me if I am wrong... A SRV record will be useful in providing the appropriate CalDAV server given a principle or a domain. Eg. Answering "Where is example.com's CalDAV server" with "It's cal.example.com". But after the client initiates the session with cal.example.com, it still doesn't know where the user's 'primary' calendar is. And it still can't provide the user with a list of available principals. Correct? 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 1AF3E7F8D0; Mon, 26 Jun 2006 07:01:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C1021422BE; Mon, 26 Jun 2006 07:01:24 -0700 (PDT) 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 31985-01; Mon, 26 Jun 2006 07:01:22 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 725E71422BC; Mon, 26 Jun 2006 07:01:22 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 69D80E0079; Mon, 26 Jun 2006 10:01:27 -0400 (EDT) From: Sam Hartman To: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@gmx.de> <7B5034F2-49E9-4B5B-B27C-A153F0F8EF5A@osafoundation.org> Date: Mon, 26 Jun 2006 10:01:27 -0400 In-Reply-To: <7B5034F2-49E9-4B5B-B27C-A153F0F8EF5A@osafoundation.org> (Lisa Dusseault's message of "Fri, 23 Jun 2006 14:40:03 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-Mailman-Approved-At: Mon, 26 Jun 2006 12:40:33 -0700 Cc: The IESG , 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, 26 Jun 2006 14:01:24 -0000 >>>>> "Lisa" == Lisa Dusseault writes: Lisa> Context: whether CalDAV should mandate clients supporting Lisa> TLS in order to provide at least one encrypted transport Lisa> over which plain- text passwords might be used. Yes or wait for a revision of HTTP. 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 DE3247F8D0 for ; Mon, 26 Jun 2006 06:59:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CEA131422BE for ; Mon, 26 Jun 2006 06:59:22 -0700 (PDT) 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 20283-04 for ; Mon, 26 Jun 2006 06:59:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id E2FCF1422BC for ; Mon, 26 Jun 2006 06:59:21 -0700 (PDT) Received: (qmail invoked by alias); 26 Jun 2006 13:59:20 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 26 Jun 2006 15:59:20 +0200 X-Authenticated: #1915285 Message-ID: <449FE836.1090801@gmx.de> Date: Mon, 26 Jun 2006 15:59:18 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] CalDAV Global Address Book References: <449F4BA2.3070700@adevsoft.com> <449F880F.100@gmx.de> <449FE0FC.8080400@gmx.de> <0BE212D478C92F354450DA37@Cyrus-Daboo.local> In-Reply-To: <0BE212D478C92F354450DA37@Cyrus-Daboo.local> 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.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: Mon, 26 Jun 2006 13:59:23 -0000 Cyrus Daboo schrieb: > Hi Julian, > > --On June 26, 2006 3:28:28 PM +0200 Julian Reschke > wrote: > >> Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to >> define new URI schemes, unless none of the existing schemes would work. >> Why wouldn't http be sufficient? Did you consider defining a MIME type >> (holding the information in the content), or a link relation? > > Yup - we did have arguments for all of this and a new scheme came out as > the best choice for a number of reasons. Obviously there is a high > barrier for defining new schemes so we will have to fully justify this > if we do end up doing it and writing a spec for it. Well, there's a barrier for a reason. It would be nice if somebody could summarize over here what actual problem needs to be solved, and which alternatives have been discussed. 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 A2C937F8C7 for ; Mon, 26 Jun 2006 06:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 94A0A1422C2 for ; Mon, 26 Jun 2006 06:53:52 -0700 (PDT) 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 19619-09 for ; Mon, 26 Jun 2006 06:53:52 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C1FA1422BE for ; Mon, 26 Jun 2006 06:53:52 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 3306FD87B61; Mon, 26 Jun 2006 09:53:51 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Mon, 26 Jun 2006 09:53:51 -0400 X-Sasl-enc: 1ONKjzr+5eRK1li1XhH4ZWqJHIvAKFYccLGciBYbZwwa 1151330031 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 7F4415E37; Mon, 26 Jun 2006 09:53:49 -0400 (EDT) Date: Mon, 26 Jun 2006 09:53:48 -0400 From: Cyrus Daboo To: Julian Reschke Subject: Re: [Ietf-caldav] CalDAV Global Address Book Message-ID: <0BE212D478C92F354450DA37@Cyrus-Daboo.local> In-Reply-To: <449FE0FC.8080400@gmx.de> References: <449F4BA2.3070700@adevsoft.com> <449F880F.100@gmx.de> <449FE0FC.8080400@gmx.de> X-Mailer: Mulberry/4.0.5 (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.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, 26 Jun 2006 13:53:52 -0000 Hi Julian, --On June 26, 2006 3:28:28 PM +0200 Julian Reschke wrote: > Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to > define new URI schemes, unless none of the existing schemes would work. > Why wouldn't http be sufficient? Did you consider defining a MIME type > (holding the information in the content), or a link relation? Yup - we did have arguments for all of this and a new scheme came out as the best choice for a number of reasons. Obviously there is a high barrier for defining new schemes so we will have to fully justify this if we do end up doing it and writing a spec for it. -- 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 D47A77F788 for ; Mon, 26 Jun 2006 06:28:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C682C1422D6 for ; Mon, 26 Jun 2006 06:28:35 -0700 (PDT) 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 26906-04 for ; Mon, 26 Jun 2006 06:28:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id C0F4B1422C5 for ; Mon, 26 Jun 2006 06:28:33 -0700 (PDT) Received: (qmail invoked by alias); 26 Jun 2006 13:28:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 26 Jun 2006 15:28:31 +0200 X-Authenticated: #1915285 Message-ID: <449FE0FC.8080400@gmx.de> Date: Mon, 26 Jun 2006 15:28:28 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] CalDAV Global Address Book References: <449F4BA2.3070700@adevsoft.com> <449F880F.100@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.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: Mon, 26 Jun 2006 13:28:36 -0000 Cyrus Daboo schrieb: > Hi Kervin, > > --On June 26, 2006 9:09:03 AM +0200 Julian Reschke > wrote: > >>> (i) Is it reasonable to assume that the principal >>> collection would allow listing? In my current >>> testing this has been the case. Ie. Are we >>> going to incur the wrath of Sys. Admins. because >>> we assumed that users are allowed to list this >>> collection? ( I am hoping someone more familiar >>> with WebDAV ACL can clarify this ) >> >> No, in general you can't assume that listing will work, as the >> collections may be very (very!) big. >> >> But the DAV:principal-property-search REPORT may help here >> (). > > There are situations where access to the principal hierarchy may be > denied entirely (whether directly or by a REPORT). For example, consider > an ISP running a caldav server - they are very unlikely to want to > expose their customer list (list of users) to everyone either outsiders > or customers. > > Question: is your intent here to have a general way to find anybody's > calendar given some identifier? Do you actually want their calendar as > opposed to wanting to do scheduling operations with them (as in > free-busy lookups, booking meetings etc)? If this is what you want to do > then there have been several discussions of 'calendar user > discoverability' that have gone on in Calconnect. Right now the feeling > is that there needs to be a new 'scheduleto' URI scheme with appropriate > lookup rules (SRV records) to find the calendar service for a particular > address. Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to define new URI schemes, unless none of the existing schemes would work. Why wouldn't http be sufficient? Did you consider defining a MIME type (holding the information in the content), or a link relation? 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 6EDBE7F8BD for ; Mon, 26 Jun 2006 06:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5FC321422C5 for ; Mon, 26 Jun 2006 06:16:21 -0700 (PDT) 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 19619-01 for ; Mon, 26 Jun 2006 06:16:18 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id B5D081422AE for ; Mon, 26 Jun 2006 06:16:18 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id A11DBD8779B; Mon, 26 Jun 2006 09:16:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Mon, 26 Jun 2006 09:16:18 -0400 X-Sasl-enc: 4727sAFH7Xekbxo0pHFC8Yk7DGIQrn3IuHxlzZk+E77X 1151327777 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 6809F6589; Mon, 26 Jun 2006 09:16:16 -0400 (EDT) Date: Mon, 26 Jun 2006 09:16:13 -0400 From: Cyrus Daboo To: Julian Reschke , "Kervin L. Pierre" Subject: Re: [Ietf-caldav] CalDAV Global Address Book Message-ID: In-Reply-To: <449F880F.100@gmx.de> References: <449F4BA2.3070700@adevsoft.com> <449F880F.100@gmx.de> X-Mailer: Mulberry/4.0.5 (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.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, 26 Jun 2006 13:16:21 -0000 Hi Kervin, --On June 26, 2006 9:09:03 AM +0200 Julian Reschke wrote: >> (i) Is it reasonable to assume that the principal >> collection would allow listing? In my current >> testing this has been the case. Ie. Are we >> going to incur the wrath of Sys. Admins. because >> we assumed that users are allowed to list this >> collection? ( I am hoping someone more familiar >> with WebDAV ACL can clarify this ) > > No, in general you can't assume that listing will work, as the > collections may be very (very!) big. > > But the DAV:principal-property-search REPORT may help here > (). There are situations where access to the principal hierarchy may be denied entirely (whether directly or by a REPORT). For example, consider an ISP running a caldav server - they are very unlikely to want to expose their customer list (list of users) to everyone either outsiders or customers. Question: is your intent here to have a general way to find anybody's calendar given some identifier? Do you actually want their calendar as opposed to wanting to do scheduling operations with them (as in free-busy lookups, booking meetings etc)? If this is what you want to do then there have been several discussions of 'calendar user discoverability' that have gone on in Calconnect. Right now the feeling is that there needs to be a new 'scheduleto' URI scheme with appropriate lookup rules (SRV records) to find the calendar service for a particular address. -- 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 0AC717F79B for ; Mon, 26 Jun 2006 00:09:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF8691422C5 for ; Mon, 26 Jun 2006 00:09:16 -0700 (PDT) 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 07005-05 for ; Mon, 26 Jun 2006 00:09:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 0200D1422BE for ; Mon, 26 Jun 2006 00:09:13 -0700 (PDT) Received: (qmail invoked by alias); 26 Jun 2006 07:09:12 -0000 Received: from p508FC298.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.194.152] by mail.gmx.net (mp036) with SMTP; 26 Jun 2006 09:09:12 +0200 X-Authenticated: #1915285 Message-ID: <449F880F.100@gmx.de> Date: Mon, 26 Jun 2006 09:09:03 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] CalDAV Global Address Book References: <449F4BA2.3070700@adevsoft.com> In-Reply-To: <449F4BA2.3070700@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.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: Mon, 26 Jun 2006 07:09:17 -0000 Kervin L. Pierre schrieb: > Hello Group, > > Has the issue of providing a Global Address Book > for CalDAV users come up yet? > > It seems that if a user provides the WebDAV ACL > base URL. eg. > http://cal.example.com/principals/individuals/ > > A CalDAV client can provide a Global Address Book > to its user by... > (i) first listing the principals in that > collection at that URL. > (ii) then rendering using the returned > displayname > (iii) and accessing using the calendar-home-set > property. > > There are issues surrounding this though... > > (i) Is it reasonable to assume that the principal > collection would allow listing? In my current > testing this has been the case. Ie. Are we > going to incur the wrath of Sys. Admins. because > we assumed that users are allowed to list this > collection? ( I am hoping someone more familiar > with WebDAV ACL can clarify this ) No, in general you can't assume that listing will work, as the collections may be very (very!) big. But the DAV:principal-property-search REPORT may help here (). > ... 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 CA8177F576 for ; Sun, 25 Jun 2006 19:48:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BB8451422A3 for ; Sun, 25 Jun 2006 19:48:54 -0700 (PDT) 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 00406-03 for ; Sun, 25 Jun 2006 19:48:53 -0700 (PDT) Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by laweleka.osafoundation.org (Postfix) with SMTP id E1C57142294 for ; Sun, 25 Jun 2006 19:48:52 -0700 (PDT) Received: (qmail 9067 invoked from network); 26 Jun 2006 02:48:52 -0000 Received: from unknown (HELO ?192.168.1.3?) (kervin@adevsoft.com@72.156.251.193 with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 26 Jun 2006 02:48:52 -0000 Message-ID: <449F4BA2.3070700@adevsoft.com> Date: Sun, 25 Jun 2006 22:51:14 -0400 From: "Kervin L. Pierre" Organization: Adevsoft Inc User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: CalDAV DevList 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.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-caldav] CalDAV Global Address Book 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, 26 Jun 2006 02:48:54 -0000 Hello Group, Has the issue of providing a Global Address Book for CalDAV users come up yet? It seems that if a user provides the WebDAV ACL base URL. eg. http://cal.example.com/principals/individuals/ A CalDAV client can provide a Global Address Book to its user by... (i) first listing the principals in that collection at that URL. (ii) then rendering using the returned displayname (iii) and accessing using the calendar-home-set property. There are issues surrounding this though... (i) Is it reasonable to assume that the principal collection would allow listing? In my current testing this has been the case. Ie. Are we going to incur the wrath of Sys. Admins. because we assumed that users are allowed to list this collection? ( I am hoping someone more familiar with WebDAV ACL can clarify this ) (ii) How are server developers dealing with setting calendar-home-set ? This property is listed as a MAY. The spec says this can be a calendar collection, or a regular collection with a calendar descendant. This is going to make clients lives a little harder. Maybe the spec should decide on one approach. Currently I see Oracle is pointing to a calendar, this works perfectly for us because users are going to want to put in a principal and get a calendar in return I suspect. Just as they do with current calendar applications, eg. Outlook. Hence... (iii) I think we need a way to specify a 'default' or 'main' calendar. If a 'default calendar' property is not desirable, the spec should suggest a default calendar collection name. Just as webservers look for 'index.html' if they are configured to do so. So if the client finds that calendar-home-set points to an ordinary collection, it may ask for the 'main' collection under that and see if that is a calendar. The ultimate goal is, given a principle, the client can ultimately retrieve a calendar. 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 685547F7C1 for ; Fri, 23 Jun 2006 15:20:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 588D814230B for ; Fri, 23 Jun 2006 15:20:09 -0700 (PDT) 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 06505-01 for ; Fri, 23 Jun 2006 15:20:07 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id A786D142306 for ; Fri, 23 Jun 2006 15:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 37E773D0362; Sat, 24 Jun 2006 00:19:05 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-243-166.reverse.mdcc-fun.de [213.211.243.166]) by mail.mdlink.net (Postfix) with ESMTP id CC7A0402392; Sat, 24 Jun 2006 00:19:04 +0200 (CEST) In-Reply-To: <449C44A3.5060404@gmx.de> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@gmx.de> <449C44A3.5060404@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <373429CA-4173-48B7-8EBD-88D511CA1B05@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Sat, 24 Jun 2006 00:19:49 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) 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: The IESG 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 Jun 2006 22:20:09 -0000 On Jun 23, 2006, at 21:44, Julian Reschke wrote: > The point I'm trying to make is that if CalDAV and WebDAV share the > same security requirements, they optimally should say the same > thing. As CalDAV already normatively refers to RFC2518bis, this > means it doesn't need to say anything about it all. Definitely +1. Why should CalDAV be different to WebDAV/HTTP? Helge 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 AA37C7F946 for ; Fri, 23 Jun 2006 14:40:14 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7415D1422F9; Fri, 23 Jun 2006 14:40:14 -0700 (PDT) In-Reply-To: References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B5034F2-49E9-4B5B-B27C-A153F0F8EF5A@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 14:40:03 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.750) Cc: The IESG , 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 Jun 2006 21:40:14 -0000 Context: whether CalDAV should mandate clients supporting TLS in order to provide at least one encrypted transport over which plain- text passwords might be used. Lisa On Jun 23, 2006, at 2:36 PM, Sam Hartman wrote: >>>>>> "Julian" == Julian Reschke writes: > > Julian> Lisa Dusseault schrieb: >>> ... It would indeed be better to solve it in the base spec if >>> we had time and resources. Mark Nottingham is holding a bar >>> BOF in Montreal to see if there's interest in making some >>> updates to HTTP, which might include this. But since that's >>> such a long-term approach, I don't think it's the right thing >>> to wait for here, nor is it the right thing to leave decent >>> security optional. Thus, I don't agree with your opinion on >>> this, but you're welcome to attempt to argue it with the IESG >>> (iesg@ietf.org) or the Security directorate (secdir@mit.edu). >>> ... >> > I'm missing what this is all about? Etag? If so, how does that have > to do with security? > Something else? > 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 CF8477F929; Fri, 23 Jun 2006 14:36:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C0D441422FE; Fri, 23 Jun 2006 14:36:29 -0700 (PDT) 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 29225-09; Fri, 23 Jun 2006 14:36:27 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 48B691422F9; Fri, 23 Jun 2006 14:36:27 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B821DE0079; Fri, 23 Jun 2006 17:36:25 -0400 (EDT) From: Sam Hartman To: Julian Reschke Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@gmx.de> Date: Fri, 23 Jun 2006 17:36:25 -0400 In-Reply-To: <449C411F.2090906@gmx.de> (Julian Reschke's message of "Fri, 23 Jun 2006 21:29:35 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-Mailman-Approved-At: Mon, 26 Jun 2006 12:40:33 -0700 Cc: The IESG , 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 Jun 2006 21:36:29 -0000 >>>>> "Julian" == Julian Reschke writes: Julian> Lisa Dusseault schrieb: >> ... It would indeed be better to solve it in the base spec if >> we had time and resources. Mark Nottingham is holding a bar >> BOF in Montreal to see if there's interest in making some >> updates to HTTP, which might include this. But since that's >> such a long-term approach, I don't think it's the right thing >> to wait for here, nor is it the right thing to leave decent >> security optional. Thus, I don't agree with your opinion on >> this, but you're welcome to attempt to argue it with the IESG >> (iesg@ietf.org) or the Security directorate (secdir@mit.edu). >> ... > I'm missing what this is all about? Etag? If so, how does that have to do with security? Something else? 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 4E5957F962 for ; Fri, 23 Jun 2006 12:44:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F0D214230B for ; Fri, 23 Jun 2006 12:44:43 -0700 (PDT) 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 17676-01 for ; Fri, 23 Jun 2006 12:44:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 3BEB11422FE for ; Fri, 23 Jun 2006 12:44:42 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 19:44:41 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp027) with SMTP; 23 Jun 2006 21:44:41 +0200 X-Authenticated: #1915285 Message-ID: <449C44A3.5060404@gmx.de> Date: Fri, 23 Jun 2006 21:44:35 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: The IESG , 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 Jun 2006 19:44:43 -0000 Lisa Dusseault schrieb: > > On Jun 23, 2006, at 12:29 PM, Julian Reschke wrote: > >> Lisa Dusseault schrieb: >>> ... >>> It would indeed be better to solve it in the base spec if we had time >>> and resources. Mark Nottingham is holding a bar BOF in Montreal to >>> see if there's interest in making some updates to HTTP, which might >>> include this. But since that's such a long-term approach, I don't >>> think it's the right thing to wait for here, nor is it the right >>> thing to leave decent security optional. >>> Thus, I don't agree with your opinion on this, but you're welcome to >>> attempt to argue it with the IESG (iesg@ietf.org) or the Security >>> directorate (secdir@mit.edu). >>> ... >> >> OK, let's try a very simple question: >> >> How are the security requirements for CalDAV different from those for >> WebDAV? > > It's not. WebDAV makes the same requirement, with the exception of not > making TLS the mandatory-to-implement mechanism. CalDAV simply goes a > step further in ensuring interoperability, in addition to security. > > Would you propose updating RFC2518bis to make TLS mandatory? The point I'm trying to make is that if CalDAV and WebDAV share the same security requirements, they optimally should say the same thing. As CalDAV already normatively refers to RFC2518bis, this means it doesn't need to say anything about it all. I'm not a security expert. But if the experts think that what RFC2518bis currently says isn't sufficient, then yes, it should be updated. 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 C57A57F94B for ; Fri, 23 Jun 2006 12:37:43 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A02AE1422FE; Fri, 23 Jun 2006 12:37:43 -0700 (PDT) In-Reply-To: <449C411F.2090906@gmx.de> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> <449C411F.2090906@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 12:37:37 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) Cc: The IESG , 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 Jun 2006 19:37:43 -0000 On Jun 23, 2006, at 12:29 PM, Julian Reschke wrote: > Lisa Dusseault schrieb: >> ... >> It would indeed be better to solve it in the base spec if we had >> time and resources. Mark Nottingham is holding a bar BOF in >> Montreal to see if there's interest in making some updates to >> HTTP, which might include this. But since that's such a long-term >> approach, I don't think it's the right thing to wait for here, nor >> is it the right thing to leave decent security optional. >> Thus, I don't agree with your opinion on this, but you're welcome >> to attempt to argue it with the IESG (iesg@ietf.org) or the >> Security directorate (secdir@mit.edu). >> ... > > OK, let's try a very simple question: > > How are the security requirements for CalDAV different from those > for WebDAV? It's not. WebDAV makes the same requirement, with the exception of not making TLS the mandatory-to-implement mechanism. CalDAV simply goes a step further in ensuring interoperability, in addition to security. Would you propose updating RFC2518bis to make TLS mandatory? 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 110A67F95F for ; Fri, 23 Jun 2006 12:29:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 02A45142309 for ; Fri, 23 Jun 2006 12:29:45 -0700 (PDT) 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 14732-03 for ; Fri, 23 Jun 2006 12:29:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 09B611422F9 for ; Fri, 23 Jun 2006 12:29:42 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 19:29:40 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp012) with SMTP; 23 Jun 2006 21:29:40 +0200 X-Authenticated: #1915285 Message-ID: <449C411F.2090906@gmx.de> Date: Fri, 23 Jun 2006 21:29:35 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> In-Reply-To: <0ED97199-8D42-48D0-81C2-7248B9B52152@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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: The IESG , 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 Jun 2006 19:29:45 -0000 Lisa Dusseault schrieb: > ... > It would indeed be better to solve it in the base spec if we had time > and resources. Mark Nottingham is holding a bar BOF in Montreal to see > if there's interest in making some updates to HTTP, which might include > this. But since that's such a long-term approach, I don't think it's > the right thing to wait for here, nor is it the right thing to leave > decent security optional. > > Thus, I don't agree with your opinion on this, but you're welcome to > attempt to argue it with the IESG (iesg@ietf.org) or the Security > directorate (secdir@mit.edu). > ... OK, let's try a very simple question: How are the security requirements for CalDAV different from those for WebDAV? If they are the same, CalDAV should just refer to RFC2518bis. If you think they aren't, please explain how. Best regards, Julian (yes, iesg@ietf.org copied) 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 A3B437F95F for ; Fri, 23 Jun 2006 12:08:29 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E54D1422F9; Fri, 23 Jun 2006 12:08:29 -0700 (PDT) In-Reply-To: <449C314F.8010209@gmx.de> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> <449C314F.8010209@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0ED97199-8D42-48D0-81C2-7248B9B52152@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 12:08:19 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) 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 Jun 2006 19:08:29 -0000 On Jun 23, 2006, at 11:22 AM, Julian Reschke wrote: > Lisa Dusseault schrieb: >> I answered too fast and forgot one important point: a single, >> mandatory-to-implement secure transport is necessary to have both >> interoperability and to meet the "no plain-text passwords in the >> clear" requirement. If a server supported only IPSec and a client >> supported only TLS, that would not be interoperable. I find TLS >> to be the preferable mandatory-to-implement solution. >> It looks like our text could still do with some improvement >> however; something along the lines of "Servers MUST NOT offer >> BASIC over an unprotected channel. Clients MUST support TLS in >> order to provide one channel-encryption mechanism that servers can >> rely on if they decide to offer BASIC." >> ... > > I really think it's an extremely bad idea if each protocol that > happens to use HTTP as transport comes with it's own requirements > here. This is an issue which is common to WebDAV itself, CalDav, > AtomPub and so on. > > Are you saying that the IESG expects the authors of each of these > specs to come up with their own solution? > > If this problem really requires attention, it should be solved in a > base spec others can rely on. It definitively doesn't belong into > CalDAV (why would it have security requirements different from > those in WebDAV, for instance???). > It would indeed be better to solve it in the base spec if we had time and resources. Mark Nottingham is holding a bar BOF in Montreal to see if there's interest in making some updates to HTTP, which might include this. But since that's such a long-term approach, I don't think it's the right thing to wait for here, nor is it the right thing to leave decent security optional. Thus, I don't agree with your opinion on this, but you're welcome to attempt to argue it with the IESG (iesg@ietf.org) or the Security directorate (secdir@mit.edu). 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 B3E447F87C for ; Fri, 23 Jun 2006 11:22:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A55D01422F9 for ; Fri, 23 Jun 2006 11:22:15 -0700 (PDT) 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 04571-01 for ; Fri, 23 Jun 2006 11:22:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 8E41B1422ED for ; Fri, 23 Jun 2006 11:22:13 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 18:22:12 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp041) with SMTP; 23 Jun 2006 20:22:12 +0200 X-Authenticated: #1915285 Message-ID: <449C314F.8010209@gmx.de> Date: Fri, 23 Jun 2006 20:22:07 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> In-Reply-To: <71692780-6177-4023-8749-71DCA6960B7B@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.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, 23 Jun 2006 18:22:15 -0000 Lisa Dusseault schrieb: > I answered too fast and forgot one important point: a single, > mandatory-to-implement secure transport is necessary to have both > interoperability and to meet the "no plain-text passwords in the clear" > requirement. If a server supported only IPSec and a client supported > only TLS, that would not be interoperable. I find TLS to be the > preferable mandatory-to-implement solution. > > It looks like our text could still do with some improvement however; > something along the lines of "Servers MUST NOT offer BASIC over an > unprotected channel. Clients MUST support TLS in order to provide one > channel-encryption mechanism that servers can rely on if they decide to > offer BASIC." > > ... I really think it's an extremely bad idea if each protocol that happens to use HTTP as transport comes with it's own requirements here. This is an issue which is common to WebDAV itself, CalDav, AtomPub and so on. Are you saying that the IESG expects the authors of each of these specs to come up with their own solution? If this problem really requires attention, it should be solved in a base spec others can rely on. It definitively doesn't belong into CalDAV (why would it have security requirements different from those in WebDAV, for instance???). 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 DA6127F881 for ; Fri, 23 Jun 2006 11:07:13 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B63DC1422D5; Fri, 23 Jun 2006 11:07:13 -0700 (PDT) In-Reply-To: <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71692780-6177-4023-8749-71DCA6960B7B@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 11:07:08 -0700 To: "Kervin L. Pierre" X-Mailer: Apple Mail (2.750) 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 Jun 2006 18:07:14 -0000 I answered too fast and forgot one important point: a single, mandatory-to-implement secure transport is necessary to have both interoperability and to meet the "no plain-text passwords in the clear" requirement. If a server supported only IPSec and a client supported only TLS, that would not be interoperable. I find TLS to be the preferable mandatory-to-implement solution. It looks like our text could still do with some improvement however; something along the lines of "Servers MUST NOT offer BASIC over an unprotected channel. Clients MUST support TLS in order to provide one channel-encryption mechanism that servers can rely on if they decide to offer BASIC." lisa On Jun 23, 2006, at 11:03 AM, Lisa Dusseault wrote: > > On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote: > >> Hello, >> >> I think it can be argued that since 4.1.1 states >> that either TLS or IPSEC is valid to remedy the >> situation, that the authors were suggesting that >> the protocol's _use_ be protected and not that the >> protocol itself has to supply protection. Ie. >> plain-text CalDAV over an IPSEC VPN would satisfy >> 4.1.1 in that case. >> >> In other words the CalDAV spec does not have to >> mandate TLS but rather mandate that either TLS or >> IPSEC be used when using the protocol. > > This is a very good point, thanks. > >> PS. + $0.02 :) The Etag issue, this, and a recent >> iCalendar issue seem to stem from CalDAV not >> 'looking the other way' on deficiencies in >> HTTP and iCalendar. >> >> This is commendable, but by doing this it forces >> developers to investigate and modify components >> that they otherwise would have been able to >> utilize as 'black box' components. >> >> For example, clients who would simply call a HTTP >> stack with a url, username and password will now >> have to check the type of authorization is being >> used and fail that connection if auth is basic. >> Not to mention relay that to the user in a way >> that is useful to them. This is compounded by the >> fact that the authorization layer may not be in >> the developers control. Eg. The client application >> already supports WebDAV or some other HTTP protocol >> and the CalDAV component or layer simply calls that >> function with a simplified API interface. >> >> My point is maybe we should avoid conflicting with >> lower level protocols if at all possible, for the >> sake of adoption? > > A pragmatic approach, yes. Philosophically I tend to agree with > you (there are too many cases to list, where we simply went with > what the underlying protocols provided, as that was our first > choice usually), but there are always a couple exceptions. The > ETag ambiguity simply interfered too much with interoperability and > reliable synching. And the secured transport (when using plain- > text passwords) is not only a good idea, it's important to get > CalDAV approved. > > 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 A07A67F866 for ; Fri, 23 Jun 2006 11:03:37 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 859181422D5; Fri, 23 Jun 2006 11:03:37 -0700 (PDT) In-Reply-To: <449C2B91.4050401@adevsoft.com> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> <449C2B91.4050401@adevsoft.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17FD78D4-8C25-407C-A1A5-E47777C27828@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 11:03:31 -0700 To: Kervin L.Pierre X-Mailer: Apple Mail (2.750) 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, 23 Jun 2006 18:03:37 -0000 On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote: > Hello, > > I think it can be argued that since 4.1.1 states > that either TLS or IPSEC is valid to remedy the > situation, that the authors were suggesting that > the protocol's _use_ be protected and not that the > protocol itself has to supply protection. Ie. > plain-text CalDAV over an IPSEC VPN would satisfy > 4.1.1 in that case. > > In other words the CalDAV spec does not have to > mandate TLS but rather mandate that either TLS or > IPSEC be used when using the protocol. This is a very good point, thanks. > PS. + $0.02 :) The Etag issue, this, and a recent > iCalendar issue seem to stem from CalDAV not > 'looking the other way' on deficiencies in > HTTP and iCalendar. > > This is commendable, but by doing this it forces > developers to investigate and modify components > that they otherwise would have been able to > utilize as 'black box' components. > > For example, clients who would simply call a HTTP > stack with a url, username and password will now > have to check the type of authorization is being > used and fail that connection if auth is basic. > Not to mention relay that to the user in a way > that is useful to them. This is compounded by the > fact that the authorization layer may not be in > the developers control. Eg. The client application > already supports WebDAV or some other HTTP protocol > and the CalDAV component or layer simply calls that > function with a simplified API interface. > > My point is maybe we should avoid conflicting with > lower level protocols if at all possible, for the > sake of adoption? A pragmatic approach, yes. Philosophically I tend to agree with you (there are too many cases to list, where we simply went with what the underlying protocols provided, as that was our first choice usually), but there are always a couple exceptions. The ETag ambiguity simply interfered too much with interoperability and reliable synching. And the secured transport (when using plain-text passwords) is not only a good idea, it's important to get CalDAV approved. 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 96A247F7D0 for ; Fri, 23 Jun 2006 10:55:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 88560142306 for ; Fri, 23 Jun 2006 10:55:18 -0700 (PDT) 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 02704-02 for ; Fri, 23 Jun 2006 10:55:17 -0700 (PDT) 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 B750D1422D5 for ; Fri, 23 Jun 2006 10:55:16 -0700 (PDT) Received: (qmail 23064 invoked from network); 23 Jun 2006 17:55:16 -0000 Received: from unknown (HELO ?192.168.1.3?) (kervin@adevsoft.com@72.156.251.193 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 23 Jun 2006 17:55:16 -0000 Message-ID: <449C2B91.4050401@adevsoft.com> Date: Fri, 23 Jun 2006 13:57:37 -0400 From: "Kervin L. Pierre" Organization: Adevsoft Inc User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> In-Reply-To: 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: Fri, 23 Jun 2006 17:55:18 -0000 Hello, I think it can be argued that since 4.1.1 states that either TLS or IPSEC is valid to remedy the situation, that the authors were suggesting that the protocol's _use_ be protected and not that the protocol itself has to supply protection. Ie. plain-text CalDAV over an IPSEC VPN would satisfy 4.1.1 in that case. In other words the CalDAV spec does not have to mandate TLS but rather mandate that either TLS or IPSEC be used when using the protocol. PS. + $0.02 :) The Etag issue, this, and a recent iCalendar issue seem to stem from CalDAV not 'looking the other way' on deficiencies in HTTP and iCalendar. This is commendable, but by doing this it forces developers to investigate and modify components that they otherwise would have been able to utilize as 'black box' components. For example, clients who would simply call a HTTP stack with a url, username and password will now have to check the type of authorization is being used and fail that connection if auth is basic. Not to mention relay that to the user in a way that is useful to them. This is compounded by the fact that the authorization layer may not be in the developers control. Eg. The client application already supports WebDAV or some other HTTP protocol and the CalDAV component or layer simply calls that function with a simplified API interface. My point is maybe we should avoid conflicting with lower level protocols if at all possible, for the sake of adoption? Best regards, Kervin Lisa Dusseault wrote: > > On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote: >> >>> Right now CalDAV effectively mandates the use of TLS (again not SSL) >>> when BASIC authentication is used. Is that too strong of a position? >> >> I would think so. It's just something that CalDAV doesn't need to make >> requirements about. See similar discussion for AtomPub. > > That used to be true, when RFC2616 and RFC2518 were published. It's not > true any more. See also RFC3552, particularly section 4.1 > > "Unprotected (plaintext) > username/password systems are not acceptable in IETF standards." > > So, today the IESG imposes a higher standard, because the technology is > available to reasonably do so. IMO, this is the right thing to do. > > Lisa > _______________________________________________ > 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 5A7C77F901 for ; Fri, 23 Jun 2006 10:17:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 473B71422FA for ; Fri, 23 Jun 2006 10:17:44 -0700 (PDT) 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 28557-07 for ; Fri, 23 Jun 2006 10:17:42 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 4B73B142306 for ; Fri, 23 Jun 2006 10:17:42 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 17:17:40 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp038) with SMTP; 23 Jun 2006 19:17:40 +0200 X-Authenticated: #1915285 Message-ID: <449C222F.8040007@gmx.de> Date: Fri, 23 Jun 2006 19:17:35 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@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.3 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, 23 Jun 2006 17:17:44 -0000 Lisa Dusseault schrieb: > > On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote: >> >>> Right now CalDAV effectively mandates the use of TLS (again not SSL) >>> when BASIC authentication is used. Is that too strong of a position? >> >> I would think so. It's just something that CalDAV doesn't need to make >> requirements about. See similar discussion for AtomPub. > > That used to be true, when RFC2616 and RFC2518 were published. It's not > true any more. See also RFC3552, particularly section 4.1 > > "Unprotected (plaintext) > username/password systems are not acceptable in IETF standards." > > So, today the IESG imposes a higher standard, because the technology is > available to reasonably do so. IMO, this is the right thing to do. I don't argue that plain text passwords shouldn't be used on non-secure connections. But that's an HTTP question, not one for CalDAV to answer. 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 098B17F920 for ; Fri, 23 Jun 2006 09:47:26 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E0EE01422ED; Fri, 23 Jun 2006 09:47:25 -0700 (PDT) In-Reply-To: <449BEB5A.4050909@gmx.de> References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> <449BEB5A.4050909@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Date: Fri, 23 Jun 2006 09:47:19 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) 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, 23 Jun 2006 16:47:26 -0000 On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote: > >> Right now CalDAV effectively mandates the use of TLS (again not >> SSL) when BASIC authentication is used. Is that too strong of a >> position? > > I would think so. It's just something that CalDAV doesn't need to > make requirements about. See similar discussion for AtomPub. That used to be true, when RFC2616 and RFC2518 were published. It's not true any more. See also RFC3552, particularly section 4.1 "Unprotected (plaintext) username/password systems are not acceptable in IETF standards." So, today the IESG imposes a higher standard, because the technology is available to reasonably do so. IMO, this is the right thing to do. 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 9BAEA7F847 for ; Fri, 23 Jun 2006 08:02:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D97714230C for ; Fri, 23 Jun 2006 08:02:15 -0700 (PDT) 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 31799-10 for ; Fri, 23 Jun 2006 08:02:15 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CCBE8142309 for ; Fri, 23 Jun 2006 08:02:14 -0700 (PDT) Received: from [84.167.128.189] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52913743 for ietf-caldav@osafoundation.org; Fri, 23 Jun 2006 17:02:06 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Fri, 23 Jun 2006 17:02:20 +0200 Subject: Re: [Ietf-caldav] Access of external attachments a MUST? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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, MIME_QP_LONG_LINE 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 Jun 2006 15:02:15 -0000 > [CalDAV clients] just have to be able to 'hand-off' the URL for processin= g by > some other service (e.g. local "helper app"). Just my thoughts on *this* "have to": Clients might not be able to defer processing. In J2ME MIDP version 2 it is possible to defer this, however, there is no control over the outcome how and whether it succeeds. That is okay. However, in MIDP version 1 for example, there is not even such a mechanism. Just one example I am aware right now, there might be zillions of similar ones. Even in MIDP version 2 it does not offer this for URIs but URLs only. Even a MUST only for deferring, will be a problem. You could save this, making HTTP fetching a MUST=E2=80=A0 and deferring for all other URIs a condition= al MUST, depending whether the environment allows something like this. When URLs are possible, this mechanism MUST be used. =E2=80=A0 =E2=80=A6as CalDAV is based on WebDAV and WebDAV is based on HTTP. Or is WebD= AV not limited to HTTP/HTTP theoretically? Then the CalDAV bearer would a MUST instead of saying anything about HTTP. 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 EB3F37F847 for ; Fri, 23 Jun 2006 08:02:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD312142309 for ; Fri, 23 Jun 2006 08:02:15 -0700 (PDT) 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 30070-06 for ; Fri, 23 Jun 2006 08:02:14 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D50E71422F9 for ; Fri, 23 Jun 2006 08:02:13 -0700 (PDT) Received: from [84.167.128.189] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52913754 for ietf-caldav@osafoundation.org; Fri, 23 Jun 2006 17:02:05 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Fri, 23 Jun 2006 17:02:20 +0200 Subject: Re: [Ietf-caldav] Client property loss? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Jun 2006 15:02:16 -0000 > There are several use cases that justify the statement we currently have: Do not see a reason to point implementers on this. They figure out themselves, when they need this (dangerous) feature. Additionally, I do not say anything about MUST. >> I would like to see a statement like "highly encouraging to" save keep all >> unknown-to-client fields as far as possible here. > Perhaps we could also mention that they need to do that if they want to > 'hand-off' the iCal object to some other service (eg sync.). What happens, when the server is not reachable? Let us tighten this a bit more: Any client which (might) exchange a component with a third party SHOULD load all properties. What about that? Yes I know, a SHOULD is rather useless, however, better than the current situation. Perhaps the implementer things twice about it then. 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 6BAD67F959 for ; Fri, 23 Jun 2006 06:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C81D14230E for ; Fri, 23 Jun 2006 06:39:54 -0700 (PDT) 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 26402-08 for ; Fri, 23 Jun 2006 06:39:51 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF88D14230D for ; Fri, 23 Jun 2006 06:39:51 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id B9121D85EA9; Fri, 23 Jun 2006 09:39:50 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 23 Jun 2006 09:39:51 -0400 X-Sasl-enc: wz07N4L+JrE5ay8CogQCkGc88XeawgC/OAgp1+ZxHM58 1151069990 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 57614963C; Fri, 23 Jun 2006 09:39:50 -0400 (EDT) Date: Fri, 23 Jun 2006 09:39:48 -0400 From: Cyrus Daboo To: Alexander Traud , CalDav Subject: Re: [Ietf-caldav] Access of external attachments a MUST? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.5 (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.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 Jun 2006 13:39:54 -0000 Hi Alexander, --On June 23, 2006 11:11:54 AM +0200 Alexander Traud wrote: > Just noticed, the whole Guidelines section *seems* to be informative > instead of normative. You should state this in brackets to chapter 8. > Found this in the to-be-removed version history only. > > This means every "MUST" in chapter 8 just repeats a MUST in another part > of the/a specification for clarity. However, I cannot find such a > references for some "MUST"s in chapter 8.5 and 8.6. Either find and > mention a reference or drop the parts affected or move the parts to a > chapter before chapter 8. Otherwise, have I overlooked these MUSTs and it > is my misunderstanding? > > Any comments on this? Especially a word from the author(s) about the idea > behind chapter 8 would be helpful - especially 8.5/8.6. > We (authors) are working on some new text for the attachment section to clarify the client behaviour. The bottom line is CalDAV clients themselves are not required to download/execute external attachments - they just have to be able to 'hand-off' the URL for processing by some other service (e.g. local "helper app"). As to Section 8 being informative - I will check about that, but I do think its normative because we are using MUST etc. -- 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 000607F95A for ; Fri, 23 Jun 2006 06:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E42C9142300 for ; Fri, 23 Jun 2006 06:23:47 -0700 (PDT) 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 30604-01 for ; Fri, 23 Jun 2006 06:23:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id B5B81142305 for ; Fri, 23 Jun 2006 06:23:44 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 13:23:40 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp021) with SMTP; 23 Jun 2006 15:23:40 +0200 X-Authenticated: #1915285 Message-ID: <449BEB5A.4050909@gmx.de> Date: Fri, 23 Jun 2006 15:23:38 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 References: <449B891B.1080100@gmx.de> <88FAA2AFE8503D7918902B9C@ninevah.local> In-Reply-To: <88FAA2AFE8503D7918902B9C@ninevah.local> 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.3 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, 23 Jun 2006 13:23:48 -0000 Cyrus Daboo schrieb: > Hi Julian, > > --On June 23, 2006 8:24:27 AM +0200 Julian Reschke > wrote: > >> Running the checker...: >> >> Normative References: >> >> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok >> RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346 >> RFC2445: [PROPOSED STANDARD] ok >> RFC2446: [PROPOSED STANDARD] ok >> RFC2616: [DRAFT STANDARD] ok >> RFC2818: [INFORMATIONAL] ok >> RFC3253: [PROPOSED STANDARD] ok >> RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok >> RFC3744: [PROPOSED STANDARD] ok >> draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok >> >> Informative References: >> >> RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512 >> RFC2426: [PROPOSED STANDARD] ok >> RFC2739: [PROPOSED STANDARD] ok >> RFC4331: [PROPOSED STANDARD] ok >> >> So, >> >> - the normative ref to RFF2818 may be problematic if CalDav is supposed >> to be on the standards track (I think this has already been mentioned) > > The issue of the 2818 reference was brought up during IESG review > yesterday. We are trying to determine the best way to deal with this. > > Just as background: 2818 describes how to use TLS (as opposed to SSL) > within HTTP. Its status is 'informational', however CalDAV references it > as a 'normative' reference and thus causes a conflict. Yep. > Right now CalDAV effectively mandates the use of TLS (again not SSL) > when BASIC authentication is used. Is that too strong of a position? I would think so. It's just something that CalDAV doesn't need to make requirements about. See similar discussion for AtomPub. > Should we allow SSL and TLS (even though SSL is not an IETF standard)? > How many client/server implementations actually handle TLS as opposed to > SSL, and how many follow 2818? No idea. > There are several ways to try and resolve this: > > 1) Downgrade 2818 to an 'Informative reference' in CalDAV and add SSL > (or a 'suitable' security layer') as other options. ...actually, don't mention it at all. > 2) Ask for a 'variance' from IESG to allow 2818 to be included as a > normative reference - this would require CalDAV implementations using > BASIC to support it. Obviously not a good idea if today's clients can't do it. > 3) Ask to have 2818 moved to proposed status so CalDAV's normative > reference would be OK. That's certainly not easy. Or 4) (for completeness): submit CalDAV as "informational" as well. > The first two choices will likely require another last call of the > document as we are changing something that was previously 'normative'. Yes, possibly. >> - the ref to RFC2251 probably should be updated > > Yup - the new LDAP documents just came out. I will look into updating > our reference. Thanks (that probably could be done during AUTH48 as well). 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 F24F47F95A for ; Fri, 23 Jun 2006 06:06:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E2FE51422FF for ; Fri, 23 Jun 2006 06:06:47 -0700 (PDT) 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 24242-06 for ; Fri, 23 Jun 2006 06:06:47 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3320D1422E7 for ; Fri, 23 Jun 2006 06:06:47 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 3BCE2D86510; Fri, 23 Jun 2006 09:06:46 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 23 Jun 2006 09:06:46 -0400 X-Sasl-enc: oEnfY82srtb/8smMkVtlAT3jgjxUtQOOkNu0sL/OUFQB 1151068006 Received: from [10.0.1.4] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id 82009955F; Fri, 23 Jun 2006 09:06:45 -0400 (EDT) Date: Fri, 23 Jun 2006 09:06:50 -0400 From: Cyrus Daboo To: Julian Reschke , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12 Message-ID: <88FAA2AFE8503D7918902B9C@ninevah.local> In-Reply-To: <449B891B.1080100@gmx.de> References: <449B891B.1080100@gmx.de> X-Mailer: Mulberry/4.0.5 (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.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 Jun 2006 13:06:48 -0000 Hi Julian, --On June 23, 2006 8:24:27 AM +0200 Julian Reschke wrote: > Running the checker...: > > Normative References: > > RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok > RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346 > RFC2445: [PROPOSED STANDARD] ok > RFC2446: [PROPOSED STANDARD] ok > RFC2616: [DRAFT STANDARD] ok > RFC2818: [INFORMATIONAL] ok > RFC3253: [PROPOSED STANDARD] ok > RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok > RFC3744: [PROPOSED STANDARD] ok > draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok > > Informative References: > > RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512 > RFC2426: [PROPOSED STANDARD] ok > RFC2739: [PROPOSED STANDARD] ok > RFC4331: [PROPOSED STANDARD] ok > > So, > > - the normative ref to RFF2818 may be problematic if CalDav is supposed > to be on the standards track (I think this has already been mentioned) The issue of the 2818 reference was brought up during IESG review yesterday. We are trying to determine the best way to deal with this. Just as background: 2818 describes how to use TLS (as opposed to SSL) within HTTP. Its status is 'informational', however CalDAV references it as a 'normative' reference and thus causes a conflict. Right now CalDAV effectively mandates the use of TLS (again not SSL) when BASIC authentication is used. Is that too strong of a position? Should we allow SSL and TLS (even though SSL is not an IETF standard)? How many client/server implementations actually handle TLS as opposed to SSL, and how many follow 2818? There are several ways to try and resolve this: 1) Downgrade 2818 to an 'Informative reference' in CalDAV and add SSL (or a 'suitable' security layer') as other options. 2) Ask for a 'variance' from IESG to allow 2818 to be included as a normative reference - this would require CalDAV implementations using BASIC to support it. 3) Ask to have 2818 moved to proposed status so CalDAV's normative reference would be OK. The first two choices will likely require another last call of the document as we are changing something that was previously 'normative'. > - the ref to RFC2251 probably should be updated Yup - the new LDAP documents just came out. I will look into updating our reference. -- 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 2D3747F93C for ; Fri, 23 Jun 2006 05:56:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 108BE1422E7 for ; Fri, 23 Jun 2006 05:56:54 -0700 (PDT) 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 25455-05 for ; Fri, 23 Jun 2006 05:56:52 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 84E1B1422E6 for ; Fri, 23 Jun 2006 05:56:52 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 79768D86017; Fri, 23 Jun 2006 08:56:51 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 23 Jun 2006 08:56:51 -0400 X-Sasl-enc: Grd35P20v9VIPNSLEs16P0w9g+J+BHsJ+ctdobk+DVyJ 1151067411 Received: from [10.0.1.4] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id BCF3E4135; Fri, 23 Jun 2006 08:56:50 -0400 (EDT) Date: Fri, 23 Jun 2006 08:56:53 -0400 From: Cyrus Daboo To: Alexander Traud , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Client property loss? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.5 (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.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 Jun 2006 12:56:54 -0000 Hi Alexander, --On June 23, 2006 11:11:54 AM +0200 Alexander Traud wrote: > Keeping only a part of components is a big problem in data > synchronization. The next paragraph does not help, when the client > forwards (partial) components to third parties not involving the original > party (i.e. a CalDAV server). With today memory card sizes and prices, > storage is not such a issue anymore even for clients. There are several use cases that justify the statement we currently have: 1) Mobile devices - these do have limited storage. 2) A 'presentation only' calendar system that simply displays calendar data - such a system would only need to get the properties and values it would actually use. 3) A web-calendar using client-side javascript/xsl or whatever to transform the iCal (or xCal) data into presentations elements. Again, they would have no need for attachment data until a user actually requests to download an inline attachment. The paragraph after the one you quoted does imply that clients will have to deal with the entire iCal object to do updates. Perhaps we could also mention that they need to do that if they want to 'hand-off' the iCal object to some other service (eg sync.). -- 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 E34117F935 for ; Fri, 23 Jun 2006 02:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D27651422FB for ; Fri, 23 Jun 2006 02:11:54 -0700 (PDT) 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 28399-08 for ; Fri, 23 Jun 2006 02:11:51 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D213B142309 for ; Fri, 23 Jun 2006 02:11:50 -0700 (PDT) Received: from [84.167.146.175] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52898140 for ietf-caldav@osafoundation.org; Fri, 23 Jun 2006 11:11:41 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Fri, 23 Jun 2006 11:11:54 +0200 From: Alexander Traud To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Subject: [Ietf-caldav] Client property loss? 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 Jun 2006 09:11:55 -0000 Chapter 8.2.2 https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.sec tion.8.2.2 > Since some calendar property values can be large (e.g., ATTACH or ATTENDEE) > clients can choose to restrict the calendar properties to be returned in a > calendaring REPORT request to those it knows it will use. I would like to see a statement like "highly encouraging to" save keep all unknown-to-client fields as far as possible here. Keeping only a part of components is a big problem in data synchronization. The next paragraph does not help, when the client forwards (partial) components to third parties not involving the original party (i.e. a CalDAV server). With today memory card sizes and prices, storage is not such a issue anymore even for clients. Pointing to such a case and encouraging implementers might help to improve data synchronization. Chapter 5.3.3 > http://lists.osafoundation.org/pipermail/ietf-caldav/2005-December/000565.html https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.sec tion.5.3.3 > Servers MUST support the use of non-standard components, properties and > parameters in calendar object resources stored via the PUT method. This was discussed on this mailing list before and as far as I understand because of WebDAV specification client properties (of the iCalendar specification unknown to the server) SHOULD be kept. However, repeating or pointing to this requirement might help (force?) implementers to keep *all* type of properties from the client even standard-but-unknown-to-server and not only X-type ones. By the way is this now a MUST or a SHOULD to keep standard-but-unknown-to-server properties in CalDAV? I do not want to repeat or start the discussion on this again, however, I do not understand the result of the discussion while reading the mailing list archive. A server MUST keep X-type properties, however, for standard ones keeping is SHOULD only? Do not get that. Where is my misunderstanding? Two clarifications I would like to see in the specification. Any comment on those? 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 C84BF7F931 for ; Fri, 23 Jun 2006 02:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B945414230C for ; Fri, 23 Jun 2006 02:11:53 -0700 (PDT) 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 26266-08 for ; Fri, 23 Jun 2006 02:11:50 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BBE171422FB for ; Fri, 23 Jun 2006 02:11:49 -0700 (PDT) Received: from [84.167.146.175] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52898124 for ietf-caldav@osafoundation.org; Fri, 23 Jun 2006 11:11:41 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Fri, 23 Jun 2006 11:11:54 +0200 Subject: Re: [Ietf-caldav] Access of external attachments a MUST? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 Jun 2006 09:11:53 -0000 Just noticed, the whole Guidelines section *seems* to be informative instead of normative. You should state this in brackets to chapter 8. Found this in the to-be-removed version history only. This means every "MUST" in chapter 8 just repeats a MUST in another part of the/a specification for clarity. However, I cannot find such a references for some "MUST"s in chapter 8.5 and 8.6. Either find and mention a reference or drop the parts affected or move the parts to a chapter before chapter 8. Otherwise, have I overlooked these MUSTs and it is my misunderstanding? Any comments on this? Especially a word from the author(s) about the idea behind chapter 8 would be helpful - especially 8.5/8.6. 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 87E027F932 for ; Thu, 22 Jun 2006 23:24:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7895B1422F9 for ; Thu, 22 Jun 2006 23:24:35 -0700 (PDT) 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 07467-07 for ; Thu, 22 Jun 2006 23:24:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id A6EE6142305 for ; Thu, 22 Jun 2006 23:24:32 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2006 06:24:30 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp005) with SMTP; 23 Jun 2006 08:24:30 +0200 X-Authenticated: #1915285 Message-ID: <449B891B.1080100@gmx.de> Date: Fri, 23 Jun 2006 08:24:27 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-15; 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.3 tagged_above=-50.0 required=4.0 tests=AWL, UPPERCASE_25_50 X-Spam-Level: Subject: [Ietf-caldav] References in draft-dusseault-caldav-12 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 Jun 2006 06:24:35 -0000 Running the checker...: Normative References: RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346 RFC2445: [PROPOSED STANDARD] ok RFC2446: [PROPOSED STANDARD] ok RFC2616: [DRAFT STANDARD] ok RFC2818: [INFORMATIONAL] ok RFC3253: [PROPOSED STANDARD] ok RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok RFC3744: [PROPOSED STANDARD] ok draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok Informative References: RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512 RFC2426: [PROPOSED STANDARD] ok RFC2739: [PROPOSED STANDARD] ok RFC4331: [PROPOSED STANDARD] ok So, - the normative ref to RFF2818 may be problematic if CalDav is supposed to be on the standards track (I think this has already been mentioned) - the ref to RFC2251 probably should be updated 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 3E3F77F82B for ; Thu, 22 Jun 2006 03:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 11A111422F2 for ; Thu, 22 Jun 2006 03:12:36 -0700 (PDT) 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 28670-08 for ; Thu, 22 Jun 2006 03:12:33 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B88E1422F1 for ; Thu, 22 Jun 2006 03:12:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 32AAA3FCAA5 for ; Thu, 22 Jun 2006 12:06:49 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-243-166.reverse.mdcc-fun.de [213.211.243.166]) by mail.mdlink.net (Postfix) with ESMTP id 07E8D40100C for ; Thu, 22 Jun 2006 12:06:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Helge Hess Subject: Re: [Ietf-caldav] Access of external attachments a MUST? Date: Thu, 22 Jun 2006 12:12:18 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) 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: 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 Jun 2006 10:12:36 -0000 On Jun 22, 2006, at 08:55, Alexander Traud wrote: > We have to *access* - not just refer to - external attachments (see =20= > chapter > 8.5.2 of current CalDAV draft 12). Well, I think there is no specific definition of what "access" means. =20= In the given context "access" will usually mean opening the =20 attachment in/using the systems web browser (inline or out of =20 application). Eg Kontact can open external attachments as tabs inside the =20 appointment viewer by embedding Konqueror (or by opening Konqueror =20 itself). But I agree, this section could be improved in the wording :-) > My English dictionary states for access: > "fetching and opening [the attachment]". Please correct me, if I > misunderstand anything here. Well, your misunderstanding is that there is a 1:1 mapping between =20 words and definitions :-) There are plenty of definitions for "access": http://www.infoplease.com/ipd/A0304736.html Which is why the section should be a bit more specific about this. As =20= this threads points out it can be misunderstood. I really don't think that it is the intention that CalDAV clients =20 themselves must _fetch_ external content (and this is not written in =20 the spec). What would be the point? This doesn't belong into CalDAV =20 and is already specified in iCalendar. "CalDAV clients MUST support inline attachments as specified in =20 iCalendar" This is a DUP if we already specify that "CalDAV clients MUST support =20= iCalendar", no? Probably the motivation to add a chapter about that topic was to =20 raise awareness that client will actually want to do that. I suppose a situation which should not arise is that a user attaches =20 a lovely Word file to an event with one client, and when a different =20 client accesses the event the file is not even shown. However it =20 obviously cannot imply that the other clients needs to be able to =20 process Word files :-) [or arbitary URLs] > https://www.greenbytes.de/tech/webdav/draft-dusseault-=20 > caldav-12.html#rfc.sec > tion.8.5.2 >> =85 if the client accesses any calendar object resource it MUST be =20= >> capable of >> also accessing the external attachment if one exists. Greets, Helge 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 3D5EB7F81E for ; Wed, 21 Jun 2006 23:55:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 104EB1422E0 for ; Wed, 21 Jun 2006 23:55:58 -0700 (PDT) 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 20980-06 for ; Wed, 21 Jun 2006 23:55:56 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DFE361422C6 for ; Wed, 21 Jun 2006 23:55:55 -0700 (PDT) Received: from [84.167.169.211] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52842799 for ietf-caldav@osafoundation.org; Thu, 22 Jun 2006 08:55:50 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Thu, 22 Jun 2006 08:55:58 +0200 Subject: Re: [Ietf-caldav] Access of external attachments a MUST? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: <3B5EA2BB-9410-4546-A267-8A981C64C3EA@opengroupware.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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, MIME_QP_LONG_LINE 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 Jun 2006 06:55:58 -0000 Helge Hess wrote on 22nd June 2006: > The requirement just states that the client and the server must store > those URLs, it doesn't say that they need to be able to open / deal- > with the URLs. Cannot follow this interpretation. We have to *access* - not just refer to - external attachments (see chapter 8.5.2 of current CalDAV draft 12). My English dictionary states for access: "fetching and opening [the attachment]". Please correct me, if I misunderstand anything here. https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.se= c tion.8.5.2 > =E2=80=A6 if the client accesses any calendar object resource it MUST be capabl= e of > also accessing the external attachment if one exists. 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 C3FE17F813 for ; Wed, 21 Jun 2006 23:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 95F831422E4 for ; Wed, 21 Jun 2006 23:54:04 -0700 (PDT) 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 25735-07 for ; Wed, 21 Jun 2006 23:54:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 9CFA41422C6 for ; Wed, 21 Jun 2006 23:54:01 -0700 (PDT) Received: (qmail invoked by alias); 22 Jun 2006 06:53:59 -0000 Received: from p508FBE6A.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.106] by mail.gmx.net (mp017) with SMTP; 22 Jun 2006 08:53:59 +0200 X-Authenticated: #1915285 Message-ID: <449A3E7F.8080502@gmx.de> Date: Thu, 22 Jun 2006 08:53:51 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Access of external attachments a MUST? References: <3B5EA2BB-9410-4546-A267-8A981C64C3EA@opengroupware.org> In-Reply-To: <3B5EA2BB-9410-4546-A267-8A981C64C3EA@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.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: Thu, 22 Jun 2006 06:54:04 -0000 Helge Hess schrieb: > On Jun 22, 2006, at 24:49, Alexander Traud wrote: >> I know I am here in an IETF environment, however, there are a lot of >> devices >> out there in the wild which do not have FTP and will never get built >> in (for >> example J2ME MIDP). So I would have to add a FTP client stack just to get >> CalDAV client interoperability. Is this intended? > > I can't really follow what you are talking about. An external attachment > is just a URL, right? All iCalendar/CalDAV specifies is that URLs can be > associated with events/tasks/etc. > The requirement just states that the client and the server must store > those URLs, it doesn't say that they need to be able to open / deal-with > the URLs. Well, that's not what it says: "if the client accesses any calendar object resource it MUST be capable of also accessing the external attachment if one exists" () As far as I can tell, that requirement is non-implementable, because it doesn't say what types of URLs are supported. That is, it can only be validated at runtime. > ... 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 AC3E07F716 for ; Wed, 21 Jun 2006 16:05:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 815A11422E4 for ; Wed, 21 Jun 2006 16:05:34 -0700 (PDT) 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 11053-04 for ; Wed, 21 Jun 2006 16:05:33 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id E18711422E7 for ; Wed, 21 Jun 2006 16:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id C550C401AEA for ; Thu, 22 Jun 2006 00:59:45 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-243-166.reverse.mdcc-fun.de [213.211.243.166]) by mail.mdlink.net (Postfix) with ESMTP id 59F564015AB for ; Thu, 22 Jun 2006 00:59:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B5EA2BB-9410-4546-A267-8A981C64C3EA@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Access of external attachments a MUST? Date: Thu, 22 Jun 2006 01:05:17 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) 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: 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 Jun 2006 23:05:34 -0000 On Jun 22, 2006, at 24:49, Alexander Traud wrote: > I know I am here in an IETF environment, however, there are a lot > of devices > out there in the wild which do not have FTP and will never get > built in (for > example J2ME MIDP). So I would have to add a FTP client stack just > to get > CalDAV client interoperability. Is this intended? I can't really follow what you are talking about. An external attachment is just a URL, right? All iCalendar/CalDAV specifies is that URLs can be associated with events/tasks/etc. The requirement just states that the client and the server must store those URLs, it doesn't say that they need to be able to open / deal- with the URLs. Thats exactly like with HTML where an or even an can contain arbitary URLs and its the browsers tasks to decide how to deal with them (I think the same is true for WML). I suppose the requirement to store external attachments was added because not all servers store the iCal as a verbatim copy, that is, they might remove/reorder/transform various fields of the iCal entity. CalDAV basically says they are not allowed to do this for external attachments. Greets, Helge 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 75EBC7F654 for ; Wed, 21 Jun 2006 15:49:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4BEB01422DA for ; Wed, 21 Jun 2006 15:49:15 -0700 (PDT) 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 01685-08 for ; Wed, 21 Jun 2006 15:49:13 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EDD814229A for ; Wed, 21 Jun 2006 15:49:13 -0700 (PDT) Received: from [84.167.129.146] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52830141 for ietf-caldav@osafoundation.org; Thu, 22 Jun 2006 00:49:06 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Thu, 22 Jun 2006 00:49:13 +0200 Subject: Re: [Ietf-caldav] Access of external attachments a MUST? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: <5CDC0DCA-136E-4435-94BE-A767D6B7E6D5@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit 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: Wed, 21 Jun 2006 22:49:15 -0000 > FTP for external attachments I know I am here in an IETF environment, however, there are a lot of devices out there in the wild which do not have FTP and will never get built in (for example J2ME MIDP). So I would have to add a FTP client stack just to get CalDAV client interoperability. Is this intended? I think you want to force implementers to use external attachments rather than internal ones. This is a good idea, however, rather than forcing I would go for convincing them. Make it SHOULD, however, explain why external attachments are useful. Nevertheless, personally I could live with a MUST for HTTP URIs. Perhaps even HTTPS. > If some clients can't handle external attachments, that would be a serious > barrier to using them Could you elaborate a bit more or point to a reference? I do not understand your aims, yet. Was this discussed before? Have not found anything in the archives. 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 5A2D87F61C for ; Wed, 21 Jun 2006 13:46:05 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 257101422EB; Wed, 21 Jun 2006 13:46:05 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <5CDC0DCA-136E-4435-94BE-A767D6B7E6D5@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] Access of external attachments a MUST? Date: Wed, 21 Jun 2006 13:46:01 -0700 To: Alexander Traud X-Mailer: Apple Mail (2.750) Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 20:46:05 -0000 On Jun 21, 2006, at 2:14 AM, Alexander Traud wrote: > Chapter 8.5.2 > https://www.greenbytes.de/tech/webdav/draft-dusseault-=20 > caldav-12.html#rfc.sec > tion.8.5.2 >> =85 if the client accesses any calendar object resource it MUST be =20= >> capable of >> also accessing the external attachment if one exists. > > Why is this a MUST? > We consider it a requirement that clients be able to handle both =20 internal and external attachments. If some clients can't handle =20 external attachments, that would be a serious barrier to using them =20 despite the advantages of external attachments. > It is impossible to access all URIs out there in one client. In my > understanding, to confirm to CalDAV the client would need to reject =20= > the > whole component or the affected ATTACH property if the URI is not =20 > supported. > Does this make sense if you want to forward the component to a =20 > third party > client which might support this URI? I think the intent was that this would be mostly HTTP URLs which =20 would be required to support, possibly also FTP. Although we didn't =20 use MUST/MAY language, we provided some guidance on this in section =20 8.5.2: "An external attachment could be: o In a collection in the calendar collection containing the =20 calendar object resource; o Somewhere else in the same repository that hosts the calendar collection; or o On an HTTP or FTP server elsewhere." It would certainly be sufficiently conducive to interoperability for =20 clients to support both HTTP and FTP for external attachments, and to =20= error for other URI types. 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 E2ED57F7E3; Wed, 21 Jun 2006 10:23:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BBE971422C5; Wed, 21 Jun 2006 10:23:18 -0700 (PDT) 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 29048-08; Wed, 21 Jun 2006 10:23:17 -0700 (PDT) Received: from sanpietro.red-bean.com (Sanpietro.red-bean.com [66.146.193.61]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2AAEC1422A6; Wed, 21 Jun 2006 10:23:17 -0700 (PDT) Received: from adsl-68-126-173-44.dsl.snfc21.pacbell.net ([68.126.173.44]:44640 helo=[10.0.0.4]) by sanpietro.red-bean.com with esmtpsa (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.62) (envelope-from ) id 1Ft6Pt-0008RF-N2; Wed, 21 Jun 2006 12:23:03 -0500 In-Reply-To: References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-804709028; protocol="application/pkcs7-signature" Message-Id: <59B1DDE0-1429-40F2-92F4-3FD91C321203@wsanchez.net> From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Wed, 21 Jun 2006 10:23:20 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.750) X-Virus-Scanned: No virus found by ClamAV at red-bean.com 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: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Wed, 21 Jun 2006 17:23:19 -0000 --Apple-Mail-4-804709028 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Actually, I remember sending a few emails with feedback on this and not getting any replies, and then I went on my honeymoon, so it wasn't quite on my mind for a while. I think that document is the way to go, even if all it ends up saying is something similar to what you have in the CalDAV draft. -wsv On Jun 20, 2006, at 4:59 PM, Lisa Dusseault wrote: > We basically tried that. What it turned into was this www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> with > no consensus on the basic model or apparent drive to come to > consensus. Got any feedback on that draft? --Apple-Mail-4-804709028 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHbDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQlMIIDjqADAgECAhBx7J2j8CFn/hGS fsXTuaKyMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNTEyMTIwMTA1NDFaFw0wNjEyMTIwMTA1NDFaMIIBHzEVMBMGA1UEBBMMU2Fu Y2hleiBWZWdhMREwDwYDVQQqEwhXaWxmcmVkbzEeMBwGA1UEAxMVV2lsZnJlZG8gU2FuY2hleiBW ZWdhMSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekB3c2FuY2hlei5uZXQxITAfBgkqhkiG9w0BCQEW EndzYW5jaGV6QGFwcGxlLmNvbTEiMCAGCSqGSIb3DQEJARYTd3NhbmNoZXpAYXBhY2hlLm9yZzEf MB0GCSqGSIb3DQEJARYQd3NhbmNoZXpAbWl0LmVkdTEkMCIGCSqGSIb3DQEJARYVd3NhbmNoZXpA YWx1bS5taXQuZWR1MR8wHQYJKoZIhvcNAQkBFhB3c2FuY2hlekBtYWMuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4pAElSKR4KhKaopixoANvjnn/ZJirl2wJL7mEtgxA6kzZ/iB t9m9h3CNTh2h9g87CbOb10trNI8MmusNLgC4y2Z1Jv9EEV9LidrYW8iJx5vrqPOpOCwKqdqM4K+y kCC/CZVRYh7b5Di0UChUqtfNc6MROXz30GNq3n5fpWNbzz64DgAMSohwfSQbtt4f1W3OHIDHbtOl s4RNYmQssgI+SiYYekfJZl0RKrTEs0iYkTUFDV/Rwm1/GcIUpEHU00jmZJ2NxZUnWpOWlMa+iWn7 xUpr1W3CWXEnD9/leXRokoKhZvU5K4SiZyLqstEnWz5Qqz8sq6/ZD80K1z8G5XnjZQIDAQABo4GY MIGVMIGEBgNVHREEfTB7gRV3c2FuY2hlekB3c2FuY2hlei5uZXSBEndzYW5jaGV6QGFwcGxlLmNv bYETd3NhbmNoZXpAYXBhY2hlLm9yZ4EQd3NhbmNoZXpAbWl0LmVkdYEVd3NhbmNoZXpAYWx1bS5t aXQuZWR1gRB3c2FuY2hlekBtYWMuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA gU93zJYHgQsOY2QwIFlBViwUWbRGwb4wflJH1sp1gyX+JOxdB60AbIdME/kSTp9tJUvHRyt1j0Yq SWXADqqohXo04XgZusdwqEjIy2dMt6c7KG+NocLqhgL9Y6HqLRWTC1Ve3TxZVn18Wb0j41fJIYhi 6RwT/cRyFQ9rcdZCatMxggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQceydo/AhZ/4Rkn7F07misjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA2MjExNzIzMjFaMCMGCSqGSIb3DQEJ BDEWBBRdK7962E/R5HcNhHa3rQqearyFoTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHHsnaPwIWf+EZJ+xdO5orIwgYcGCyqGSIb3 DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHHs naPwIWf+EZJ+xdO5orIwDQYJKoZIhvcNAQEBBQAEggEAQA0SlT1pN7YQNMRkvIqZUg99irtNYvB5 S5i4A9ifqVLKUtZ7ZoUBF1SXB8ugV5NRecIf+RDWZBFE3AbVGnSL/HM44wIVP15nebWUPIORgjOz Ie8K1jDDYqq4eRkQPVnlHqV1lkQFKQCp+v/YZA0eydWxKL+yeroleU7FcH/J7VX1D0vZKe2oHnd/ LvumU1Cao4VYxc4dEjT+VyT8gnWzzELT2scrxKggyRn7SPbDY8HX5CjpWRfXzyRr6wq2oTP/YitZ UJ/5/eLmQ1XVxXhf3J0WTWuNiFkiZ+dJW2BGWkrvrxZhYio8+JOGaJoFJJdAu5Vj9Uu73M50VCic FlxgUAAAAAAAAA== --Apple-Mail-4-804709028-- 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 07E607F905 for ; Wed, 21 Jun 2006 07:28:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5352142295 for ; Wed, 21 Jun 2006 07:28:58 -0700 (PDT) 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 31245-10 for ; Wed, 21 Jun 2006 07:28:57 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E1FCA142293 for ; Wed, 21 Jun 2006 07:28:56 -0700 (PDT) Received: from [84.167.175.207] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52809268 for ietf-caldav@osafoundation.org; Wed, 21 Jun 2006 16:27:03 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Wed, 21 Jun 2006 16:27:16 +0200 Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type? From: Alexander Traud To: CalDav Message-ID: In-Reply-To: <3E918926E343C3B25EAE8F0E@Cyrus-Daboo.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Wed, 21 Jun 2006 14:28:59 -0000 I have to correct you, the above should be correct for vCalendar support, as vCalendar 1.0 has no MIME media type registered with IANA and iCalendar does not define a "version" parameter (see RFC2445). Correct me if I am wrong. > we do not say anything about how a client might GET data in one preferred > (supported) format over another. Yes, there is no need to that in the CalDav specification. The server detects the capabilities of the client through the HTTP "Accept" header. When the client does not accept "text/calendar" or "text/calendar" has a lower quality factor than another calendar data format supported by the server, the one with the highest quality factor should be supplied to the client. >> Nevertheless, if [vCalendar 1.0 handling] succeeds, depends on the server > a good client wanting to store calendar data in some other format will first > check what is supported by the server and then only use a format that is known > to be supported. Sure, this is a way such a client should work then. However, I was just asking the general idea whether it is possible at all. Sorry for the confusion which my wrong wording and simplification created. 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 0DFA47F636 for ; Wed, 21 Jun 2006 06:26:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D80E5142298 for ; Wed, 21 Jun 2006 06:26:21 -0700 (PDT) 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 29843-01 for ; Wed, 21 Jun 2006 06:26:20 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 554C9142292 for ; Wed, 21 Jun 2006 06:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 03A8B3FC950 for ; Wed, 21 Jun 2006 15:20:28 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-243-166.reverse.mdcc-fun.de [213.211.243.166]) by mail.mdlink.net (Postfix) with ESMTP id 5A4D9400ACA for ; Wed, 21 Jun 2006 15:20:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <3E918926E343C3B25EAE8F0E@Cyrus-Daboo.local> References: <1626244DD0BF05231CC6D69F@Cyrus-Daboo.local> <3E918926E343C3B25EAE8F0E@Cyrus-Daboo.local> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type? Date: Wed, 21 Jun 2006 15:26:02 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.750) 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: 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 Jun 2006 13:26:22 -0000 On Jun 21, 2006, at 15:24, Cyrus Daboo wrote: > However we do not say anything about how a client might GET data in > one preferred (supported) format over another. Using the HTTP "accept" header? Greets, Helge 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 030EE7F8FB for ; Wed, 21 Jun 2006 06:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 495441422E4 for ; Wed, 21 Jun 2006 06:24:35 -0700 (PDT) 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 20925-05 for ; Wed, 21 Jun 2006 06:24:34 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by laweleka.osafoundation.org (Postfix) with ESMTP id C463B1422E2 for ; Wed, 21 Jun 2006 06:24:34 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id EF210D80F75; Wed, 21 Jun 2006 09:24:33 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 09:24:34 -0400 X-Sasl-enc: k0389Lz4fDu+J3yp+uy4m2pYe0JEHmtpgx074p5+pZYJ 1150896274 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 64A0F4176; Wed, 21 Jun 2006 09:24:33 -0400 (EDT) Date: Wed, 21 Jun 2006 09:24:31 -0400 From: Cyrus Daboo To: Alexander Traud , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type? Message-ID: <3E918926E343C3B25EAE8F0E@Cyrus-Daboo.local> In-Reply-To: <1626244DD0BF05231CC6D69F@Cyrus-Daboo.local> References: <1626244DD0BF05231CC6D69F@Cyrus-Daboo.local> X-Mailer: Mulberry/4.0.5 (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.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: Wed, 21 Jun 2006 13:24:36 -0000 Hi Cyrus, --On June 21, 2006 9:02:58 AM -0400 Cyrus Daboo wrote: > In theory a server could advertise: > > xmlns:C="urn:ietf:params:xml:ns:caldav"> > > > > Which would mean it ONLY supported vCalendar. However, section 2 states > that iCalendar MUST be supported - so there is a little discrepancy there > - I will look into fixing that. To address this - section 2 mandates support for iCal V2, so the XML element above was wrong, it should have been: i.e. CalDAV servers are always required to support GET and PUT with iCal v2 data, and MAY support GET/PUT with other calendar data types. However we do not say anything about how a client might GET data in one preferred (supported) format over another. -- 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 DDEE97F8F6 for ; Wed, 21 Jun 2006 06:03:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B70691422DD for ; Wed, 21 Jun 2006 06:03:05 -0700 (PDT) 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 24706-02 for ; Wed, 21 Jun 2006 06:03:03 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by laweleka.osafoundation.org (Postfix) with ESMTP id 035411422D9 for ; Wed, 21 Jun 2006 06:03:03 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0A79FD80E2B; Wed, 21 Jun 2006 09:03:02 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Wed, 21 Jun 2006 09:03:02 -0400 X-Sasl-enc: LLsy28jIghtvmwBR1mUBHrSxSBnPHGCy1okxoa8OIaMf 1150894982 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 9B6364177; Wed, 21 Jun 2006 09:03:01 -0400 (EDT) Date: Wed, 21 Jun 2006 09:02:58 -0400 From: Cyrus Daboo To: Alexander Traud , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type? Message-ID: <1626244DD0BF05231CC6D69F@Cyrus-Daboo.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.5 (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.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: Wed, 21 Jun 2006 13:03:06 -0000 Hi Alexander, --On June 21, 2006 10:52:44 AM +0200 Alexander Traud wrote: > In reply to: >> http://lists.osafoundation.org/pipermail/ietf-caldav/2005-May/000376.html > > I hope I understand this correctly, please correct me if I am wrong: > > - There is no requirement forcing a CalDAV client to understand or send > iCalendar components. A CalDAV client can use for example vCalendar 1.0 or > xCal or whatever as exchange format as long as the client states this in > in Accept HTTP headers, of course. Nevertheless, if that succeeds, > depends on the server. Section 5.2.4 of the draft describes the CALDAV:supported-calendar-data. That is used by the server to advertise what types of calendar data it supports. In the absence of that property the server ONLY supports text/calendar VERSION:2.0. So a good client wanting to store calendar data in some other format will first check what is supported by the server and then only use a format that is known to be supported. In theory a server could advertise: Which would mean it ONLY supported vCalendar. However, section 2 states that iCalendar MUST be supported - so there is a little discrepancy there - I will look into fixing that. > - There is no requirement forcing a CalDAV server to alter a received > vCalendar 1.0 component to iCalendar (on PUT or any other method) except a > non-vCalendar aware client asks for the component. So a PUT with a > vCalendar might be saved 1:1 by the server. Correct - nothing forces a server to return calendar data in a format other than what was used to store it, but nothing prevents a server from doing that either. Question: do you really have a need to still use vCalendar as opposed to iCalendar? If so, what is keeping you from upgrading? -- 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 BED477F7A4 for ; Wed, 21 Jun 2006 02:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 98CFF1422C5 for ; Wed, 21 Jun 2006 02:14:47 -0700 (PDT) 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 11488-07 for ; Wed, 21 Jun 2006 02:14:45 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 81ED21422C0 for ; Wed, 21 Jun 2006 02:14:44 -0700 (PDT) Received: from [84.167.146.59] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52789422 for ietf-caldav@osafoundation.org; Wed, 21 Jun 2006 11:14:37 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Wed, 21 Jun 2006 11:14:50 +0200 From: Alexander Traud To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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, MIME_QP_LONG_LINE X-Spam-Level: Subject: [Ietf-caldav] Access of external attachments a MUST? 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 Jun 2006 09:14:47 -0000 Chapter 8.5.2 https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.se= c tion.8.5.2 > =E2=80=A6 if the client accesses any calendar object resource it MUST be capabl= e of > also accessing the external attachment if one exists. Why is this a MUST? iCalendar chapter 4.8.1.1 Attachment http://www.ietf.org/rfc/rfc2445.txt > The default value type for this property is URI. The value type can also = be > set to BINARY to indicate inline binary encoded content information. It is impossible to access all URIs out there in one client. In my understanding, to confirm to CalDAV the client would need to reject the whole component or the affected ATTACH property if the URI is not supported= . Does this make sense if you want to forward the component to a third party client which might support this URI? 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 C97F97F8EC for ; Wed, 21 Jun 2006 01:56:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A458F14229D for ; Wed, 21 Jun 2006 01:56:32 -0700 (PDT) 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 25745-03 for ; Wed, 21 Jun 2006 01:56:32 -0700 (PDT) Received: from macnews.de (webmail.macnews.de [81.92.6.138]) (using SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F18141422A4 for ; Wed, 21 Jun 2006 01:56:30 -0700 (PDT) Received: from [84.167.146.59] (account be10372 HELO [10.0.1.6]) by macnews.de (CommuniGate Pro SMTP 4.3.9) with ESMTPSA id 52788549 for ietf-caldav@osafoundation.org; Wed, 21 Jun 2006 10:52:38 +0200 User-Agent: Microsoft-Entourage/9.0.6.8320 Date: Wed, 21 Jun 2006 10:52:44 +0200 From: Alexander Traud To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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] vCalender 1.0 component possible as return type? 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 Jun 2006 08:56:32 -0000 In reply to: > http://lists.osafoundation.org/pipermail/ietf-caldav/2005-May/000376.html I hope I understand this correctly, please correct me if I am wrong: - There is no requirement forcing a CalDAV client to understand or send iCalendar components. A CalDAV client can use for example vCalendar 1.0 or xCal or whatever as exchange format as long as the client states this in in Accept HTTP headers, of course. Nevertheless, if that succeeds, depends on the server. - There is no requirement forcing a CalDAV server to alter a received vCalendar 1.0 component to iCalendar (on PUT or any other method) except a non-vCalendar aware client asks for the component. So a PUT with a vCalendar might be saved 1:1 by the server. Do not get me wrong, I like these features of CalDAV. I just want to confirm these are in the spirit of the authors. 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 B552F7F8CA for ; Tue, 20 Jun 2006 17:16:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C7251422C1 for ; Tue, 20 Jun 2006 17:16:13 -0700 (PDT) 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 12785-08 for ; Tue, 20 Jun 2006 17:16:13 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 8EF7E1422C0 for ; Tue, 20 Jun 2006 17:16:12 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2006 00:16:11 -0000 Received: from p508FBE07.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.7] by mail.gmx.net (mp002) with SMTP; 21 Jun 2006 02:16:11 +0200 X-Authenticated: #1915285 Message-ID: <44988FC9.4050503@gmx.de> Date: Wed, 21 Jun 2006 02:16:09 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> In-Reply-To: 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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Wed, 21 Jun 2006 00:16:13 -0000 Lisa Dusseault schrieb: > > On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote: > >> Not really, no. >> >> HTTP defines ETag. An HTTP server should be able to use the same >> ETag logic on all HTTP resources, and not treat ETags for calendar >> resources differently than others. Not all users of ETags are going >> to be aware that calendar resources are special. >> >> My concern is that if there is *any* inconsistency between the >> general solution when it comes and CalDAV's, that an implementor may >> have to choose between being compliant with CalDAV or the more general >> ETag spec, or may have to continue to implement special semantics on >> calendar resources for purposes which are better served by the other >> spec. >> >> I realize that "the other spec" doesn't exist today, and that this >> is a total drag. Can't we take your one paragraph and put it into its >> own document? I don't know IETF process very well, so I don't know >> what the next steps should be, but as an implementor, I'm >> uncomfortable with the prospect of dealing with two independently >> written specifications for the same behavior. > > We basically tried that. What it turned into was this > > with no consensus on the basic model or apparent drive to come to > consensus. Got any feedback on that draft? It's a shame we didn't make progress on that, but that doesn't invalidate the approach taken (making this an issue orthogonal to WebDAV, CalDAV or Atom). 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 E0CCC7F8C3 for ; Tue, 20 Jun 2006 17:14:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B8B8A1422C1 for ; Tue, 20 Jun 2006 17:14:40 -0700 (PDT) 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 13262-05 for ; Tue, 20 Jun 2006 17:14:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id A48511422BE for ; Tue, 20 Jun 2006 17:14:38 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2006 00:14:34 -0000 Received: from p508FBE07.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.7] by mail.gmx.net (mp001) with SMTP; 21 Jun 2006 02:14:34 +0200 X-Authenticated: #1915285 Message-ID: <44988F67.9050803@gmx.de> Date: Wed, 21 Jun 2006 02:14:31 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <4496FDDD.8010405@gmx.de> <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@osafoundation.org> <449828CC.3030700@gmx.de> <430D8860-3906-4210-8DD9-5CFCC5843176@osafoundation.org> In-Reply-To: <430D8860-3906-4210-8DD9-5CFCC5843176@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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Wed, 21 Jun 2006 00:14:41 -0000 Lisa Dusseault schrieb: > My assertion was that if a strong ETag is returned, Xythos WFC assumes > that what it PUT was what the server stored, and it seems you agree. > You found that if a Last-Modified is returned instead, WFC makes the > same assumption -- naturally, they're very similar. It seems that the client always assumes that the server does no content-rewriting, no matter what it returns. So it's incorrect to assume it makes specific assumptions about ETags on PUTs. It doesn't. > You're probably quite right about the general case, that existing WebDAV > clients don't handle content-rewriting servers at all. What's the best Several clients handle it well, because they don't have a local content cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP Netweaver KM. > thing a content-rewriting server can do in this situation? I would hope > that if a client receives neither an ETag nor a Last-Modified in a PUT > response, then the next time it synchronizes and sees an ETag that it's > never seen before, the client downloads the resource. This allows the > content to eventually get synchronized although perhaps not as fast as > would be ideal. As there's no guarantee in HTTP about content rewriting not occurring, clients should always re-sync (at some point of time). An optimization (which happens to be the one I've been proposing several times now) would be a way for the server to indicate that content was *not* rewritten, avoiding the additional retrieval. > But CalDAV clients will have to handle content-rewriting servers at > least handling events (calendar component resources), because during > protocol development we heard from a couple server developers that > they'd need to add custom iCalendar properties to an event as soon as it > was stored, thus rewriting the content. Yes. I'm not sure how this is different from the generic case, though. 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 D993A7F8DB for ; Tue, 20 Jun 2006 16:59:35 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 838291422A6; Tue, 20 Jun 2006 16:59:35 -0700 (PDT) In-Reply-To: References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Tue, 20 Jun 2006 16:59:32 -0700 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.750) Cc: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 23:59:36 -0000 On Jun 20, 2006, at 10:27 AM, Wilfredo S=E1nchez Vega wrote: > Not really, no. > > HTTP defines ETag. An HTTP server should be able to use the same =20= > ETag logic on all HTTP resources, and not treat ETags for calendar =20 > resources differently than others. Not all users of ETags are =20 > going to be aware that calendar resources are special. > > My concern is that if there is *any* inconsistency between the =20 > general solution when it comes and CalDAV's, that an implementor =20 > may have to choose between being compliant with CalDAV or the more =20 > general ETag spec, or may have to continue to implement special =20 > semantics on calendar resources for purposes which are better =20 > served by the other spec. > > I realize that "the other spec" doesn't exist today, and that =20 > this is a total drag. Can't we take your one paragraph and put it =20 > into its own document? I don't know IETF process very well, so I =20 > don't know what the next steps should be, but as an implementor, =20 > I'm uncomfortable with the prospect of dealing with two =20 > independently written specifications for the same behavior. We basically tried that. What it turned into was this with =20 no consensus on the basic model or apparent drive to come to =20 consensus. Got any feedback on that draft? Lisa > > -wsv > > > On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote: > >> Wilfredo, does it make a difference that CalDAV specifies special =20 >> ETag behavior only on Calendar Component resource items (not for =20 >> all HTTP resources)? > 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 1BDE57F8BE for ; Tue, 20 Jun 2006 16:55:56 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AC1A4142293; Tue, 20 Jun 2006 16:55:55 -0700 (PDT) In-Reply-To: <449828CC.3030700@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <4496FDDD.8010405@gmx.de> <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@osafoundation.org> <449828CC.3030700@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <430D8860-3906-4210-8DD9-5CFCC5843176@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Tue, 20 Jun 2006 16:55:52 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 23:55:56 -0000 On Jun 20, 2006, at 9:56 AM, Julian Reschke wrote: > Lisa Dusseault schrieb: >> Xythos WFC and Chandler (the Zanshin library that does WebDAV in >> python) behave this way and make the assumption I describe. How >> else would you expect a caching or synching client to behave after >> doing a PUT, when the implementors of those clients were pretty >> sure that WebDAV servers stored the content without mucking with it? > > Chandler is not released and obviously operating based on what the > CalDAV spec currently says. > > Regarding the Xythos client: I just did some tests, and as far as I > can tell the behavior is the same independantly of whether the > server returns an ETag in PUT: the client always assumes that > content was not rewritten, and in the absence of an ETag uses the > Last-Modified date to check. So it seems that it doesn't handle > content-rewriting servers at all, right? (one needs to manually > purge the cache to get the actual content). My assertion was that if a strong ETag is returned, Xythos WFC assumes that what it PUT was what the server stored, and it seems you agree. You found that if a Last-Modified is returned instead, WFC makes the same assumption -- naturally, they're very similar. You're probably quite right about the general case, that existing WebDAV clients don't handle content-rewriting servers at all. What's the best thing a content-rewriting server can do in this situation? I would hope that if a client receives neither an ETag nor a Last- Modified in a PUT response, then the next time it synchronizes and sees an ETag that it's never seen before, the client downloads the resource. This allows the content to eventually get synchronized although perhaps not as fast as would be ideal. But CalDAV clients will have to handle content-rewriting servers at least handling events (calendar component resources), because during protocol development we heard from a couple server developers that they'd need to add custom iCalendar properties to an event as soon as it was stored, thus rewriting the content. 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 BB43B7F7C9; Tue, 20 Jun 2006 10:27:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 97A101422A4; Tue, 20 Jun 2006 10:27:48 -0700 (PDT) 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 29502-04; Tue, 20 Jun 2006 10:27:46 -0700 (PDT) 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 19CD914229A; Tue, 20 Jun 2006 10:27:46 -0700 (PDT) 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 k5KHRerM007832; Tue, 20 Jun 2006 10:27:40 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id 8B5B0BD; Tue, 20 Jun 2006 10:27:40 -0700 (PDT) In-Reply-To: <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Tue, 20 Jun 2006 10:27:39 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.750) 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: Cc: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 17:27:48 -0000 Not really, no. HTTP defines ETag. An HTTP server should be able to use the same ETag logic on all HTTP resources, and not treat ETags for calendar resources differently than others. Not all users of ETags are going to be aware that calendar resources are special. My concern is that if there is *any* inconsistency between the general solution when it comes and CalDAV's, that an implementor may have to choose between being compliant with CalDAV or the more general ETag spec, or may have to continue to implement special semantics on calendar resources for purposes which are better served by the other spec. I realize that "the other spec" doesn't exist today, and that this is a total drag. Can't we take your one paragraph and put it into its own document? I don't know IETF process very well, so I don't know what the next steps should be, but as an implementor, I'm uncomfortable with the prospect of dealing with two independently written specifications for the same behavior. -wsv On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote: > Wilfredo, does it make a difference that CalDAV specifies special > ETag behavior only on Calendar Component resource items (not for > all HTTP resources)? 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 8D4737F7E9 for ; Tue, 20 Jun 2006 09:56:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 684E014229F for ; Tue, 20 Jun 2006 09:56:42 -0700 (PDT) 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 07895-03 for ; Tue, 20 Jun 2006 09:56:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 6930F142296 for ; Tue, 20 Jun 2006 09:56:41 -0700 (PDT) Received: (qmail invoked by alias); 20 Jun 2006 16:56:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 20 Jun 2006 18:56:39 +0200 X-Authenticated: #1915285 Message-ID: <449828CC.3030700@gmx.de> Date: Tue, 20 Jun 2006 18:56:44 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <4496FDDD.8010405@gmx.de> <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@osafoundation.org> In-Reply-To: <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 16:56:42 -0000 Lisa Dusseault schrieb: > > Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) > behave this way and make the assumption I describe. How else would you > expect a caching or synching client to behave after doing a PUT, when > the implementors of those clients were pretty sure that WebDAV servers > stored the content without mucking with it? Chandler is not released and obviously operating based on what the CalDAV spec currently says. Regarding the Xythos client: I just did some tests, and as far as I can tell the behavior is the same independantly of whether the server returns an ETag in PUT: the client always assumes that content was not rewritten, and in the absence of an ETag uses the Last-Modified date to check. So it seems that it doesn't handle content-rewriting servers at all, right? (one needs to manually purge the cache to get the actual content). > Your turn now: do you have an example of a general-purpose (e.g. file > sharing, site synch) shipping client that handles ETags and caches or > synchronizes content, which does a full GET of the content immediately > after PUT even if it receives a strong ETag? No. And I don't think it necessarily needs to, unless it assumes that it can use the ETag in subsequent GET/Byte-Range operations. > Even if there are such clients, the behavior we describe avoids nasty > errors on both such clients and clients like WFC. It's the conservative > choice. Well, it's a broken choice. There are servers that rewrite content and still return ETags upon PUT, and HTTP allows them do that. 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 E5A047F744 for ; Tue, 20 Jun 2006 08:13:47 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 992061422A1; Tue, 20 Jun 2006 08:13:47 -0700 (PDT) In-Reply-To: <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <80E35CD5-943D-4BE2-BA31-8987E6A4F634@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Tue, 20 Jun 2006 08:13:44 -0700 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.750) Cc: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 15:13:48 -0000 Wilfredo, does it make a difference that CalDAV specifies special =20 ETag behavior only on Calendar Component resource items (not for all =20 HTTP resources)? lisa On Jun 19, 2006, at 12:58 PM, Wilfredo S=E1nchez Vega wrote: > Sure, OK, so some clients are broken today because they make some =20= > assumptions that are only valid on some server implementations. > > We know we need a solution; I just don't agree that CalDAV is the =20= > right place to specify it. I do understand how it's convenient. > > -wsv > > > On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote: > >> It's worse than that; many client authors *assumed* that to be the =20= >> case, and implemented and deployed their clients assuming that if =20 >> the client receives a strong ETag in response to a PUT, it has no =20 >> further work to do to synchronize that resource. So the deployed =20 >> base says that *is* the case today. I don't feel our document =20 >> makes this situation any worse than the deployed base of clients =20 >> already does. > 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 B1D5E7F851 for ; Tue, 20 Jun 2006 08:11:50 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4FA101422C2; Tue, 20 Jun 2006 08:11:50 -0700 (PDT) In-Reply-To: <4496FDDD.8010405@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <4496FDDD.8010405@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Tue, 20 Jun 2006 08:11:47 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.750) Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Ted Hardie , HTTP Working Group , ietf@ietf.org, 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: Tue, 20 Jun 2006 15:11:50 -0000 Xythos WFC and Chandler (the Zanshin library that does WebDAV in =20 python) behave this way and make the assumption I describe. How else =20= would you expect a caching or synching client to behave after doing a =20= PUT, when the implementors of those clients were pretty sure that =20 WebDAV servers stored the content without mucking with it? Your turn now: do you have an example of a general-purpose (e.g. =20 file sharing, site synch) shipping client that handles ETags and =20 caches or synchronizes content, which does a full GET of the content =20 immediately after PUT even if it receives a strong ETag? Even if there are such clients, the behavior we describe avoids nasty =20= errors on both such clients and clients like WFC. It's the =20 conservative choice. Lisa On Jun 19, 2006, at 12:41 PM, Julian Reschke wrote: > Lisa Dusseault schrieb: >> On Jun 15, 2006, at 9:32 AM, Wilfredo S=E1nchez Vega wrote: >>> I agree with Julian. >>> >>> As we've mentioned before, Apache returns a weak ETag on PUT, =20 >>> which turns into a strong ETag sometime later. If clients rely =20 >>> on being able to use that ETag on a GET later, they won't work =20 >>> with Apache, and IIRC, Apache is pretty popular. >>> >>> The ETag requirements in the draft are what many clients =20 >>> authors might *like* to be the common case, but it is most =20 >>> certainly not so today. >> It's worse than that; many client authors *assumed* that to be the =20= >> case, and implemented and deployed their clients assuming that if =20 >> the client receives a strong ETag in response to a PUT, it has no =20 >> further work to do to synchronize that resource. So the deployed =20 >> base says that *is* the case today. I don't feel our document =20 >> makes this situation any worse than the deployed base of clients =20 >> already does. >> Lisa > > Again: do you have any evidence of *shipping* clients making that =20 > assumption? > > 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 935437F728; Mon, 19 Jun 2006 12:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FC681422BB; Mon, 19 Jun 2006 12:58:36 -0700 (PDT) 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 07718-06; Mon, 19 Jun 2006 12:58:34 -0700 (PDT) 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 E3AAA1422A0; Mon, 19 Jun 2006 12:58:33 -0700 (PDT) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k5JJwThB004162; Mon, 19 Jun 2006 12:58:29 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id 68A65163; Mon, 19 Jun 2006 12:58:29 -0700 (PDT) In-Reply-To: <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Mon, 19 Jun 2006 12:58:28 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.750) 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: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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 Jun 2006 19:58:36 -0000 Sure, OK, so some clients are broken today because they make some assumptions that are only valid on some server implementations. We know we need a solution; I just don't agree that CalDAV is the right place to specify it. I do understand how it's convenient. -wsv On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote: > It's worse than that; many client authors *assumed* that to be the > case, and implemented and deployed their clients assuming that if > the client receives a strong ETag in response to a PUT, it has no > further work to do to synchronize that resource. So the deployed > base says that *is* the case today. I don't feel our document > makes this situation any worse than the deployed base of clients > already does. 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 A8F337F75F for ; Mon, 19 Jun 2006 12:41:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 84E9E1422BC for ; Mon, 19 Jun 2006 12:41:25 -0700 (PDT) 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 00511-07 for ; Mon, 19 Jun 2006 12:41:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 7500814229C for ; Mon, 19 Jun 2006 12:41:21 -0700 (PDT) Received: (qmail invoked by alias); 19 Jun 2006 19:41:17 -0000 Received: from p508FBF90.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.144] by mail.gmx.net (mp042) with SMTP; 19 Jun 2006 21:41:17 +0200 X-Authenticated: #1915285 Message-ID: <4496FDDD.8010405@gmx.de> Date: Mon, 19 Jun 2006 21:41:17 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> In-Reply-To: <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Ted Hardie , HTTP Working Group , ietf@ietf.org, 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 Jun 2006 19:41:25 -0000 Lisa Dusseault schrieb: > > On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote: > >> I agree with Julian. >> >> As we've mentioned before, Apache returns a weak ETag on PUT, which >> turns into a strong ETag sometime later. If clients rely on being >> able to use that ETag on a GET later, they won't work with Apache, and >> IIRC, Apache is pretty popular. >> >> The ETag requirements in the draft are what many clients authors >> might *like* to be the common case, but it is most certainly not so >> today. > > It's worse than that; many client authors *assumed* that to be the case, > and implemented and deployed their clients assuming that if the client > receives a strong ETag in response to a PUT, it has no further work to > do to synchronize that resource. So the deployed base says that *is* > the case today. I don't feel our document makes this situation any > worse than the deployed base of clients already does. > > Lisa Again: do you have any evidence of *shipping* clients making that assumption? 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 9071E7F6A8 for ; Mon, 19 Jun 2006 12:33:05 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F8C114229C; Mon, 19 Jun 2006 12:33:05 -0700 (PDT) In-Reply-To: References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Mon, 19 Jun 2006 12:32:53 -0700 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.750) Cc: Ted Hardie , HTTP Working Group , ietf@ietf.org, 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 Jun 2006 19:33:05 -0000 On Jun 15, 2006, at 9:32 AM, Wilfredo S=E1nchez Vega wrote: > I agree with Julian. > > As we've mentioned before, Apache returns a weak ETag on PUT, =20 > which turns into a strong ETag sometime later. If clients rely on =20 > being able to use that ETag on a GET later, they won't work with =20 > Apache, and IIRC, Apache is pretty popular. > > The ETag requirements in the draft are what many clients authors =20 > might *like* to be the common case, but it is most certainly not so =20= > today. It's worse than that; many client authors *assumed* that to be the =20 case, and implemented and deployed their clients assuming that if the =20= client receives a strong ETag in response to a PUT, it has no further =20= work to do to synchronize that resource. So the deployed base says =20 that *is* the case today. I don't feel our document makes this =20 situation any worse than the deployed base of clients already does. Lisa > > Additionally, the draft doesn't just say that servers SHOULD =20 > return an ETag in a response when the data has not changed, but =20 > also that they MUST NOT do so if the data did change. It's not =20 > entirely clear that this is the direction things will go, and any =20 > MUST requirements which conflict with whatever we do come up with =20 > later will be a real headache. > > -wsv > > > On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote: > >> I noticed that the ID tracker now has a comment from the authors =20 >> (see > command=3Dview_comment&id=3D52124>), which I'd like to comment over =20= >> here...: >> >>> Author's response to Last Call comments on ETags >>> 1) Best common practice in WebDAV >>> Currently very few, if any at all, WebDAV servers change the =20 >>> content of resource data during a PUT request. Most WebDAV =20 >>> servers do return an ETag on PUT. Thus clients have come to rely =20 >>> on the presence of the ETag to effectively mean that the resource =20= >>> data was stored unchanged and that the ETag can be used in =20 >>> subsequent GET requests etc. This justifies our statement that =20 >>> servers SHOULD return an ETag in a response when the data has not =20= >>> changed. >> >> I have my doubts that this statement is based on actual testing. =20 >> In particular it seems to me that making claims about "most" =20 >> servers isn't useful here; servers that do rewrite content do =20 >> exist, but they are certainly outnumbered *installation-wise* by =20 >> IIS and Apache/moddav/fs which implement WebDAV as a "dumb" store =20 >> (in that they don't support special semantics on specific content =20 >> types). But that doesn't mean that being incompatible with that =20 >> class of servers (being fully compliant to RFC2616 and RFC2518) is =20= >> acceptable. >> >> That being said, I just tested: >> >> - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned =20 >> upon PUT >> >> - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT >> >> - Xythos WFS (on www.sharemation.com): ETag returned >> >> - SAP Netweaver KM: ETag returned although content may be rewritten >> >> It seems to me that this shows that the statement above is =20 >> misleading. >> >>> Now we have CalDAV servers where the resource data MAY be =20 >>> changed. Therefore to be compatible with existing client behavior =20= >>> a server MUST NOT send the ETag in a PUT response when the data =20 >>> changes, otherwise clients will misinterpret it. This justifies =20 >>> our 'MUST NOT' statement. >> >> It would be helpful if you could provide an example of a =20 >> *shipping* client that breaks if an ETag is returned upon PUT =20 >> although content was rewritten. >> >>> 2) Restricted behavior >>> The ETag behavior we are talking about is restricted solely to =20 >>> calendar object resources being stored in calendar collections - =20 >>> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP =20= >>> behavior by rather extending it for this one specific application =20= >>> need. >> >> But it's still an HTTP and WebDAV resource. A CalDAV server that =20 >> also happens to be a generic WebDAV server may need to make this a =20= >> special case then. And this may be hard to do should there be =20 >> another HTTP/WebDAV related specification making an incompatible =20 >> requirement. >> >> As a matter of fact, in February the IESG has decided to solve =20 >> that very problem in a separate activity (see draft-whitehead-http-=20= >> etag-00), independently of WebDAV and CalDAV. And, indeed, =20 >> RFC2518bis (the revision of WebDAV) delegates resolution of the =20 >> question to that very spec, instead of coming up with it's own. =20 >> This is what CalDAV should also be doing. >> >>> 3) Future conflicts >>> One of Julian's arguments is that our requirement will "risk =20 >>> making CalDAV incompatible with other specs extending HTTP (or =20 >>> HTTP itself, for that matter)". Since we have been careful to =20 >>> require only behavior that already exists in deployed WebDAV =20 >>> servers, CalDAV adds no further incompatibility. If future work =20 >>> to better define the meaning of ETag on PUT ever happens, it will =20= >>> need to take into account the deployed base, and the subset of =20 >>> CalDAV servers will simply happen to be a consistently behaving =20 >>> subset. We believe that our requirements improve the =20 >>> interoperability of CalDAV, without making the future/potential =20 >>> incompatibility problem any worse than it already is. >> >> See notes above. The behavior required by CalDAV is *not* what =20 >> current servers do. At least not the majority. >> >>> 4) Need/usefulness >>> In addition to the authors' evaluation of the usefulness of this =20 >>> feature for keeping an offline calendar correct, there have been =20 >>> other requests for predictable behavior w.r.t. PUT and ETags and =20 >>> calendar resources. This was one of the first feature requests =20 >>> from client implementors, including Dan Mosedale and Grant Baillie. >> >> I totally agree that clients may be interested in finding out =20 >> whether content was rewritten. The solution to this is to either =20 >> put more energy into draft-whitehead-http-etag-00, or to have a =20 >> CalDAV-specific solution that by design wouldn't interfere with =20 >> what we define in other specs later, as outlined in > lists.osafoundation.org/pipermail/ietf-caldav/2006-April/=20 >> 000787.html>. I'd really like to here why the solution suggested =20 >> back then isn't sufficient for CalDAV. >> >> >> 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 > > _______________________________________________ > 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 0FECC7F7D6 for ; Thu, 15 Jun 2006 09:33:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1962142336 for ; Thu, 15 Jun 2006 09:33:34 -0700 (PDT) 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 14643-09 for ; Thu, 15 Jun 2006 09:33:32 -0700 (PDT) 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 EF490142320 for ; Thu, 15 Jun 2006 09:33:31 -0700 (PDT) Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k5FGWrT5004924; Thu, 15 Jun 2006 09:32:53 -0700 (PDT) Received: from [17.221.42.43] (unknown [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id C0A44279; Thu, 15 Jun 2006 09:32:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44913E39.7040503@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Thu, 15 Jun 2006 09:32:51 -0700 To: Julian Reschke , ietf@ietf.org, Ted Hardie , CalDAV DevList , HTTP Working Group X-Mailer: Apple Mail (2.750) 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: 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 Jun 2006 16:33:35 -0000 I agree with Julian. As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't work with Apache, and IIRC, Apache is pretty popular. The ETag requirements in the draft are what many clients authors might *like* to be the common case, but it is most certainly not so today. Additionally, the draft doesn't just say that servers SHOULD return an ETag in a response when the data has not changed, but also that they MUST NOT do so if the data did change. It's not entirely clear that this is the direction things will go, and any MUST requirements which conflict with whatever we do come up with later will be a real headache. -wsv On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote: > I noticed that the ID tracker now has a comment from the authors > (see command=view_comment&id=52124>), which I'd like to comment over > here...: > >> Author's response to Last Call comments on ETags >> 1) Best common practice in WebDAV >> Currently very few, if any at all, WebDAV servers change the >> content of resource data during a PUT request. Most WebDAV servers >> do return an ETag on PUT. Thus clients have come to rely on the >> presence of the ETag to effectively mean that the resource data >> was stored unchanged and that the ETag can be used in subsequent >> GET requests etc. This justifies our statement that servers SHOULD >> return an ETag in a response when the data has not changed. > > I have my doubts that this statement is based on actual testing. In > particular it seems to me that making claims about "most" servers > isn't useful here; servers that do rewrite content do exist, but > they are certainly outnumbered *installation-wise* by IIS and > Apache/moddav/fs which implement WebDAV as a "dumb" store (in that > they don't support special semantics on specific content types). > But that doesn't mean that being incompatible with that class of > servers (being fully compliant to RFC2616 and RFC2518) is acceptable. > > That being said, I just tested: > > - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon > PUT > > - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT > > - Xythos WFS (on www.sharemation.com): ETag returned > > - SAP Netweaver KM: ETag returned although content may be rewritten > > It seems to me that this shows that the statement above is misleading. > >> Now we have CalDAV servers where the resource data MAY be changed. >> Therefore to be compatible with existing client behavior a server >> MUST NOT send the ETag in a PUT response when the data changes, >> otherwise clients will misinterpret it. This justifies our 'MUST >> NOT' statement. > > It would be helpful if you could provide an example of a *shipping* > client that breaks if an ETag is returned upon PUT although content > was rewritten. > >> 2) Restricted behavior >> The ETag behavior we are talking about is restricted solely to >> calendar object resources being stored in calendar collections - >> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP >> behavior by rather extending it for this one specific application >> need. > > But it's still an HTTP and WebDAV resource. A CalDAV server that > also happens to be a generic WebDAV server may need to make this a > special case then. And this may be hard to do should there be > another HTTP/WebDAV related specification making an incompatible > requirement. > > As a matter of fact, in February the IESG has decided to solve that > very problem in a separate activity (see draft-whitehead-http- > etag-00), independently of WebDAV and CalDAV. And, indeed, > RFC2518bis (the revision of WebDAV) delegates resolution of the > question to that very spec, instead of coming up with it's own. > This is what CalDAV should also be doing. > >> 3) Future conflicts >> One of Julian's arguments is that our requirement will "risk >> making CalDAV incompatible with other specs extending HTTP (or >> HTTP itself, for that matter)". Since we have been careful to >> require only behavior that already exists in deployed WebDAV >> servers, CalDAV adds no further incompatibility. If future work to >> better define the meaning of ETag on PUT ever happens, it will >> need to take into account the deployed base, and the subset of >> CalDAV servers will simply happen to be a consistently behaving >> subset. We believe that our requirements improve the >> interoperability of CalDAV, without making the future/potential >> incompatibility problem any worse than it already is. > > See notes above. The behavior required by CalDAV is *not* what > current servers do. At least not the majority. > >> 4) Need/usefulness >> In addition to the authors' evaluation of the usefulness of this >> feature for keeping an offline calendar correct, there have been >> other requests for predictable behavior w.r.t. PUT and ETags and >> calendar resources. This was one of the first feature requests >> from client implementors, including Dan Mosedale and Grant Baillie. > > I totally agree that clients may be interested in finding out > whether content was rewritten. The solution to this is to either > put more energy into draft-whitehead-http-etag-00, or to have a > CalDAV-specific solution that by design wouldn't interfere with > what we define in other specs later, as outlined in lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ > 000787.html>. I'd really like to here why the solution suggested > back then isn't sufficient for CalDAV. > > > 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 45DAE7F789 for ; Thu, 15 Jun 2006 04:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 333AF142338 for ; Thu, 15 Jun 2006 04:02:22 -0700 (PDT) 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 29355-05 for ; Thu, 15 Jun 2006 04:02:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id DA06414232E for ; Thu, 15 Jun 2006 04:02:19 -0700 (PDT) Received: (qmail invoked by alias); 15 Jun 2006 11:02:18 -0000 Received: from p508FB7A2.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.183.162] by mail.gmx.net (mp028) with SMTP; 15 Jun 2006 13:02:18 +0200 X-Authenticated: #1915285 Message-ID: <44913E39.7040503@gmx.de> Date: Thu, 15 Jun 2006 13:02:17 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> In-Reply-To: <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> 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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , CalDAV DevList , HTTP Working Group 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 Jun 2006 11:02:23 -0000 I noticed that the ID tracker now has a comment from the authors (see ), which I'd like to comment over here...: > Author's response to Last Call comments on ETags > > 1) Best common practice in WebDAV > > Currently very few, if any at all, WebDAV servers change the content of resource data during a PUT request. Most WebDAV servers do return an ETag on PUT. Thus clients have come to rely on the presence of the ETag to effectively mean that the resource data was stored unchanged and that the ETag can be used in subsequent GET requests etc. This justifies our statement that servers SHOULD return an ETag in a response when the data has not changed. I have my doubts that this statement is based on actual testing. In particular it seems to me that making claims about "most" servers isn't useful here; servers that do rewrite content do exist, but they are certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs which implement WebDAV as a "dumb" store (in that they don't support special semantics on specific content types). But that doesn't mean that being incompatible with that class of servers (being fully compliant to RFC2616 and RFC2518) is acceptable. That being said, I just tested: - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT - Xythos WFS (on www.sharemation.com): ETag returned - SAP Netweaver KM: ETag returned although content may be rewritten It seems to me that this shows that the statement above is misleading. > Now we have CalDAV servers where the resource data MAY be changed. Therefore to be compatible with existing client behavior a server MUST NOT send the ETag in a PUT response when the data changes, otherwise clients will misinterpret it. This justifies our 'MUST NOT' statement. It would be helpful if you could provide an example of a *shipping* client that breaks if an ETag is returned upon PUT although content was rewritten. > 2) Restricted behavior > > The ETag behavior we are talking about is restricted solely to calendar object resources being stored in calendar collections - i.e. it is very specific to CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this one specific application need. But it's still an HTTP and WebDAV resource. A CalDAV server that also happens to be a generic WebDAV server may need to make this a special case then. And this may be hard to do should there be another HTTP/WebDAV related specification making an incompatible requirement. As a matter of fact, in February the IESG has decided to solve that very problem in a separate activity (see draft-whitehead-http-etag-00), independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the revision of WebDAV) delegates resolution of the question to that very spec, instead of coming up with it's own. This is what CalDAV should also be doing. > 3) Future conflicts > > One of Julian's arguments is that our requirement will "risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter)". Since we have been careful to require only behavior that already exists in deployed WebDAV servers, CalDAV adds no further incompatibility. If future work to better define the meaning of ETag on PUT ever happens, it will need to take into account the deployed base, and the subset of CalDAV servers will simply happen to be a consistently behaving subset. We believe that our requirements improve the interoperability of CalDAV, without making the future/potential incompatibility problem any worse than it already is. See notes above. The behavior required by CalDAV is *not* what current servers do. At least not the majority. > 4) Need/usefulness > > In addition to the authors' evaluation of the usefulness of this feature for keeping an offline calendar correct, there have been other requests for predictable behavior w.r.t. PUT and ETags and calendar resources. This was one of the first feature requests from client implementors, including Dan Mosedale and Grant Baillie. I totally agree that clients may be interested in finding out whether content was rewritten. The solution to this is to either put more energy into draft-whitehead-http-etag-00, or to have a CalDAV-specific solution that by design wouldn't interfere with what we define in other specs later, as outlined in . I'd really like to here why the solution suggested back then isn't sufficient for CalDAV. 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 EC5547F72F for ; Mon, 5 Jun 2006 16:50:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD1691422E4 for ; Mon, 5 Jun 2006 16:50:17 -0700 (PDT) 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 05904-02 for ; Mon, 5 Jun 2006 16:50:17 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 44E921422E0 for ; Mon, 5 Jun 2006 16:50:17 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k55NoCF5020370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jun 2006 16:50:13 -0700 Received: from [129.46.225.24] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k55NoAOJ022830; Mon, 5 Jun 2006 16:50:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> Date: Mon, 5 Jun 2006 16:50:09 -0700 To: Cyrus Daboo , Julian Reschke From: Ted Hardie Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Content-Type: text/plain; charset="us-ascii" 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 X-Spam-Level: X-Mailman-Approved-At: Fri, 16 Jun 2006 08:25:18 -0700 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, 05 Jun 2006 23:50:18 -0000 >From a previous conversation, I thought that the authors had concluded that the current text would be retained but that the IETF should note that the best way forward would be a more general resolution of the ETag issue. I also believe if that results in the CalDav point solution being out of the mainstream, it would have to re-cycle at proposed and deal with the upgrade problems. Since there is no more general solution available, it seemed to me reasonable not to hold the document back for the resolution to work that has not really begun, provided the community was made aware of the issues in the write-up. If the authors are still considering the issue, though, this document is not ready for IESG consideration. I have removed it from this week's agenda. I have temporarily put it back two weeks, but it may move further (or back through Last Call) if the authors decide on significant changes. regards, Ted Hardie At 2:34 PM -0400 6/5/06, Cyrus Daboo wrote: >Hi Julian, > >--On June 5, 2006 8:30:25 PM +0200 Julian Reschke wrote: > >>I notice that draft-dusseault-caldav-12 now is in IESG Evaluation >>(>=11253>). >> >>For the record: as far as I can tell, the issue that I raised below is >>critical (given the fact that we have a separate activity to clarify this >>in HTTP), and has not been addressed. It's not clear to me whether the >>client issue it attempts to solve really is important. If it is, there is >>a simpler way to accomplish this ([1]) that doesn't risk making CalDAV >>incompatible with other specs extending HTTP (or HTTP itself, for that >>matter). > >We are planning on addressing this ETag issue in a revision now that last-call is over. Authors are discussing right now. > >-- >Cyrus Daboo > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf 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 D98367F759 for ; Mon, 5 Jun 2006 11:34:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAD2F1422BA for ; Mon, 5 Jun 2006 11:34:28 -0700 (PDT) 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 25312-03 for ; Mon, 5 Jun 2006 11:34:26 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 466E71422A8 for ; Mon, 5 Jun 2006 11:34:26 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id EBA13D68FA7; Mon, 5 Jun 2006 14:34:24 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Mon, 05 Jun 2006 14:34:27 -0400 X-Sasl-enc: em1oVeABaaSx3nPftLSAzsz5NZUUgwPGQdyqLpuWEi00 1149532466 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 2921E88E7; Mon, 5 Jun 2006 14:34:23 -0400 (EDT) Date: Mon, 05 Jun 2006 14:34:17 -0400 From: Cyrus Daboo To: Julian Reschke , ietf@ietf.org Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Message-ID: <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> In-Reply-To: <44847841.8080902@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> X-Mailer: Mulberry/4.0.5 (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.7 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , 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, 05 Jun 2006 18:34:29 -0000 Hi Julian, --On June 5, 2006 8:30:25 PM +0200 Julian Reschke wrote: > I notice that draft-dusseault-caldav-12 now is in IESG Evaluation > ( =11253>). > > For the record: as far as I can tell, the issue that I raised below is > critical (given the fact that we have a separate activity to clarify this > in HTTP), and has not been addressed. It's not clear to me whether the > client issue it attempts to solve really is important. If it is, there is > a simpler way to accomplish this ([1]) that doesn't risk making CalDAV > incompatible with other specs extending HTTP (or HTTP itself, for that > matter). We are planning on addressing this ETag issue in a revision now that last-call is over. Authors are discussing right now. -- 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 9041A7F757 for ; Mon, 5 Jun 2006 11:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A2961422BE for ; Mon, 5 Jun 2006 11:30:28 -0700 (PDT) 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 13165-08 for ; Mon, 5 Jun 2006 11:30:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 43FF91422BA for ; Mon, 5 Jun 2006 11:30:26 -0700 (PDT) Received: (qmail invoked by alias); 05 Jun 2006 18:30:24 -0000 Received: from p508FC0FC.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.192.252] by mail.gmx.net (mp005) with SMTP; 05 Jun 2006 20:30:24 +0200 X-Authenticated: #1915285 Message-ID: <44847841.8080902@gmx.de> Date: Mon, 05 Jun 2006 20:30:25 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> In-Reply-To: <44512C9B.6090102@gmx.de> 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.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , 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, 05 Jun 2006 18:30:28 -0000 Hi. I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (). For the record: as far as I can tell, the issue that I raised below is critical (given the fact that we have a separate activity to clarify this in HTTP), and has not been addressed. It's not clear to me whether the client issue it attempts to solve really is important. If it is, there is a simpler way to accomplish this ([1]) that doesn't risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter). Best regards, Julian [1] Julian Reschke wrote: > Lisa Dusseault wrote: >> Thanks for the input. Speaking as a document author here, I'm >> confident we've made a decent set of tradeoffs, balancing possible >> risks against benefits, and attempting to minimize the risks too. >> >> The basic risk is that any requirements related to ETags may conflict >> with future requirements. We've attempted to minimize this risk by >> making only one requirement -- that servers MUST NOT return strong >> ETags if they have changed the data provided to be stored. We believe >> that this requirement is quite within the spirit of ETag design. We >> didn't make any requirements about weak ETags, nor did we require any >> behavior that future specs might make illegal. Since today with HTTP >> it's perfectly acceptable not to return an ETag at all, future >> requirements on ETags would at least have to work with a huge deployed >> base of HTTP servers that don't return any ETag on PUT responses. >> >> Thus, any future ETag-related requirements that invalidated this >> CalDAV requirement, would also conflict with the huge deployed base of >> HTTP. I > > How so? > > A potential requirement of an XyzDav spec to return ETags even though > the content was rewritten wouldn't be in conflict with HTTP at all. It > would just be impossible to implement a resource that's both compliant > to CalDAV and XyzDav. > > This is why I think CalDav uses the wrong approach. There's a simple way > to give CalDav clients that piece of information and which is guaranteed > to be compatible with other specs, and that's what CalDav should do. > > Or, alternatively, it could just stay silent and let that other spec > work out the solution, instead of trying to come up with a fait accompli. > > > ... > > Best regards, Julian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > 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 CAE047F728 for ; Mon, 5 Jun 2006 09:01:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B9A0B1422AF for ; Mon, 5 Jun 2006 09:01:53 -0700 (PDT) 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 06843-04 for ; Mon, 5 Jun 2006 09:01:51 -0700 (PDT) Received: from randymail-a5.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4A7151422AC for ; Mon, 5 Jun 2006 09:01:51 -0700 (PDT) Received: from [192.168.1.31] (c-24-7-127-83.hsd1.ca.comcast.net [24.7.127.83]) by randymail-a5.dreamhost.com (Postfix) with ESMTP id EF2FD8FC5C; Mon, 5 Jun 2006 09:01:50 -0700 (PDT) Message-ID: <4484556E.5030007@acm.org> Date: Mon, 05 Jun 2006 09:01:50 -0700 From: Andrew Hsu User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] What happened to the CalDav website? References: <4483208B.6070704@acm.org> <44842CFD.3080404@oracle.com> In-Reply-To: <44842CFD.3080404@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.0 tagged_above=-50.0 required=4.0 tests=WORK_AT_HOME X-Spam-Level: Cc: Ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrewhsu@acm.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: Mon, 05 Jun 2006 16:01:53 -0000 Thanks--that worked. Bernard Desruisseaux wrote: > There's an issue with the machine alias "ietf.webdav.org". > > Try this URL: http://ietf.cse.ucsc.edu/caldav > > Cheers, > Bernard > > Andrew Hsu wrote: >> Hello, >> >> I use to visit the CalDav website quite a lot, but the last few days >> I've been unable to connect: >> >> http://caldav.org/ >> http://www.caldav.org/ >> http://ietf.webdav.org/caldav/ >> >> They all timeout on me from work or from home (Comcast). >> >> Is the site down for maintenance or has it moved to a new location? >> Even the Google cache has a blank page: >> http://www.google.com/search?q=cache:www.caldav.org >> >> Cheers, >> Andrew >> -- . . Andrew Hsu . email: andrewhsu@acm.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 9810B7F763 for ; Mon, 5 Jun 2006 06:10:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A7221422E0 for ; Mon, 5 Jun 2006 06:10:12 -0700 (PDT) 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 14988-07 for ; Mon, 5 Jun 2006 06:10:09 -0700 (PDT) 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 E94191422D6 for ; Mon, 5 Jun 2006 06:10:07 -0700 (PDT) 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 k55DA3RO013812; Mon, 5 Jun 2006 08:10:04 -0500 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k55DA2Yx010370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 5 Jun 2006 07:10:03 -0600 Message-ID: <44842CFD.3080404@oracle.com> Date: Mon, 05 Jun 2006 09:09:17 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: andrewhsu@acm.org Subject: Re: [Ietf-caldav] What happened to the CalDav website? References: <4483208B.6070704@acm.org> In-Reply-To: <4483208B.6070704@acm.org> 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.9 tagged_above=-50.0 required=4.0 tests=AWL, WORK_AT_HOME 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, 05 Jun 2006 13:10:12 -0000 There's an issue with the machine alias "ietf.webdav.org". Try this URL: http://ietf.cse.ucsc.edu/caldav Cheers, Bernard Andrew Hsu wrote: > Hello, > > I use to visit the CalDav website quite a lot, but the last few days > I've been unable to connect: > > http://caldav.org/ > http://www.caldav.org/ > http://ietf.webdav.org/caldav/ > > They all timeout on me from work or from home (Comcast). > > Is the site down for maintenance or has it moved to a new location? > Even the Google cache has a blank page: > http://www.google.com/search?q=cache:www.caldav.org > > Cheers, > Andrew > 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 1F3C47F80C for ; Sun, 4 Jun 2006 11:04:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 112621422DB for ; Sun, 4 Jun 2006 11:04:00 -0700 (PDT) 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 19457-07 for ; Sun, 4 Jun 2006 11:03:56 -0700 (PDT) Received: from randymail-a6.dreamhost.com (ip-208-97-132-53.dreamhost.com [208.97.132.53]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9819D1422D9 for ; Sun, 4 Jun 2006 11:03:56 -0700 (PDT) Received: from [192.168.1.30] (c-24-7-127-83.hsd1.ca.comcast.net [24.7.127.83]) by randymail-a6.dreamhost.com (Postfix) with ESMTP id 352F3175684 for ; Sun, 4 Jun 2006 11:03:56 -0700 (PDT) Message-ID: <4483208B.6070704@acm.org> Date: Sun, 04 Jun 2006 11:03:55 -0700 From: Andrew Hsu User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Ietf-caldav@osafoundation.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.0 tagged_above=-50.0 required=4.0 tests=WORK_AT_HOME X-Spam-Level: Subject: [Ietf-caldav] What happened to the CalDav website? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrewhsu@acm.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: Sun, 04 Jun 2006 18:04:00 -0000 Hello, I use to visit the CalDav website quite a lot, but the last few days I've been unable to connect: http://caldav.org/ http://www.caldav.org/ http://ietf.webdav.org/caldav/ They all timeout on me from work or from home (Comcast). Is the site down for maintenance or has it moved to a new location? Even the Google cache has a blank page: http://www.google.com/search?q=cache:www.caldav.org Cheers, Andrew -- . . Andrew Hsu . email: andrewhsu@acm.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 A07987F8F1 for ; Fri, 2 Jun 2006 19:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 895D814229F for ; Fri, 2 Jun 2006 19:19:55 -0700 (PDT) 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 14620-09 for ; Fri, 2 Jun 2006 19:19:52 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3792F14229E for ; Fri, 2 Jun 2006 19:19:52 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id m22so664905nzf for ; Fri, 02 Jun 2006 19:19:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SxCLTSTuKMe09nDr9nXcHyl4CrbSewDLF74iT0pTJLgcIREp2NjZd3BXggA3B8eb2m2Yh8y7GosdtpfXPWIeL7rV0WVOxqRPCpBXcEAvI0pgSbweT/2q9cEt5MfojVIXdl3Qg+Aoh/BmlV8UVYSZDLHG92tBmMjjuCHpoqVUpFI= Received: by 10.65.115.4 with SMTP id s4mr2277778qbm; Fri, 02 Jun 2006 19:19:51 -0700 (PDT) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id c6sm1345082qbc.2006.06.02.19.19.50; Fri, 02 Jun 2006 19:19:50 -0700 (PDT) Message-ID: <4480F1C5.9010304@gmail.com> Date: Fri, 02 Jun 2006 22:19:49 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? References: <4476F3D3.1040902@gmail.com> In-Reply-To: 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.2 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP, SARE_LWSHORTT 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, 03 Jun 2006 02:19:56 -0000 Cyrus, I agree with a lot of what you write here, but not your conclusions :) Yes, it is possible to work around all these things by doing more work and sometimes a lot more work. I just have to ask why? What is special about freebusy lookups that mean that they can't be accomplished in a manner that is more widely adopted and that most application developers are very familiar with. The proposed GET matched the functionality of the CalDav freebusy report and so direct comparisons of development effort, testabilty, consumability and deployment can be made, and I still maintain that the effort will be substantially reduced for GET. However, below you seem to be arguing that the CalDav report is "not really useful" and go on to state that more functionality is required and hence GET is not that simple. I am not really following your argument. If the freebusy report in CalDav is useful then it can be accomplished in a simpler manner with a GET. If it is not that useful and something else is needed then we should look at what that is and also see if it is easier to consume, develop, test etc. using a GET vs. REPORT. Finally, if the freebusy report in CalDav really is not that useful then shouldn't it be an optional report, instead of a mandated one? more comments below. Rob Cyrus Daboo wrote: > 1. httpclient/webdavclient libraries etc: > > FYI Last year I built a caldav client library using httpclient and the > slide client library together with my own iCal library. It was trivial > to do (though I knew enough about iCalendar in the first place). WRT > slide library not having been updated in a while - yes that is true > but it seems to work fine - and its open source so you can always > contribute. As to Legal - of course one has to go through that for > every piece of open source software at least once... I agree with this, but as a product manager releasing a piece of software, would you want it to depend on a library that doesn't appear to have much momentum behind it (not having been updated since 2004) and that in turn depends on a jar file that has been end of life'd? > > 2. Using a simple GET request for free-busy: > > The example given is not as simple as it first seems: there is still > work you have to do to at the very least to parse and understand the > date/period format and know what 'BUSY-TENTATIVE' etc means. i.e. the > semantics of calendars still have to be understood no matter what > syntax or protocol is used to transport the data. agreed, but this is nothing to do with the use of http GET vs. webdav REPORT. > > Certainly if all you want is a free-busy view of a single calendar, > the GET approach is trivial and easy. But the reality is there is much > more to calendaring than just that. > > Lets be clear, the free-busy report in CalDAV access is not really > useful when it comes to doing free busy lookups of calendar USERS as > opposed to just looking at a static calendar. The actual need is to > target calendar users (who may have more than one calendar > contributing to their free busy). The CalDAV schedule specification, a > new version of which was published to internet-drafts last week, > addresses this by allowing iTIP free busy requests targeted at one (or > more) local (or possibly remote) users on a CalDAV server. This > returns a much more useful response listing each user's f-b info. It > also deals with the issue of how to grant someone the right to only > see free busy and not the entire calendar data. Am confused by what you are saying here. The GET that I described could have the same functional semantics as the REPORT, namely that it would be possible to pass in the same parameters and get the same response. Are you stating that the REPORT as described in CalDav is not that useful? and if so, why is it mandatory? > > 3. REPORT method and firewalls: > > Any organization that has gone to the trouble to setup a firewall (be > it one that allows WebDAV methods or not) will likely require all > external users to use SSL when connecting from outside when accessing > company sensitive information such as email and calendars. So ssl > (https) will almost certainly be a requirement for CalDAV use and > that, as others have pointed out, pretty much gets around any firewall > problems. Just to be clear the firewall issue is not only applicable to access originating from outside the company's intranet. It applies equally to an end user sat on the corporate network accessing their corporate servers. As we consider using PUT and DELETE methods in our products we are surveying clients infrastructure to see if it is viable. The early results are mixed and it looks likely that we will require a means to tunnel PUT and DELETE over POST, at least for the short term. We are not presently surveying for the REPORT method but I would guess it would produce a similar, if not worse, set of results. SSL is also no magic bullet here as is dramatically effects the throughput that can be achieved on any given server. Most of our customers are not eager to have it turned on for every single server request. > > 4. Make REPORTs optional: > > The reports are a key part of CalDAV, if you make them optional then > you might just as well do plain WebDAV (e.g. GroupDAV) or HTTP. They > are certainly not trivial to implement (well multiget is actually > pretty easy) but most of the complexity is tied up in the calendar > data semantics. For example, a time-range query seems simple at first > glance, but when you take into account all possibilities allowed by > iCalendar (timed, all-day, floating, timezones, recurrences, events > with a start only, to-do's with due only etc) it gets complicated. We > spent a fair bit of time putting together the tables describing how > that works for the different components in the hope that would save > implementers a lot of time. Again, I find myself in violent agreement :). It is hard to do the time-range queries and yes they are a key part, but some of the REPORTS that are mandated in section 7 are much more obtuse. Example 7.7.7 is a case in point In this example, the client requests the server to return the VEVENT components that have the ATTENDEE property with the value "mailto:lisa@example.com" and for which the PARTSTAT parameter is set to "NEEDS-ACTION". Maybe I missed it, but I cannot find the "feature" in my Calandering client (Lotus Notes) that requires this kind of query. If I understand it correctly it asks for all the appointments in a Calendar where Lisa still needs to respond. I know I am tempting fate here, cos I know it is here for a reason, but which Calendaring system currently does this and why? and do all calendaring systems need to do this for interoperability? I just wonder if it is worth prioritizing the REPORTs specified in CalDav and making some optional. You stated above that the freebusy one is not that useful, although I disagree with this. Are there others that are not that useful but mandated. I saw folks on this thread stating both that CalDav was already too complex and asking whether REPORTs should be optional. Is it worth coming up with a more limited mandatory set? > > 5. iCalendar vs XML syntax: > > We did design CalDAV in such a way that an XML-representation of > iCalendar data could be used at some point in the future in a > backwards compatible manner once one has been standardized. It > certainly seems like standardizing that should be the first step to > the simple GET approach and to CalATOM etc. Someone needs to pick up > that effort again and run with it... agreed, I'll see if I can garner any interest on this side. > People have pointed to some benefits of XML syntax, including > XPath/XQuery. But again, those do not address the semantics of > calendaring. The most common query that is likely to used in > calendaring is a time-range query. XPath/XQuery would have to be > extended with a special 'timerange' test function for that to work > properly with recurrences, floating time etc - another syntax does not > hide the complexity of the semantics. agreed, but it reduces the invention to a few functions vs. a whole new query syntax. > > In any case, I do think having an xml syntax a useful thing to have, > but its going to have to live alongside iCalendar for a long time to > come because iCalendar is already widely deployed and used. > Upgrading/changing data formats takes a very long time to do - don't > forget there are still many implementations using the older vCalendar > spec even today (e.g. many mobile devices). agreed > > > 6. xslt on free-busy: > > I'm not an xslt expert, but would welcome comment from others who are. > However, I do question whether a simple transformation is enough. For > example, the user would almost certainly want to see the UTC-relative > free-busy times shifted to their local timezone (or the timezone in > which they are planning the meeting) so the xslt transform would need > to apply timezone/dst rules. Of course you could push the timezone > offset calculation off to the server and have the returned free-busy > times already shifted. Yup, here is a good example of a freebusy listing in html http://ifreebusy.com/neiljensen/freebusy. The XSLT to produce that from an xCal representation would be a fairly trivial modification to the existing web page. > > Summary: > > At first glance having a simple free-busy lookup via GET sounds like a > great idea, but when you look at real use cases and constraints its > going to be a lot harder than originally proposed. Of course it can be > done, but by the time you've finished addressing the real-world use > cases you may well end up with something just as 'hard' to do as the > CalDAV equivalent. A GET with an XML or an iCal response can functionally match the freebusy lookup REPORT in CalDav. It will be substantially less effort to consume in a shipping product for reasons that I point out in gory detail here http://robubu.com/?p=8, end of life'd jars, firewall issues, custom parsers. These are all headaches that we don't have if we stick to what everybody else is doing. I also failed to mention in that post that it is also harder to automate tests for REPORT vs. GET. For a GET, I can use cURL http://curl.haxx.se/docs/, httpunit http://httpunit.sourceforge.net/ or even the browser. I don't know of any WebDav equivalents that are as well maintained. Then there's load testing, does anyone know if loadrunner http://www.mercury.com/us/products/performance-center/loadrunner/ supports REPORT. All of this is more effort > > If people want to pursue this then I encourage you to write up the > actual use cases that need to be addressed and then see what needs to > be done. The GET proposal was to simply match the functionality provided by the freebusy report in CalDav. I was assuming that use case analysis had already been done to ensure that this meets the current needs. The GET proposal is not to address any new functionality, it is just an alternative approach to that currently specified, so I am confused why any further use cases are needed. 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 9FA647F583 for ; Fri, 2 Jun 2006 08:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91DD214226F for ; Fri, 2 Jun 2006 08:39:12 -0700 (PDT) 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 08754-08 for ; Fri, 2 Jun 2006 08:39:09 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E0DB142264 for ; Fri, 2 Jun 2006 08:39:09 -0700 (PDT) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 36567D68DA5 for ; Fri, 2 Jun 2006 11:39:06 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Fri, 02 Jun 2006 11:39:07 -0400 X-Sasl-enc: LIZ7aYi6qMHjNpCBqqQJ1iaId5D0GZrkGG9w1yYyWXdl 1149262747 Received: from [17.101.35.126] (unknown [17.101.35.126]) by www.fastmail.fm (Postfix) with ESMTP id 3508F8199 for ; Fri, 2 Jun 2006 11:39:06 -0400 (EDT) Date: Fri, 02 Jun 2006 11:39:04 -0400 From: Cyrus Daboo To: Ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume? Message-ID: In-Reply-To: <4476F3D3.1040902@gmail.com> References: <4476F3D3.1040902@gmail.com> X-Mailer: Mulberry/4.0.5 (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.7 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, 02 Jun 2006 15:39:12 -0000 Hi, I am going to try and address several of the comments in this thread in one go. 1. httpclient/webdavclient libraries etc: FYI Last year I built a caldav client library using httpclient and the slide client library together with my own iCal library. It was trivial to do (though I knew enough about iCalendar in the first place). WRT slide library not having been updated in a while - yes that is true but it seems to work fine - and its open source so you can always contribute. As to Legal - of course one has to go through that for every piece of open source software at least once... 2. Using a simple GET request for free-busy: The example given is not as simple as it first seems: there is still work you have to do to at the very least to parse and understand the date/period format and know what 'BUSY-TENTATIVE' etc means. i.e. the semantics of calendars still have to be understood no matter what syntax or protocol is used to transport the data. Certainly if all you want is a free-busy view of a single calendar, the GET approach is trivial and easy. But the reality is there is much more to calendaring than just that. Lets be clear, the free-busy report in CalDAV access is not really useful when it comes to doing free busy lookups of calendar USERS as opposed to just looking at a static calendar. The actual need is to target calendar users (who may have more than one calendar contributing to their free busy). The CalDAV schedule specification, a new version of which was published to internet-drafts last week, addresses this by allowing iTIP free busy requests targeted at one (or more) local (or possibly remote) users on a CalDAV server. This returns a much more useful response listing each user's f-b info. It also deals with the issue of how to grant someone the right to only see free busy and not the entire calendar data. 3. REPORT method and firewalls: Any organization that has gone to the trouble to setup a firewall (be it one that allows WebDAV methods or not) will likely require all external users to use SSL when connecting from outside when accessing company sensitive information such as email and calendars. So ssl (https) will almost certainly be a requirement for CalDAV use and that, as others have pointed out, pretty much gets around any firewall problems. 4. Make REPORTs optional: The reports are a key part of CalDAV, if you make them optional then you might just as well do plain WebDAV (e.g. GroupDAV) or HTTP. They are certainly not trivial to implement (well multiget is actually pretty easy) but most of the complexity is tied up in the calendar data semantics. For example, a time-range query seems simple at first glance, but when you take into account all possibilities allowed by iCalendar (timed, all-day, floating, timezones, recurrences, events with a start only, to-do's with due only etc) it gets complicated. We spent a fair bit of time putting together the tables describing how that works for the different components in the hope that would save implementers a lot of time. 5. iCalendar vs XML syntax: We did design CalDAV in such a way that an XML-representation of iCalendar data could be used at some point in the future in a backwards compatible manner once one has been standardized. It certainly seems like standardizing that should be the first step to the simple GET approach and to CalATOM etc. Someone needs to pick up that effort again and run with it... People have pointed to some benefits of XML syntax, including XPath/XQuery. But again, those do not address the semantics of calendaring. The most common query that is likely to used in calendaring is a time-range query. XPath/XQuery would have to be extended with a special 'timerange' test function for that to work properly with recurrences, floating time etc - another syntax does not hide the complexity of the semantics. In any case, I do think having an xml syntax a useful thing to have, but its going to have to live alongside iCalendar for a long time to come because iCalendar is already widely deployed and used. Upgrading/changing data formats takes a very long time to do - don't forget there are still many implementations using the older vCalendar spec even today (e.g. many mobile devices). 6. xslt on free-busy: I'm not an xslt expert, but would welcome comment from others who are. However, I do question whether a simple transformation is enough. For example, the user would almost certainly want to see the UTC-relative free-busy times shifted to their local timezone (or the timezone in which they are planning the meeting) so the xslt transform would need to apply timezone/dst rules. Of course you could push the timezone offset calculation off to the server and have the returned free-busy times already shifted. Summary: At first glance having a simple free-busy lookup via GET sounds like a great idea, but when you look at real use cases and constraints its going to be a lot harder than originally proposed. Of course it can be done, but by the time you've finished addressing the real-world use cases you may well end up with something just as 'hard' to do as the CalDAV equivalent. If people want to pursue this then I encourage you to write up the actual use cases that need to be addressed and then see what needs to be done. You might want to take a look at some of the use cases that Calconnect produced too: . I suspect there is still plenty more to discuss on this topic... -- Cyrus Daboo