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 D694D7F703 for ; Fri, 31 Mar 2006 16:29:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C855A142299 for ; Fri, 31 Mar 2006 16:29:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12594-08 for ; Fri, 31 Mar 2006 16:29:34 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.205]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0406E142283 for ; Fri, 31 Mar 2006 16:29:33 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so394479uge for ; Fri, 31 Mar 2006 16:29:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h0TkhZCMkwjbZ14o2xJHCauC9ruhXCAiRH5HumbCgRXcSFif25ss5wxEu9Sb+0v4KGUCwnBi5DNT9Q8mOiHQo8ISqZIuXIDrZL6Dwkcmt8e/+cfn9v4K+okam+n/+4MYdJamur93P4nsDvVzFukeaElEA9ODRu11R/uXloMgniE= Received: by 10.78.42.7 with SMTP id p7mr28021hup; Fri, 31 Mar 2006 16:29:32 -0800 (PST) Received: by 10.78.75.7 with HTTP; Fri, 31 Mar 2006 16:29:32 -0800 (PST) Message-ID: <29a761a00603311629o5b832408r71d9e16f724af917@mail.gmail.com> Date: Fri, 31 Mar 2006 16:29:32 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 00:29:37 -0000 On 3/31/06, Wilfredo S=E1nchez Vega wrote: > On Mar 30, 2006, at 11:33 AM, Brian Moseley wrote: > > > 1) point my client at the parent collection to publish updates > > 2) tell his friends who use my client the url of the parent collection > > 3) tell his friends who use vanilla caldav clients the url of the > > calendar subcollection > > 4) tell his friends who use vanilla carddav clients the url of the > > contact subcollection > > Just like he'd tells since friends with a generic PDF viewer that > happens to know how to do HTTP GET (Open URL...) to point them at the > PDF document in this collection. Yeah. Or the client will have to > know that if it gets a collection, to search for PDF documents in the > collection and do something useful like offer up a list, etc. > > What you don't do is insist that the PDF document must be able to > store any resources in it that you want and whatnot. Why pretend > that the PDF and the collection that contain the PDF are the same thing? sorry, i'm not even close to getting your point. but the section of my original message that you quoted is specifically what i DON'T want to have to do. i want to avoid a world like that at all costs. it's pretty much what the existing limitations of caldav force on me, though, if i stay rigidly compliant and still try to still include mixed content within one logical "shared content bundle". 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 C5C307F635; Fri, 31 Mar 2006 15:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6E46142295; Fri, 31 Mar 2006 15:54:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19493-01; Fri, 31 Mar 2006 15:53:58 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F43A14224B; Fri, 31 Mar 2006 15:53:58 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k2VNrvtx017640; Fri, 31 Mar 2006 15:53:57 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [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 59B2011; Fri, 31 Mar 2006 15:53:57 -0800 (PST) In-Reply-To: <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) 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] non-calendar resources in calendar collections Date: Fri, 31 Mar 2006 15:53:56 -0800 To: Brian Moseley X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 31 Mar 2006 23:54:00 -0000 On Mar 30, 2006, at 11:33 AM, Brian Moseley wrote: > 1) point my client at the parent collection to publish updates > 2) tell his friends who use my client the url of the parent collection > 3) tell his friends who use vanilla caldav clients the url of the > calendar subcollection > 4) tell his friends who use vanilla carddav clients the url of the > contact subcollection Just like he'd tells since friends with a generic PDF viewer that happens to know how to do HTTP GET (Open URL...) to point them at the PDF document in this collection. Yeah. Or the client will have to know that if it gets a collection, to search for PDF documents in the collection and do something useful like offer up a list, etc. What you don't do is insist that the PDF document must be able to store any resources in it that you want and whatnot. Why pretend that the PDF and the collection that contain the PDF are the same thing? -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1C9E17F737 for ; Thu, 30 Mar 2006 12:18:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E60B142290 for ; Thu, 30 Mar 2006 12:18:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09864-09 for ; Thu, 30 Mar 2006 12:18:20 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.199]) by laweleka.osafoundation.org (Postfix) with ESMTP id 101D714228F for ; Thu, 30 Mar 2006 12:18:19 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so257252uge for ; Thu, 30 Mar 2006 12:18:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WUAQQ1QaX60sjpnDGuzych7mMqPZ/ONzvnYtXSOa2RdMtyhrEjlrx2qY0yUPT0vTnEQiqxkipBQUtjodU3MhWMFl6Anx8qXRx/QdZ/14XrAj3lbxMPHBEanUFmYLiH3oaUjuCYp8iJlNASbMEriE6VRFYRE7z/G8Vt29foad9hk= Received: by 10.78.29.13 with SMTP id c13mr5424huc; Thu, 30 Mar 2006 12:18:19 -0800 (PST) Received: by 10.78.75.7 with HTTP; Thu, 30 Mar 2006 12:18:19 -0800 (PST) Message-ID: <29a761a00603301218h5abc1da0h195fd5a9307c344c@mail.gmail.com> Date: Thu, 30 Mar 2006 12:18:19 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <80634F3962D30890FB6E6CB7@Cyrus-Daboo.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> <80634F3962D30890FB6E6CB7@Cyrus-Daboo.local> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 20:18:23 -0000 On 3/30/06, Cyrus Daboo wrote: > Lets be clear about this: the main reason for this constraint is to allow > support of legacy calendar systems with CalDAV. In order to promote > adoption of CalDAV we want to see CalDAV 'adapters' for the existing larg= e > deployments of such calendaring systems, and crucially make it easy for > CalDAV to sit on top of those. Often such systems ONLY allow calendar dat= a > to be stored, and there is no satisfactory way to store arbitrary data. understood :) > So the bottom line is there will always be some CalDAV servers that canno= t > support non-calendar data in calendar collections. The question then > becomes whether we mandate this behaviour or make it optional so that oth= er > less constrained servers can store arbitrary data. And there in lies the > problem of making a potentially important feature a 'MAY' - it means that > clients cannot rely on it to be present and so have to have two or more > code paths to achieve the same goals. I think history has shown with IMAP > that when that occurs, the client authors nearly always choose to impleme= nt > a single code path - the one that will work with all servers irrespective > of constraints (i.e. in our case be able to work with CalDAV constraints = as > they stand now). and that's fine for most clients. adding the MAY feature allows a (probably small) subset of clients and servers to remain fully interoperable with the rest of the clients and servers out there while adding important new features that are also interoperable, albeit with that same small subset. > I think the examples you give are interesting cases, but they can be solv= ed > in a whole variety of different ways whilst still living with the current > constraints on the data model. but nothing satisfactory has been proposed yet. you could certainly make the case that it's my job to use my brain to come up with a good solution for my software, but if we don't all collaborate on a standard solution that's acceptable to most or all of us, then either my software is not going to be of the quality i want, or it's not going to inteoperate with everyone else's. > I think part of the problem here is trying to impose a user's > 'visualization' of the data on the data store. Its my belief that there > really ought to be a separate 'virtual visualization' layer between the e= nd > user and the data such that they can choose their own arbitrary groupings > based on what makes sense for them. That way constraints on either side c= an > be hidden. how could such a visualization be implemented interoperably? do you think there is an opportunity for an extension to caldav, perhaps, instead of a MAY feature? 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 4FDCB7F728; Thu, 30 Mar 2006 12:09:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3EF63142290; Thu, 30 Mar 2006 12:09:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22418-09; Thu, 30 Mar 2006 12:09:20 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by laweleka.osafoundation.org (Postfix) with ESMTP id 80A4814228F; Thu, 30 Mar 2006 12:09:20 -0800 (PST) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 88DD9D4321C; Thu, 30 Mar 2006 15:09:07 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Thu, 30 Mar 2006 15:08:46 -0500 X-Sasl-enc: RjFEMwWxX7IeO4YI63mDLlLtrYJgkLjwWgJ4Psplikqu 1143749326 Received: from [17.101.34.29] (unknown [17.101.34.29]) by www.fastmail.fm (Postfix) with ESMTP id 35CA41FC9; Thu, 30 Mar 2006 15:08:45 -0500 (EST) Date: Thu, 30 Mar 2006 15:09:05 -0500 From: Cyrus Daboo To: Brian Moseley , CalDAV DevList Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Message-ID: <80634F3962D30890FB6E6CB7@Cyrus-Daboo.local> In-Reply-To: <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 30 Mar 2006 20:09:24 -0000 Hi Brian, --On March 30, 2006 11:33:08 AM -0800 Brian Moseley wrote: > 2) caldav doesn't allow non-calendar resources in calendar collections. Lets be clear about this: the main reason for this constraint is to allow support of legacy calendar systems with CalDAV. In order to promote adoption of CalDAV we want to see CalDAV 'adapters' for the existing large deployments of such calendaring systems, and crucially make it easy for CalDAV to sit on top of those. Often such systems ONLY allow calendar data to be stored, and there is no satisfactory way to store arbitrary data. So the bottom line is there will always be some CalDAV servers that cannot support non-calendar data in calendar collections. The question then becomes whether we mandate this behaviour or make it optional so that other less constrained servers can store arbitrary data. And there in lies the problem of making a potentially important feature a 'MAY' - it means that clients cannot rely on it to be present and so have to have two or more code paths to achieve the same goals. I think history has shown with IMAP that when that occurs, the client authors nearly always choose to implement a single code path - the one that will work with all servers irrespective of constraints (i.e. in our case be able to work with CalDAV constraints as they stand now). I think the examples you give are interesting cases, but they can be solved in a whole variety of different ways whilst still living with the current constraints on the data model. I think part of the problem here is trying to impose a user's 'visualization' of the data on the data store. Its my belief that there really ought to be a separate 'virtual visualization' layer between the end user and the data such that they can choose their own arbitrary groupings based on what makes sense for them. That way constraints on either side can be hidden. -- 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 1D2767F6FA for ; Thu, 30 Mar 2006 11:33:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E81C142290 for ; Thu, 30 Mar 2006 11:33:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08401-09 for ; Thu, 30 Mar 2006 11:33:10 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.201]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF24914228F for ; Thu, 30 Mar 2006 11:33:09 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so252392uge for ; Thu, 30 Mar 2006 11:33:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SwHVK/yneXyRA4aXpr5dMjEForiS9pDns3mPv/P2+Zgo+/mgcCRbTS3M3VgSmvJjAUHYT2Fv0787J//MWkuaxYapU9HYUi50klaUKWGZfocYTj/g3vmU0bcCSdshmzj02PEKMQVilViGFNovinfHHq2SvyT1GHTogYt7lysP2f0= Received: by 10.78.52.17 with SMTP id z17mr1324huz; Thu, 30 Mar 2006 11:33:08 -0800 (PST) Received: by 10.78.75.7 with HTTP; Thu, 30 Mar 2006 11:33:08 -0800 (PST) Message-ID: <29a761a00603301133s4b79e0dasb857392d6185e29a@mail.gmail.com> Date: Thu, 30 Mar 2006 11:33:08 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 19:33:13 -0000 On 3/30/06, Wilfredo S=E1nchez Vega wrote: > Right, but the downside here is that this seems like a funny > little dance. It's extra "magic" complexity that the server is > taking care of, and I don't like the idea of building that into a > spec. Where I'm going is that neither option for hiding data seems > palatable. and as julian pointed out, it's not the expected behavior of a generic webdav collection. yeah, none of the proposed solutions have been great, but i'm hoping they stimulate further ideas - or at least cause people to reconsider whether caldav clients should be expected to recognize and discard non-calendar resources returned from PROPFINDs. > My point is that if you want a spiffy collection with mixed > content, treat the calendar collection as one resource in that > collection, rather than trying to force the calendar collection to be > that collection itself. Or put the mixed data in a subcollection. > The "ew" objection is understandable, but not all that compelling. > > Put simply, I don't see why you can't accomplish what I understand > your goal to be without living in the bounds of the current spec. I > realize, though, that I probably don't understand what you are trying > to do well enough. let's imagine that my client can publish events, tasks, contacts, email messages, and photos to my server. my client also allows other people who are also using my client to subcribe to all of these things as one big mess. imagine further that my server allows people using any vanilla caldav client to subscribe directly to the calendar subcollection, and those using any vanilla carddav client to subscribe directly to the contact subcollection. my client could certainly make a parent collection containing a subcollection for each distinct content type. but then the user would have to remember to: 1) point my client at the parent collection to publish updates 2) tell his friends who use my client the url of the parent collection 3) tell his friends who use vanilla caldav clients the url of the calendar subcollection 4) tell his friends who use vanilla carddav clients the url of the contact subcollection that is not a very compelling interoperability story. the ideal scenario is that the user can tell all of his friends a single url without regard to what client they might be using. do you agree that is a worthy interop goal? i could theoretically put some magic into my server to examine requests for the parent collection and determine whether they come from 1) my client, 2) vanilla caldav client, or 3) vanilla carddav client. this would let me serve content from one of the subcollections in response to a request made for the parent collection and just might suffice (except the protocols don't give us any mechanism for these clients to distinguish what kind of content they want). but there's also the problem that in my client, a particular content item can be an event, a task, an email message, a content and a photo all at the same time. i'd rather not have to store a copy of the item in each of these four subcollections if i could store a single item in the parent collection. if i could do that, then my server could respond to a request with a view of that item appropriate to the protocol used to request it: 1) webdav - the "uber item' 2) caldav - an icalendar object containing a vevent and a vtodo 3) carddav - a vcard (i assume that's the correct resource type) the parent collection, then, would act as a caldav collection for caldav clients, a carddav collection (if such a thing exists) for carddav clients, and a regular webdav collection for webdav clilents. there are only two things holding us back from this ideal content negotiation situation in which users and clients only ever have to know about one url and the server can store one resource but serve multiple views of it. 1) clients don't have any way to ask for specific content types with PROPFIND or otherwise indicate that they are anything other than a generic webdav client interested in all resource types. 2) caldav doesn't allow non-calendar resources in calendar collections. does this make sense? does anybody else other than me see any value in shaping the webdav-based protocols so that they allow for (not assume, simply allow for) this negotiated-content world to exist? 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 EE66E7F728; Thu, 30 Mar 2006 10:58:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF26C14228F; Thu, 30 Mar 2006 10:58:44 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07590-05; Thu, 30 Mar 2006 10:58:43 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5456214228D; Thu, 30 Mar 2006 10:58:43 -0800 (PST) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k2UIwhWS025319; Thu, 30 Mar 2006 10:58:43 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 04488324002; Thu, 30 Mar 2006 10:58:43 -0800 (PST) In-Reply-To: <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E69B6C0-91B5-4076-9543-997D0BFF6EE7@wsanchez.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Thu, 30 Mar 2006 10:58:42 -0800 To: Brian Moseley X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 30 Mar 2006 18:58:45 -0000 On Mar 28, 2006, at 11:58 AM, Brian Moseley wrote: >> Having to add a custom header to not get unexpected data is >> undesirable. Not all clients will know of this custom header. >> Better to have a custom header to show you the data, and have the >> server default to hiding it. > > agree! that's what i proposed earlier in the thread. if a client used > MKCALENDAR to create the collection, then consider "calendar" the > primary resource type for that collection and return only resources of > that type for PROPFINDS, unless the client explicitly asks for > more/different types with the custom header. Right, but the downside here is that this seems like a funny little dance. It's extra "magic" complexity that the server is taking care of, and I don't like the idea of building that into a spec. Where I'm going is that neither option for hiding data seems palatable. >> I really don't see the practical problem that you face here. If >> you treat the calendar collection as a compound document, you can put >> that collection in your logic collection along with whatever other >> resources you like. > > not really getting your point here. My point is that if you want a spiffy collection with mixed content, treat the calendar collection as one resource in that collection, rather than trying to force the calendar collection to be that collection itself. Or put the mixed data in a subcollection. The "ew" objection is understandable, but not all that compelling. Put simply, I don't see why you can't accomplish what I understand your goal to be without living in the bounds of the current spec. I realize, though, that I probably don't understand what you are trying to do well enough. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A233E7F62F for ; Tue, 28 Mar 2006 14:14:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 933591422BE for ; Tue, 28 Mar 2006 14:14:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03106-06 for ; Tue, 28 Mar 2006 14:14:49 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF7CE1422B1 for ; Tue, 28 Mar 2006 14:14:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6FD933D9EE7 for ; Wed, 29 Mar 2006 00:12:55 +0200 (CEST) Received: from [192.168.1.233] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id 0BCFD3D81AC for ; Wed, 29 Mar 2006 00:12:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <44299BFC.2060104@gmx.de> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <44299752.3080703@gmx.de> <29a761a00603281223v77e3c7b0med358a30d14dd7f8@mail.gmail.com> <44299BFC.2060104@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DEB3F95-8458-4DC2-8713-9FAA14C42A5E@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Wed, 29 Mar 2006 00:14:33 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 22:14:52 -0000 On 28. Mrz 2006, at 22:26 Uhr, Julian Reschke wrote: > Just for the record: methinks that mixed content should be fine; so > CalDAV should allow that, and clients would need to deal with it > upon PROPFIND. I tend to agree. CalDAV is so complicated that it won't be fully supported by legacy servers which can't deal with the mixed content requirement anyway. In fact I think the far majority of fully compliant CalDAV servers will be done from scratch and most existing servers will just support a subset which is enough to connect the important clients. Personally I do not see a major difference between supporting subcollections and supporting mixed content. The level of difficulty for legacy RDBMS servers should be roughly the same. So I suggest that a statement is added that clients MUST be prepared to receive content which is not iCalendar. They can filter that using the content-type or just use REPORTs if they don't want to be bothered. I think there is no explicit need for a MAY on the server side, just keep the WebDAV semantics (which allows the server to reject content if it doesn't want it / can't store it ...). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5D4617F6A1 for ; Tue, 28 Mar 2006 12:33:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4DF2D1422C2 for ; Tue, 28 Mar 2006 12:33:59 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06378-06 for ; Tue, 28 Mar 2006 12:33:58 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.206]) by laweleka.osafoundation.org (Postfix) with ESMTP id 964F31422BE for ; Tue, 28 Mar 2006 12:33:58 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so10791uge for ; Tue, 28 Mar 2006 12:33:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IrHw48QVaUoqISiM6u+t8d9l5Wu7tDmFNU+aIW2kPp1I2kgQO/sLAJ47/eYwGt60RXvK0/KWPYR+c4/Gk5D9vTABtj9n0uY8/KfpbD7o1Tzc0RaSuHzmxF7ilAT65o3R2tK2yhb/DCbdzXDmplRTfatV3jCdlPRVw/JfBxQCn64= Received: by 10.78.40.10 with SMTP id n10mr89078hun; Tue, 28 Mar 2006 12:33:57 -0800 (PST) Received: by 10.78.75.7 with HTTP; Tue, 28 Mar 2006 12:33:57 -0800 (PST) Message-ID: <29a761a00603281233l2ffcd400o9a897c353e76c28e@mail.gmail.com> Date: Tue, 28 Mar 2006 12:33:57 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <44299BFC.2060104@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <44299752.3080703@gmx.de> <29a761a00603281223v77e3c7b0med358a30d14dd7f8@mail.gmail.com> <44299BFC.2060104@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:33:59 -0000 On 3/28/06, Julian Reschke wrote: > Just for the record: methinks that mixed content should be fine; so > CalDAV should allow that, and clients would need to deal with it upon > PROPFIND. i am sympathetic to those who argue that a simple calendar client should not have to download and discard non-calendar resources. i would just like to find a way for those "basic" caldav cilents to distinguish themselves from "even more basic" webdav clients (which do want all member resources) and "mixed content aware" clients that should be able to ask for specifically what they want. 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 5D6687F64C for ; Tue, 28 Mar 2006 12:28:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E9001422C2 for ; Tue, 28 Mar 2006 12:28:27 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06378-05 for ; Tue, 28 Mar 2006 12:28:26 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 639F01422BA for ; Tue, 28 Mar 2006 12:28:26 -0800 (PST) Received: (qmail invoked by alias); 28 Mar 2006 20:28:24 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 28 Mar 2006 22:28:24 +0200 X-Authenticated: #1915285 Message-ID: <44299BFC.2060104@gmx.de> Date: Tue, 28 Mar 2006 22:26:36 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <44299752.3080703@gmx.de> <29a761a00603281223v77e3c7b0med358a30d14dd7f8@mail.gmail.com> In-Reply-To: <29a761a00603281223v77e3c7b0med358a30d14dd7f8@mail.gmail.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=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Tue, 28 Mar 2006 20:28:27 -0000 Brian Moseley wrote: > On 3/28/06, Julian Reschke wrote: > >> That would break the PROPFIND semantics defined by RFC2518. If a >> calendar collection is a WebDAV collection, it has to follow the >> semantics defined by RFC2518. > > logjam! > > ok, well, i give up. if nobody has a better suggestion, then we will > have to find a way to be as non-uncompliant as possible if we do > decide to support mixed content. it certainly doesn't seem like we can > be all things to all people. Just for the record: methinks that mixed content should be fine; so CalDAV should allow that, and clients would need to deal with it upon PROPFIND. Just my 2 cents, 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 7AE4B7F6BF for ; Tue, 28 Mar 2006 12:23:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6CD851422B8 for ; Tue, 28 Mar 2006 12:23:17 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11533-10 for ; Tue, 28 Mar 2006 12:23:15 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.207]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6A951422B2 for ; Tue, 28 Mar 2006 12:23:14 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so9664uge for ; Tue, 28 Mar 2006 12:23:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gUXlIKROe1prOJR6pFuAu7S8EL68bSe2t/H0thBQJb7m2nEQiXrsL7VlsdANBV6yWX7/ywkqnDp/AowVDnVGLIfuSBK5qVWpWIU+PoiwO3pahPYjXwjc9fiBJi+rOZBbOIEsbHJjqhxXDipmClvWONjyHsGda8jSJ3pBPVlQaJQ= Received: by 10.78.18.1 with SMTP id 1mr88342hur; Tue, 28 Mar 2006 12:23:13 -0800 (PST) Received: by 10.78.75.7 with HTTP; Tue, 28 Mar 2006 12:23:13 -0800 (PST) Message-ID: <29a761a00603281223v77e3c7b0med358a30d14dd7f8@mail.gmail.com> Date: Tue, 28 Mar 2006 12:23:13 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <44299752.3080703@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> <44299752.3080703@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:23:17 -0000 On 3/28/06, Julian Reschke wrote: > That would break the PROPFIND semantics defined by RFC2518. If a > calendar collection is a WebDAV collection, it has to follow the > semantics defined by RFC2518. logjam! ok, well, i give up. if nobody has a better suggestion, then we will have to find a way to be as non-uncompliant as possible if we do decide to support mixed content. it certainly doesn't seem like we can be all things to all people. 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 D95BD7F6AE for ; Tue, 28 Mar 2006 12:08:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CB4081422B8 for ; Tue, 28 Mar 2006 12:08:34 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09918-08 for ; Tue, 28 Mar 2006 12:08:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id F0C0A1422B2 for ; Tue, 28 Mar 2006 12:08:32 -0800 (PST) Received: (qmail invoked by alias); 28 Mar 2006 20:08:30 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 28 Mar 2006 22:08:30 +0200 X-Authenticated: #1915285 Message-ID: <44299752.3080703@gmx.de> Date: Tue, 28 Mar 2006 22:06:42 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> In-Reply-To: <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> 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=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Tue, 28 Mar 2006 20:08:35 -0000 Brian Moseley wrote: > On 3/28/06, Wilfredo Sánchez Vega wrote: > >> Since when do users universally avoid doing silly things? > > yea but we are talking more about clients here. i can't imagine users > will be getting into the gritty details of telling their clients to > put event attachments into subcollections and so forth. i expect > clients will hide all this behind "publish your calendar to location > xyz". > >> Having to add a custom header to not get unexpected data is >> undesirable. Not all clients will know of this custom header. >> Better to have a custom header to show you the data, and have the >> server default to hiding it. > > agree! that's what i proposed earlier in the thread. if a client used > MKCALENDAR to create the collection, then consider "calendar" the > primary resource type for that collection and return only resources of > that type for PROPFINDS, unless the client explicitly asks for > more/different types with the custom header. That would break the PROPFIND semantics defined by RFC2518. If a calendar collection is a WebDAV collection, it has to follow the semantics defined by RFC2518. > ... 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 1630F7F624 for ; Tue, 28 Mar 2006 11:58:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0308D1422BE for ; Tue, 28 Mar 2006 11:58:31 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09093-08 for ; Tue, 28 Mar 2006 11:58:28 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.203]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30A3A1422B8 for ; Tue, 28 Mar 2006 11:58:28 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so7013uge for ; Tue, 28 Mar 2006 11:58:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aOh9FQxLieJnoPRTPvOe2CCqRGNMEYjh4mPtRBCmJIL1l/97sOH6USLoeydOJoHal6bm/Hk92aOWi2JrvMFBytYY8jm/HENVDJDr9tzQKU40Ri8YUeupCMSe6mARAiNrBm+4kTgbgMtMVBjLeMW0xAo3tn5kiJGZ2zZUmSPN7Y8= Received: by 10.78.17.4 with SMTP id 4mr87621huq; Tue, 28 Mar 2006 11:58:26 -0800 (PST) Received: by 10.78.75.7 with HTTP; Tue, 28 Mar 2006 11:58:26 -0800 (PST) Message-ID: <29a761a00603281158u59d58dc5i34b9bc724333ed@mail.gmail.com> Date: Tue, 28 Mar 2006 11:58:26 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 19:58:31 -0000 On 3/28/06, Wilfredo S=E1nchez Vega wrote: > Since when do users universally avoid doing silly things? yea but we are talking more about clients here. i can't imagine users will be getting into the gritty details of telling their clients to put event attachments into subcollections and so forth. i expect clients will hide all this behind "publish your calendar to location xyz". > Having to add a custom header to not get unexpected data is > undesirable. Not all clients will know of this custom header. > Better to have a custom header to show you the data, and have the > server default to hiding it. agree! that's what i proposed earlier in the thread. if a client used MKCALENDAR to create the collection, then consider "calendar" the primary resource type for that collection and return only resources of that type for PROPFINDS, unless the client explicitly asks for more/different types with the custom header. > I really don't see the practical problem that you face here. If > you treat the calendar collection as a compound document, you can put > that collection in your logic collection along with whatever other > resources you like. not really getting your point here. this 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 99B9C7F6A2; Tue, 28 Mar 2006 11:45:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8AB4B1422B8; Tue, 28 Mar 2006 11:45:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13189-01; Tue, 28 Mar 2006 11:45:13 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C7BDE1422B2; Tue, 28 Mar 2006 11:45:13 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k2SJjDfT013666; Tue, 28 Mar 2006 11:45:13 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 654B5324002; Tue, 28 Mar 2006 11:45:13 -0800 (PST) In-Reply-To: <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) 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] non-calendar resources in calendar collections Date: Tue, 28 Mar 2006 11:45:12 -0800 To: Brian Moseley X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Tue, 28 Mar 2006 19:45:16 -0000 On Mar 28, 2006, at 10:17 AM, Brian Moseley wrote: > On 3/27/06, Lisa Dusseault wrote: > >> - If an external attachment to a calendar item is itself a >> calendar >> item, where does it get stored? If in the calendar collection, how >> would we disable the REPORT acting on that and deal with the possible >> duplication of IDs? > > isn't this a case of "don't do the obviously silly thing"? if you > don't want a calendar item to actually show up on your calendar, don't > put it in your calendar collection. Since when do users universally avoid doing silly things? >> - Even clients that don't want to make use of the feature, would >> have to be able to deal with extra resources appearing in a calendar >> collection, and how to interpret or display or ignore > > this, i think, is the main problem with my request, but it can't be an > unsolvable problem. a custom request header would do the trick - > "X-CALENDAR-ACCEPT: text/calendar" or some such. Having to add a custom header to not get unexpected data is undesirable. Not all clients will know of this custom header. Better to have a custom header to show you the data, and have the server default to hiding it. >> If we take as given that not all servers are going to support storing >> resources of arbitrary types, then I for one am in favour of limiting >> what clients have to deal with, and keeping the spec simpler, by >> isolating these various resources in a sub-collection. I don't see >> sufficient benefit in the more flexible but more complicated >> approach, in fact I'm unaware of any use cases that can't equally be >> satisfied with a sub-collection, and I can see some use cases that >> are better served with a sub-collection (e.g. synchronizing >> attachments in off-cycles). > > just as some servers "don't wanna" support arbitrary resource types, > some clients "don't wanna" have to deal with subcollections. choosing > whether or not to put a particular resource in the main collection > rather than a subcollection might be simple now, but what happens when > additional sharing protocols come out that each expect their single > resource type to be the one true resource type in a collection? > suddenly you force clients to create a bunch of peer collections, each > for a different resource type, to represent a single "logical" > collection. bleh. Not supporting arbitrary resource types is a matter of necessity for some servers, and a matter of simplicity for others. Dealing with subcollections, on the other hand, is something a client has to know how to do anyway, and is hardly a significant complication. You seem to be putting a cosmetic priority above practical ones. I really don't see the practical problem that you face here. If you treat the calendar collection as a compound document, you can put that collection in your logic collection along with whatever other resources you like. Complaining that you can't store arbitrary content in a server-managed collection feels like complaining that you can't store random data in whatever file format you encounter for a resource. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1BA3B7F6A5 for ; Tue, 28 Mar 2006 10:17:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0CDF11422B9 for ; Tue, 28 Mar 2006 10:17:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00871-08 for ; Tue, 28 Mar 2006 10:17:50 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.204]) by laweleka.osafoundation.org (Postfix) with ESMTP id 189C01422B8 for ; Tue, 28 Mar 2006 10:17:49 -0800 (PST) Received: by uproxy.gmail.com with SMTP id y2so599690uge for ; Tue, 28 Mar 2006 10:17:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ea6yiY3B/sgsdo4MkGtTiTiEUTe3qQDY2uJiTsJNtjKii7tURnadEdYaWSHCX8vbXSzXhmyMo+bIWq1rrW6U3sxc6uDSlo1DbisNizVgQsuMc529YR/SxTe+xihugvBg7Ue118qFZ/bV/y/9tJe9t9gtwOVYlkxNwzqtm8kpieM= Received: by 10.78.18.1 with SMTP id 1mr84718hur; Tue, 28 Mar 2006 10:17:48 -0800 (PST) Received: by 10.78.75.7 with HTTP; Tue, 28 Mar 2006 10:17:48 -0800 (PST) Message-ID: <29a761a00603281017g73d390c9w3bca43a645c81001@mail.gmail.com> Date: Tue, 28 Mar 2006 10:17:48 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 18:17:51 -0000 On 3/27/06, Lisa Dusseault wrote: > At any rate, I don't see a clear consensus on this list to REQUIRE > all servers to support arbitrary types in calendar collections. If > people think I'm wrong about the consensus they should voice their > opinions here unless they've already voiced it here. just to be clear, i would have never suggested this as a requirement. > - The spec would probably have to consider the following: > - are these objects attachments, or can be anything at all? > - If an external attachment to a calendar item is itself a calend= ar > item, where does it get stored? If in the calendar collection, how > would we disable the REPORT acting on that and deal with the possible > duplication of IDs? isn't this a case of "don't do the obviously silly thing"? if you don't want a calendar item to actually show up on your calendar, don't put it in your calendar collection. attachments are a case where using a different collection actually makes sense. i'm okay with that, since it's not the use case i'm addressing. > - Clients that might want to make use of the feature have to see if > the server supports it, or not, and have conditional actions for both > cases. well, sure. isn't that always the case when choosing to implement an optional feature? if a client wants to have extended functionality and still be useful with servers that don't provide the option, the client is going to be more complicated, by definition. i don't see why anybody would be afraid of that. > - Even clients that don't want to make use of the feature, would > have to be able to deal with extra resources appearing in a calendar > collection, and how to interpret or display or ignore this, i think, is the main problem with my request, but it can't be an unsolvable problem. a custom request header would do the trick - "X-CALENDAR-ACCEPT: text/calendar" or some such. > If we take as given that not all servers are going to support storing > resources of arbitrary types, then I for one am in favour of limiting > what clients have to deal with, and keeping the spec simpler, by > isolating these various resources in a sub-collection. I don't see > sufficient benefit in the more flexible but more complicated > approach, in fact I'm unaware of any use cases that can't equally be > satisfied with a sub-collection, and I can see some use cases that > are better served with a sub-collection (e.g. synchronizing > attachments in off-cycles). just as some servers "don't wanna" support arbitrary resource types, some clients "don't wanna" have to deal with subcollections. choosing whether or not to put a particular resource in the main collection rather than a subcollection might be simple now, but what happens when additional sharing protocols come out that each expect their single resource type to be the one true resource type in a collection? suddenly you force clients to create a bunch of peer collections, each for a different resource type, to represent a single "logical" collection. bleh. 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 3447E7F5F1; Mon, 27 Mar 2006 18:23:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25933142271; Mon, 27 Mar 2006 18:23:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21447-09; Mon, 27 Mar 2006 18:23:22 -0800 (PST) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A6B114225C; Mon, 27 Mar 2006 18:23:22 -0800 (PST) In-Reply-To: <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Mon, 27 Mar 2006 18:23:18 -0800 To: Brian Moseley X-Mailer: Apple Mail (2.746.2) 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, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL 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: Tue, 28 Mar 2006 02:23:23 -0000 On Mar 16, 2006, at 4:24 PM, Brian Moseley wrote: > On 3/16/06, Bernard Desruisseaux > wrote: > >> If you insist to have your collection accessible by a single URL >> you could request the Cosmo-aware clients to specify a proprietary >> request-header (e.g., X-OSAF-Something) in each of their requests. >> Cosmo would enable its CalDAV proprietary extension that allows >> resources of arbitrary media type in calendar collections only when >> this proprietary request-header is specified in a request. > I get the impression that you are > blowing off what i and at least a couple of others seem to think is a > valid use case. there has been no comment on my assertion that caldav > is written from a perspective that assumes calendar data is of primary > importance to a server, giving short shrift to servers where calendar > is just one of many data types that can be freely interspersed. can > you and/or lisa and/or cyrus address this? thanks. In my extended personal experience, Bernard doesn't blow these kinds of things off :) In fact he brought this up tonight in our phone call asking if we could resolve the issue. We discussed this at length perhaps as long as a year ago, and have revisited it now, but he simply remains of the strong opinion that we can't require servers to store arbitrary types. He's got a perspective which is different from yours and mine, on how an existing calendar repository is likely to be implemented, what restrictions it has and what kind of features it can implement easily or with difficulty. We actually tried hard to balance concerns of calendar-only servers, with those of a sharing server with more freely-interspersed data. We believe the use case is handled with a different mechanism -- that of sub-collections, primarily. Alternatively, calendar and non- calendar items can be mixed in any collection that doesn't advertise that it is a CalDAV calendar collection (and it can still even support calendar REPORTs) At any rate, I don't see a clear consensus on this list to REQUIRE all servers to support arbitrary types in calendar collections. If people think I'm wrong about the consensus they should voice their opinions here unless they've already voiced it here. Let's suppose that's a given. If servers aren't required to allow this, then MAY they? If some servers can, but other servers don't, then this makes the spec and client implementations both more complicated - The spec would probably have to consider the following: - are these objects attachments, or can be anything at all? - If an external attachment to a calendar item is itself a calendar item, where does it get stored? If in the calendar collection, how would we disable the REPORT acting on that and deal with the possible duplication of IDs? - Clients that might want to make use of the feature have to see if the server supports it, or not, and have conditional actions for both cases. - Even clients that don't want to make use of the feature, would have to be able to deal with extra resources appearing in a calendar collection, and how to interpret or display or ignore If we take as given that not all servers are going to support storing resources of arbitrary types, then I for one am in favour of limiting what clients have to deal with, and keeping the spec simpler, by isolating these various resources in a sub-collection. I don't see sufficient benefit in the more flexible but more complicated approach, in fact I'm unaware of any use cases that can't equally be satisfied with a sub-collection, and I can see some use cases that are better served with a sub-collection (e.g. synchronizing attachments in off-cycles). 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 C3F797F688 for ; Mon, 27 Mar 2006 13:35:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3E4F1422C1 for ; Mon, 27 Mar 2006 13:35:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19721-10 for ; Mon, 27 Mar 2006 13:35:02 -0800 (PST) Received: from fed1rmmtao05.cox.net (fed1rmmtao05.cox.net [68.230.241.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 273BE14227E for ; Mon, 27 Mar 2006 13:35:02 -0800 (PST) Received: from [192.168.0.102] (really [70.191.49.25]) by fed1rmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060327213501.XQUD17838.fed1rmmtao05.cox.net@[192.168.0.102]>; Mon, 27 Mar 2006 16:35:01 -0500 Message-ID: <44285A80.2090803@calconnect.org> Date: Mon, 27 Mar 2006 13:34:56 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------000406090204090900070906" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_20_30, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-caldav] Registration is now open for May 2005 CalConnect Roundtable and IOP Testing X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.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, 27 Mar 2006 21:35:04 -0000 This is a multi-part message in MIME format. --------------000406090204090900070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Registration is now open for the May 22-25 CalConnect Roundtable VI and Interoperability Testing events. These events will be hosted by IBM in Cambridge, Massachusetts. The IOP testing will occur on May 22nd and the morning of May 23rd. The Roundtable will take place on the afternoon of the 23rd, all day on the 24th and the morning of the 25th. Information on Roundtable VI and on the IOP testing event can be found at http://www.calconnect.org/roundtable6.html and http://www.calconnect.org/iopmay2006.html respectively, including travel and logistics information. A general schedule for the Roundtable is posted on the Roundtable VI page mentioned agove; more detailed information will be posted to that page as it becomes available. The Consortium is planning to offer an introductory Practicum on iCalendar (RFC 2445) and on CalDAV, the new Calendar Access protocol, on Tuesday morning the 23rd for anyone who is not involved in the IOP testing and wishes to come early. The Practicum is available without to anyone registered for Roundtable VI as an member representative or as an observer. Due to the hotel pressures in the Boston area in May, I encourage everyone to make their travel and hotel arrangements as soon as possible. Best Regards, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------000406090204090900070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Registration is now open for the May 22-25 CalConnect Roundtable VI and Interoperability Testing events.  These events will be hosted by IBM in Cambridge, Massachusetts.  The IOP testing will occur on May 22nd and the morning of May 23rd.  The Roundtable will take place on the afternoon of the 23rd, all day on the 24th and the morning of the 25th.

Information on Roundtable VI and on the IOP testing event can be found at http://www.calconnect.org/roundtable6.html and http://www.calconnect.org/iopmay2006.html respectively, including travel and logistics information.

A general schedule for the Roundtable is posted on the Roundtable VI page mentioned agove; more detailed information will be posted to that page as it becomes available.

The Consortium is planning to offer an introductory Practicum on iCalendar (RFC 2445) and on CalDAV, the new Calendar Access protocol, on Tuesday morning the 23rd for anyone who is not involved in the IOP testing and wishes to come early.  The Practicum is available without to anyone registered for Roundtable VI as an member representative or as an observer.

Due to the hotel pressures in the Boston area in May, I encourage everyone to make their travel and hotel arrangements as soon as possible.

Best Regards,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------000406090204090900070906-- 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 CD3487F677 for ; Fri, 24 Mar 2006 05:55:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE622142289 for ; Fri, 24 Mar 2006 05:55:21 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10423-03 for ; Fri, 24 Mar 2006 05:55:21 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C7F214227F for ; Fri, 24 Mar 2006 05:55:21 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ODtHxJ000858; Fri, 24 Mar 2006 07:55:17 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2ODtG05029657; Fri, 24 Mar 2006 06:55:17 -0700 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2ODtEdS029606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 24 Mar 2006 06:55:15 -0700 Message-ID: <4423F9E0.2080205@oracle.com> Date: Fri, 24 Mar 2006 08:53:36 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Ietf-caldav] ical within xml text nodes References: <442355F8.9010604@nokia.com> In-Reply-To: <442355F8.9010604@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 24 Mar 2006 13:55:21 -0000 Hi Jari, - I guess it wouldn't hurt to add a comment about XML escaping (i.e., the use of character and entity references as well as CDATA sections) in section 9.5 CALDAV:calendar-data XML Element. - We'll change all the examples with trailing whitespaces. That is, END:VCALENDAR should be changed to: END:VCALENDAR - We'll fix the typo in section 7.7.1. Thanks for the feedback! Cheers, Bernard Jari Urpalainen wrote: > Hi all! > > This is just a ping of discussion with Lisa. While XML is not that good > at embedding other markup it should imo expressed clearly that > applications must either encode at least & and < characters or embed > ical within CDATA sections. With CDATA it is worth mentioning that that > ]]> (or new start of CDATA) string may not appear within ical strings > (although very rare situation i agree/assume). CRLF mangling seems to be > taken care of. What I don't know at all, does ical allow appended > whitespaces at the end of document as many examples have it ? In Section > 7.7.1 there's a typo . I'm still a newbie regarding > caldav, so I don't have real comments on the content of this i-d, sorry. > br, > Jari > _______________________________________________ > 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 4D5C67F7A6 for ; Fri, 24 Mar 2006 01:22:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F19F142280 for ; Fri, 24 Mar 2006 01:22:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32593-06 for ; Fri, 24 Mar 2006 01:22:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 6D23A14227F for ; Fri, 24 Mar 2006 01:22:12 -0800 (PST) Received: (qmail invoked by alias); 24 Mar 2006 09:22:08 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 24 Mar 2006 10:22:08 +0100 X-Authenticated: #1915285 Message-ID: <4423B9F2.8020604@gmx.de> Date: Fri, 24 Mar 2006 10:20:50 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Ietf-caldav] ical within xml text nodes References: <442355F8.9010604@nokia.com> In-Reply-To: <442355F8.9010604@nokia.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.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2006 09:22:13 -0000 Jari Urpalainen wrote: > Hi all! > > This is just a ping of discussion with Lisa. While XML is not that good > at embedding other markup it should imo expressed clearly that > applications must either encode at least & and < characters or embed > ical within CDATA sections. With CDATA it is worth mentioning that that > ... Well, if somebody gets this wrong, no recipient using a regular XML parser would be able to interoperate. So I guess that kind of bug would get noticed very soon :-) 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 94B077F7B7 for ; Thu, 23 Mar 2006 21:02:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85088142279 for ; Thu, 23 Mar 2006 21:02:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02919-07 for ; Thu, 23 Mar 2006 21:02:10 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by laweleka.osafoundation.org (Postfix) with ESMTP id 12E06142278 for ; Thu, 23 Mar 2006 21:02:10 -0800 (PST) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc13) with SMTP id <2006032405020801300eb6l5e>; Fri, 24 Mar 2006 05:02:09 +0000 From: "Tim Hare" To: Subject: RE: [Ietf-caldav] ical within xml text nodes Date: Fri, 24 Mar 2006 00:02:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZO6OZPHbLzktCrQt6YTejhtUm6HwAFep3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <442355F8.9010604@nokia.com> Message-Id: <20060324050210.12E06142278@laweleka.osafoundation.org> 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, BAYES_00, MSGID_FROM_MTA_ID 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, 24 Mar 2006 05:02:10 -0000 I don't think there's any express document regarding embedding iCalendar (RCF2445) in XML as a piece of text. iCalendar is not markup-like, or at least not well-formed markup, having for most components only a beginning "tag" (for example DTSTART:) with no end tag. There are IETF individual draft documents on "xcal" which try to describe an XML representation of iCalendar data As far as appended whitespace goes, if have been reading the RFC correctly, trailing whitespace MAY be ignored in the value of a component or property; however a blank immediately following x'0D0A' is part of line wrapping of a component value larger than 75 characters and cannot be ignored. Remember that iCalendar files don't have the same properties as XML documents. Also, since you are at Nokia, unless things have changed one of the original iCalendar authors worked there (F. Dawson) and could be a source of information if he's not busy on other things. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Jari Urpalainen Sent: Thursday, March 23, 2006 9:14 PM To: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] ical within xml text nodes Hi all! This is just a ping of discussion with Lisa. While XML is not that good at embedding other markup it should imo expressed clearly that applications must either encode at least & and < characters or embed ical within CDATA sections. With CDATA it is worth mentioning that that ]]> (or new start of CDATA) string may not appear within ical strings (although very rare situation i agree/assume). CRLF mangling seems to be taken care of. What I don't know at all, does ical allow appended whitespaces at the end of document as many examples have it ? In Section 7.7.1 there's a typo . I'm still a newbie regarding caldav, so I don't have real comments on the content of this i-d, sorry. br, Jari _______________________________________________ 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 B51597F7A7 for ; Thu, 23 Mar 2006 18:16:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A060C142273 for ; Thu, 23 Mar 2006 18:16:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17505-04 for ; Thu, 23 Mar 2006 18:16:01 -0800 (PST) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E63DE14225B for ; Thu, 23 Mar 2006 18:16:00 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k2O2Ftom007881 for ; Fri, 24 Mar 2006 04:15:58 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 04:15:50 +0200 Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Mar 2006 04:15:51 +0200 Received: from [10.241.58.141] (daec-linuxvpn058141.americas.nokia.com [10.241.58.141]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k2O2FEQ23049 for ; Fri, 24 Mar 2006 04:15:14 +0200 (EET) Message-ID: <442355F8.9010604@nokia.com> Date: Fri, 24 Mar 2006 04:14:16 +0200 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2006 02:15:51.0404 (UTC) FILETIME=[DF664AC0:01C64EE8] 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, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] ical within xml text nodes 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, 24 Mar 2006 02:16:01 -0000 Hi all! This is just a ping of discussion with Lisa. While XML is not that good at embedding other markup it should imo expressed clearly that applications must either encode at least & and < characters or embed ical within CDATA sections. With CDATA it is worth mentioning that that ]]> (or new start of CDATA) string may not appear within ical strings (although very rare situation i agree/assume). CRLF mangling seems to be taken care of. What I don't know at all, does ical allow appended whitespaces at the end of document as many examples have it ? In Section 7.7.1 there's a typo . I'm still a newbie regarding caldav, so I don't have real comments on the content of this i-d, sorry. br, Jari 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 90EE27F7F9; Sat, 18 Mar 2006 11:49:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 80D83142299; Sat, 18 Mar 2006 11:49:11 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07190-02; Sat, 18 Mar 2006 11:49:11 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F63E14228A; Sat, 18 Mar 2006 11:49:11 -0800 (PST) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc13) with SMTP id <20060318194906m13005ktgqe>; Sat, 18 Mar 2006 19:49:10 +0000 From: "Tim Hare" To: "'Calsify WG'" , "'CalDAV DevList'" , "'WebDAV WG'" Subject: RE: [Ietf-calsify] Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Sat, 18 Mar 2006 14:49:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 thread-index: AcZKs38u3+lLj57DRQC1s4+bQ7s7FgAD/0NA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <441C4676.2080507@gmx.de> Message-Id: <20060318194911.2F63E14228A@laweleka.osafoundation.org> 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, BAYES_00, MSGID_FROM_MTA_ID X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 19:49:11 -0000 Cross-posted to Calsify, CalDAV, and WebDAV because that's how it came in, which is relevant to this post. Would it be possible to not cross-post CalDAV/WebDAV discussion to the Calsify list, please? The two are different efforts, albeit related, and receiving CalDAV postings twice only serves to make it harder to follow Calsify discussions. Thanks, Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Julian Reschke Sent: Saturday, March 18, 2006 12:42 PM To: Bernard Desruisseaux Cc: Calsify WG; CalDAV DevList; WebDAV WG Subject: [Ietf-calsify] Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Bernard Desruisseaux wrote: > > I thought it would be worthwhile to update everybody on the > changes we are planning to make in draft -11 based on the > issues that have been brought up so far: > > - Added new preconditions: > * CALDAV:number-of-recurrences-within-limits for PUT; > * CALDAV:calendar-collection-location-ok for MOVE and COPY. > - Redefined the CALDAV:no-uid-conflict precondition. > - Minor editorial changes. > - Update to references. > - Added element CALDAV:is-not-defined. > - Added new attribute "negate-condition" to the > CALDAV:text-match element. > > The last two changes were required to be able to query the to-dos > that are *not* completed and *not* cancelled. The issue is that > the CALDAV:calendar-query REPORT does not provide support for a > "not" operator. To be able to address the above use case without > increasing the complexity of the CALDAV:calendar-query REPORT > significantly we have decided to add a new condition "is-not-defined" > and to add a "negate-condition" attribute to be able to negate the > "text-match" condition. > ... Bernard, so did you consider whether CalDAV is going to be based on RFC2518 or on RFC2518bis? That is, would a CalDAV client be able to rely on RFC2518bis, or would they need to interact with both kinds of servers? Are CalDAV server implementors implementing RFC2518bis (or are they planning to)? Best regards, Julian _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify 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 975817FA4C for ; Sat, 18 Mar 2006 09:56:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 884D814228A for ; Sat, 18 Mar 2006 09:56:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24397-02 for ; Sat, 18 Mar 2006 09:56:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id B675214226D for ; Sat, 18 Mar 2006 09:56:45 -0800 (PST) Received: (qmail invoked by alias); 18 Mar 2006 17:56:44 -0000 Received: from p508F85E1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.133.225] by mail.gmx.net (mp028) with SMTP; 18 Mar 2006 18:56:44 +0100 X-Authenticated: #1915285 Message-ID: <441C498B.50505@gmx.de> Date: Sat, 18 Mar 2006 18:55:23 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> <4418CF08.7090300@oracle.com> <441C4676.2080507@gmx.de> <29a761a00603180946v6d17439doe0bc718363925b12@mail.gmail.com> In-Reply-To: <29a761a00603180946v6d17439doe0bc718363925b12@mail.gmail.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=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 17:56:47 -0000 Brian Moseley wrote: > On 3/18/06, Julian Reschke wrote: > >> Are CalDAV server implementors implementing RFC2518bis (or are they >> planning to)? > > i haven't looked at it in detail, so i don't have an adquate > understanding of how much effort it would take to implement, but i'm > unlikely to do it soon unless caldav requires it. Well. RFC2518bis introduces some incompatible changes compared to RFC2518. Some are easy to handle, but at least one is not. Should CalDAV avoid to build on top of RFC2518bis, both CalDAV clients and servers will have to deal with that interoperability issue. On the other hand, it's not too late to throw that change out, see WebDAV mailing list at and . 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 98D417FA47 for ; Sat, 18 Mar 2006 09:46:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 89764142287 for ; Sat, 18 Mar 2006 09:46:29 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22056-09 for ; Sat, 18 Mar 2006 09:46:29 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by laweleka.osafoundation.org (Postfix) with ESMTP id 148CE14227E for ; Sat, 18 Mar 2006 09:46:29 -0800 (PST) Received: by wproxy.gmail.com with SMTP id 70so723996wra for ; Sat, 18 Mar 2006 09:46:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BltiLqwcBf3Flg1dnSm4VQQeqHK69edpozzCSz2S/R+moWQOXZZ6TADX8pI/qwkf/S8dlQ/TRY6HivNkdX3lYL+LvGvz6qUpDZ2VxtGqT0YFt1YRQlmX1hi+C6Ib/Ia6tXG3Fvp5+23wizBWL/yp3jvl7WUqjESCJK4gA0aSCtw= Received: by 10.54.69.16 with SMTP id r16mr2334926wra; Sat, 18 Mar 2006 09:46:28 -0800 (PST) Received: by 10.54.98.20 with HTTP; Sat, 18 Mar 2006 09:46:28 -0800 (PST) Message-ID: <29a761a00603180946v6d17439doe0bc718363925b12@mail.gmail.com> Date: Sat, 18 Mar 2006 09:46:28 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call In-Reply-To: <441C4676.2080507@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> <4418CF08.7090300@oracle.com> <441C4676.2080507@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2006 17:46:29 -0000 On 3/18/06, Julian Reschke wrote: > Are CalDAV server implementors implementing RFC2518bis (or are they > planning to)? i haven't looked at it in detail, so i don't have an adquate understanding of how much effort it would take to implement, but i'm unlikely to do it soon unless caldav requires it. 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 2EC647FA47 for ; Sat, 18 Mar 2006 09:43:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2062E142286 for ; Sat, 18 Mar 2006 09:43:38 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16451-10 for ; Sat, 18 Mar 2006 09:43:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 32FB914227E for ; Sat, 18 Mar 2006 09:43:37 -0800 (PST) Received: (qmail invoked by alias); 18 Mar 2006 17:43:35 -0000 Received: from p508F85E1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.133.225] by mail.gmx.net (mp020) with SMTP; 18 Mar 2006 18:43:35 +0100 X-Authenticated: #1915285 Message-ID: <441C4676.2080507@gmx.de> Date: Sat, 18 Mar 2006 18:42:14 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> <4418CF08.7090300@oracle.com> In-Reply-To: <4418CF08.7090300@oracle.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=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Ted Hardie , Calsify WG , CalDAV DevList , WebDAV WG 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, 18 Mar 2006 17:43:38 -0000 Bernard Desruisseaux wrote: > > I thought it would be worthwhile to update everybody on the > changes we are planning to make in draft -11 based on the > issues that have been brought up so far: > > - Added new preconditions: > * CALDAV:number-of-recurrences-within-limits for PUT; > * CALDAV:calendar-collection-location-ok for MOVE and COPY. > - Redefined the CALDAV:no-uid-conflict precondition. > - Minor editorial changes. > - Update to references. > - Added element CALDAV:is-not-defined. > - Added new attribute "negate-condition" to the > CALDAV:text-match element. > > The last two changes were required to be able to query the to-dos > that are *not* completed and *not* cancelled. The issue is that > the CALDAV:calendar-query REPORT does not provide support for a > "not" operator. To be able to address the above use case without > increasing the complexity of the CALDAV:calendar-query REPORT > significantly we have decided to add a new condition "is-not-defined" > and to add a "negate-condition" attribute to be able to negate the > "text-match" condition. > ... Bernard, so did you consider whether CalDAV is going to be based on RFC2518 or on RFC2518bis? That is, would a CalDAV client be able to rely on RFC2518bis, or would they need to interact with both kinds of servers? Are CalDAV server implementors implementing RFC2518bis (or are they planning to)? 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 77A667F9DB for ; Thu, 16 Mar 2006 16:24:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68981142296 for ; Thu, 16 Mar 2006 16:24:35 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11545-03 for ; Thu, 16 Mar 2006 16:24:35 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id D55DB14228F for ; Thu, 16 Mar 2006 16:24:34 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so501707wra for ; Thu, 16 Mar 2006 16:24:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b5IwqrE5sZdmqcv/WxEP5DZDtS2Qlt7TVUV/hisierFFwYgO01qzkpD1uBYv3gDhE2oz5Db2HGAjKb3LVVKtPvyKyBxhQOHQ/gMfD6qV/OwLdcsoOGm7uAO8J5PywGp0KVMGKpW3m2Pk9wFTOQ0/CL+i64MeVlPRcbt8ZvuvTNo= Received: by 10.54.113.16 with SMTP id l16mr797928wrc; Thu, 16 Mar 2006 16:24:34 -0800 (PST) Received: by 10.54.98.20 with HTTP; Thu, 16 Mar 2006 16:24:34 -0800 (PST) Message-ID: <29a761a00603161624j29635ee7g9450340e8ffb0151@mail.gmail.com> Date: Thu, 16 Mar 2006 16:24:34 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <4419FF62.2060506@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <4419FF62.2060506@oracle.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 00:24:35 -0000 On 3/16/06, Bernard Desruisseaux wrote: > The Accept request-header field can be used to specify certain > media types which are acceptable for the response. I believe > PROPFIND can only return responses of media type "text/xml" > and "application/xml". The Accept request-header does not impact > which resources are reported by PROPFIND. ah, good point. the Accept header is basically rendered useless with webdav by the xml envelope. great. > If you insist to have your collection accessible by a single URL > you could request the Cosmo-aware clients to specify a proprietary > request-header (e.g., X-OSAF-Something) in each of their requests. > Cosmo would enable its CalDAV proprietary extension that allows > resources of arbitrary media type in calendar collections only when > this proprietary request-header is specified in a request. thanks for the suggestion, but i get the impression that you are blowing off what i and at least a couple of others seem to think is a valid use case. there has been no comment on my assertion that caldav is written from a perspective that assumes calendar data is of primary importance to a server, giving short shrift to servers where calendar is just one of many data types that can be freely interspersed. can you and/or lisa and/or cyrus address this? thanks. 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 984127F9D5; Thu, 16 Mar 2006 16:14:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 89F6C14228C; Thu, 16 Mar 2006 16:14:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03995-06; Thu, 16 Mar 2006 16:14:35 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CCB6A14228F; Thu, 16 Mar 2006 16:14:35 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2H0EYTB028249; Thu, 16 Mar 2006 18:14:34 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2H0EXui012447; Thu, 16 Mar 2006 17:14:33 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw5-141-144-105-41.vpn.oracle.com [141.144.105.41]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2H0ELrh012288; Thu, 16 Mar 2006 17:14:24 -0700 Message-ID: <4419FF62.2060506@oracle.com> Date: Thu, 16 Mar 2006 19:14:26 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> In-Reply-To: <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 17 Mar 2006 00:14:36 -0000 Brian, The Accept request-header field can be used to specify certain media types which are acceptable for the response. I believe PROPFIND can only return responses of media type "text/xml" and "application/xml". The Accept request-header does not impact which resources are reported by PROPFIND. If you insist to have your collection accessible by a single URL you could request the Cosmo-aware clients to specify a proprietary request-header (e.g., X-OSAF-Something) in each of their requests. Cosmo would enable its CalDAV proprietary extension that allows resources of arbitrary media type in calendar collections only when this proprietary request-header is specified in a request. Cheers, Bernard Brian Moseley wrote: > On 3/16/06, Bernard Desruisseaux wrote: > > >>A calendar object resource would be accessible via two URLs: >> >> /home/brian/generic/mtg123.ics -- regular collection >> /home/brian/calendar/mtg123.ics -- calendar collection >> >>and these two URLs would be mapped to the same resource in your >>internal store (you don't want to duplicate data). > > > that is technically possible, but it doesn't meet our requirement for > having a collection accessible by a single url :) > > here's the "maximum interop, user friendly" chandler/cosmo sharing scenario: > > 1) user A shares a collection of data containing resource of many > types, including some of multiple types (for example, "all of my work > stuff") to cosmo, which responds with the url to the shared collection > > 2) user A sends that url to user B, another chandler user, who > subscribes to the shared collection using chandler's "smart" > capabilities, receiving all of the resources in the collection, > regardless of type > > 3) user A sends the same url to user C, an evolution user, who > subscribes to the shared collection using caldav, receiving just the > calendar resources (and multitype resources stamped as calendar > objects) > > 4) user A sends the same url to user D, an ical user, who subscribes > to the shared collection using "webcal", receiving a monolithic > icalendar object containing icalendar representations of all of the > calendar resources (and multitype resources stamped as calendar > objects) > > we want a single cosmo collection to masquerade as a caldav calendar > collection for user and as a webcal-style monolithic calendar > resource for user D, as well as operating as a "smart" collection for > chandler. > > the caldav scenario is the only problematic one, since the caldav > client has no way to ask for just the calendar resources from the > collection. we have no way of distinguishing between a caldav client > and a "smart" client. using the Accept header would solve this > problem, no? > _______________________________________________ > 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 7A8377F9CC for ; Thu, 16 Mar 2006 15:08:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6C53C14229A for ; Thu, 16 Mar 2006 15:08:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29978-05 for ; Thu, 16 Mar 2006 15:08:35 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id AC61E142298 for ; Thu, 16 Mar 2006 15:08:35 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so492029wra for ; Thu, 16 Mar 2006 15:08:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B/Ch9baVD1yEzOOx6RCHLYJeRY19PPvWEVChOUbg0OD7qreC5sUMDXfatLVl+YaT8RnrNrKiTceuRR2iNGtwAX6GNfYG+7s6aAPoIv/TgFevJdwyao8uIR27PFsbcaF7KGHdjWscGawhSf9OjV4d9tyN/9gH/QkvJ5q7gcKXRG4= Received: by 10.54.99.12 with SMTP id w12mr375051wrb; Thu, 16 Mar 2006 15:08:34 -0800 (PST) Received: by 10.54.98.20 with HTTP; Thu, 16 Mar 2006 15:08:34 -0800 (PST) Message-ID: <29a761a00603161508t2c037e89sa98580cca0270338@mail.gmail.com> Date: Thu, 16 Mar 2006 15:08:34 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <643BA7EB-5669-4F66-9356-A01FF47677A1@opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> <643BA7EB-5669-4F66-9356-A01FF47677A1@opengroupware.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 23:08:36 -0000 On 3/16/06, Helge Hess wrote: > This is mostly irrelevant to the discussion, but of course the client > has a way. It just needs to use a REPORT to retrieve the events. But > thats beside the point. right, that's why i didn't address it :) > > using the Accept header would solve this problem, no? > > Not the actual problem, no. The problem is that it makes the servers > more complicated if the client is allowed to PUT arbitary content > into a calendar collection. And that every MAY makes conforming to > the standard harder. but it's the server implementors' choice whether or not they want to make their server more complicated or not, not the standards body's. please explain how MAY makes compliance harder. if you don't want to implement the optional feature, on either the client or server end, then don't. what's hard about that? do you have a specific example of MAY leading to increased complexity or difficulty? > You basically explain how Chandler won't be a conforming CalDAV > client but only works with Cosmo (because it relies on that feature > instead of honoring the MAY)? i explained how chandler and cosmo operate together, and how clients that implement today's caldav draft work with cosmo. chandler has a "vanilla" caldav compatibility mode as well. i didn't see the need to go into that. > It does not seem to support this use case: > 5) a user using a server w/o PUT / PROPPATCH / abc support sends a > URL to a > Chandler user. The Chandler user won't be able to use the collection > because it doesn't support required features. in this case, chandler acts just as a standard caldav client. > Well and thats really against a standardization effort, no? And > proves my concern that there will be clients which will most likely > ignore a MAY and will work with just 50% of the servers :-| there may be, but those are lazy clients. the solution is not to dumb the spec down to encourage their laziness but rather to let the community and competition weed out those clients (or conversely for the community to signal its overwhelming desire for the client that only works with half of the servers). > Summary: *if* this feature is considered crucial for a working > calendaring standard, it IMHO should be a MUST. since your assumption is that i consider it crucial is invalid, then so is this statement. i still hold that servers ought to have the choice to support arbitrary content in a calendar collection and, if they do, they should be required to be fully compatible with clients that do not support arbitrary content in a calendar collection. 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 C0C697F996 for ; Thu, 16 Mar 2006 14:20:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2A65142296 for ; Thu, 16 Mar 2006 14:20:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21262-08 for ; Thu, 16 Mar 2006 14:20:52 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id DDFB7142280 for ; Thu, 16 Mar 2006 14:20:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 995793D69B6 for ; Thu, 16 Mar 2006 23:17:34 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id 3D8C23D6994 for ; Thu, 16 Mar 2006 23:17:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <643BA7EB-5669-4F66-9356-A01FF47677A1@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Thu, 16 Mar 2006 23:20:58 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 22:20:52 -0000 On 16. Mrz 2006, at 22:51 Uhr, Brian Moseley wrote: > the caldav scenario is the only problematic one, since the caldav > client has no way to ask for just the calendar resources from the > collection. This is mostly irrelevant to the discussion, but of course the client has a way. It just needs to use a REPORT to retrieve the events. But thats beside the point. > using the Accept header would solve this problem, no? Not the actual problem, no. The problem is that it makes the servers more complicated if the client is allowed to PUT arbitary content into a calendar collection. And that every MAY makes conforming to the standard harder. (Of course it always makes sense to send a proper Accept. But if the client needs to deal with that, it can also just check the content- type property/header prior attempting a GET.) You basically explain how Chandler won't be a conforming CalDAV client but only works with Cosmo (because it relies on that feature instead of honoring the MAY)? It does not seem to support this use case: 5) a user using a server w/o PUT / PROPPATCH / abc support sends a URL to a Chandler user. The Chandler user won't be able to use the collection because it doesn't support required features. Well and thats really against a standardization effort, no? And proves my concern that there will be clients which will most likely ignore a MAY and will work with just 50% of the servers :-| Summary: *if* this feature is considered crucial for a working calendaring standard, it IMHO should be a MUST. Same thing for PROPPATCH, iCal X-* properties and iCal VATTACH components (we had the discussion ...). The RFC should give definite directions on what MUST be available and highlight that MAY features may not be used (w/o proper fallback) in a conforming client. regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E0E0D7F9AD for ; Thu, 16 Mar 2006 13:51:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D1B8D142293 for ; Thu, 16 Mar 2006 13:51:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21719-10 for ; Thu, 16 Mar 2006 13:51:47 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by laweleka.osafoundation.org (Postfix) with ESMTP id 432B714228C for ; Thu, 16 Mar 2006 13:51:47 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so480278wra for ; Thu, 16 Mar 2006 13:51:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rtLYKgX73VmhBS2g6Pq/hBQae8TaVTXfU4X1heZOub9Du0tnY+VyGeoCvlixu0npSr0hdT4oVEtS6bA0iADwrELQnisidluVSvzFB2ywt+XfdGyuIFSVeFE7v4u/tIgc3dYMNthc40fm0/RKJubgNN4h8ZWwrQYLbOx47b76JzY= Received: by 10.54.123.15 with SMTP id v15mr376222wrc; Thu, 16 Mar 2006 13:51:46 -0800 (PST) Received: by 10.54.98.20 with HTTP; Thu, 16 Mar 2006 13:51:46 -0800 (PST) Message-ID: <29a761a00603161351j314ef16el41dd60a67cd11026@mail.gmail.com> Date: Thu, 16 Mar 2006 13:51:46 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <4419D770.7050907@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> <4419D770.7050907@oracle.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 21:51:48 -0000 On 3/16/06, Bernard Desruisseaux wrote: > A calendar object resource would be accessible via two URLs: > > /home/brian/generic/mtg123.ics -- regular collection > /home/brian/calendar/mtg123.ics -- calendar collection > > and these two URLs would be mapped to the same resource in your > internal store (you don't want to duplicate data). that is technically possible, but it doesn't meet our requirement for having a collection accessible by a single url :) here's the "maximum interop, user friendly" chandler/cosmo sharing scenario= : 1) user A shares a collection of data containing resource of many types, including some of multiple types (for example, "all of my work stuff") to cosmo, which responds with the url to the shared collection 2) user A sends that url to user B, another chandler user, who subscribes to the shared collection using chandler's "smart" capabilities, receiving all of the resources in the collection, regardless of type 3) user A sends the same url to user C, an evolution user, who subscribes to the shared collection using caldav, receiving just the calendar resources (and multitype resources stamped as calendar objects) 4) user A sends the same url to user D, an ical user, who subscribes to the shared collection using "webcal", receiving a monolithic icalendar object containing icalendar representations of all of the calendar resources (and multitype resources stamped as calendar objects) we want a single cosmo collection to masquerade as a caldav calendar collection for user and as a webcal-style monolithic calendar resource for user D, as well as operating as a "smart" collection for chandler. the caldav scenario is the only problematic one, since the caldav client has no way to ask for just the calendar resources from the collection. we have no way of distinguishing between a caldav client and a "smart" client. using the Accept header would solve this problem, no? 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 9C1CF7F94A; Thu, 16 Mar 2006 13:26:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E7B3142293; Thu, 16 Mar 2006 13:26:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20100-05; Thu, 16 Mar 2006 13:26:08 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D534A14228F; Thu, 16 Mar 2006 13:26:07 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2GLQ6gl021890; Thu, 16 Mar 2006 15:26:06 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2GLQ5H6015353; Thu, 16 Mar 2006 14:26:06 -0700 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 k2GLQ3eH015344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 16 Mar 2006 14:26:04 -0700 Message-ID: <4419D770.7050907@oracle.com> Date: Thu, 16 Mar 2006 16:24:00 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> In-Reply-To: <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 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, 16 Mar 2006 21:26:08 -0000 I understand the internal data model of Cosmo allows resources of arbitrary media type to co-exist in the same container. For each container you could have a regular WebDAV collection that would give access to all the resources in the container, and a calendar collection that would only give access to the calendar object resources contained in the container. A calendar object resource would be accessible via two URLs: /home/brian/generic/mtg123.ics -- regular collection /home/brian/calendar/mtg123.ics -- calendar collection and these two URLs would be mapped to the same resource in your internal store (you don't want to duplicate data). Cheers, Bernard Brian Moseley wrote: > On 3/16/06, Helge Hess wrote: > > >>Whats the use case for storing additional content in a calendar? > > > cosmo is a generic content repository that happens to allow caldav > access. it supports content that is "stamped" as various types - > imagine a resource that is simultaneously an event, a task, and an > email message. > > i want to support caldav access to a collection filled with resources > with arbitrary media types. one such media type might be something > like "text/x-multitype" for a resource that encloses icalendar and > mime representations of the same data item. > > caldav clients should be able to send reports to these collections and > get back just calendar resources as they'd expect, including the > icalendar representations of these special multitype resources. other > "smart" clients should be able to put and get resources of arbitrary > types, including multitype as mentioned above. > > it is certainly true that i can implement cosmo to allow smart clients > to put whatever they want into cosmo's collections. however, if cosmo > allows a caldav client to behave this way, then it is contradicting > the caldav spec as written. of course most caldav clients won't try, > but still. > > i think the issue might be one of perspective. the draft is written > such that storing calendar resources is the primary job of a calendar > collection. from my point of view, a collection should only be thought > of as a calendar collection when it's time to service a caldav report. > > i understand the issue where a caldav client propfinds a calendar > collection and finds resources with media types it can't handle. > couldn't we specify that a client may send the Accept header limiting > the returned resources to just those that the client can handle? i'd > be satisfied if the default server behavior does not provide an Accept > header, is to include only text/calendar resources in the response. > providing an Accept header certainly seems to be the responsibility of > a "smart" client. > _______________________________________________ > 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 792DE7F95E for ; Thu, 16 Mar 2006 12:14:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68F9E14229A for ; Thu, 16 Mar 2006 12:14:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29998-04 for ; Thu, 16 Mar 2006 12:14:08 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5E84142298 for ; Thu, 16 Mar 2006 12:14:07 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so463744wra for ; Thu, 16 Mar 2006 12:14:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dVBTMAErTujzY8fK6lRWUEwtF0Im1kRM4CXQjjovbJnGEomMobsxX5fEGn5LgpgzqkcpKt+R0l+IQZ+YqTv4ZpjaYVnstKMCY1w+aJGEHILZgmfEqTC6oUdo2DI5zvczBHZUYOaRjPeA4Wa4+Uc/NqM5UWgq4PyxtJSEZFONs1E= Received: by 10.54.145.8 with SMTP id s8mr888705wrd; Thu, 16 Mar 2006 12:14:06 -0800 (PST) Received: by 10.54.98.20 with HTTP; Thu, 16 Mar 2006 12:14:06 -0800 (PST) Message-ID: <29a761a00603161214w531283beu3ca6653ebedd3af5@mail.gmail.com> Date: Thu, 16 Mar 2006 12:14:06 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <44196B25.8040004@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <44196B25.8040004@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 20:14:08 -0000 On 3/16/06, Julian Reschke wrote: > If your server is a generic server where a calendar just happens to be a > special case, it really doesn't make sense requiring the server to > reject other content. Thinking of it, server implementors aren't likely > to implement that constraint if it doesn't make sense to them (no matter > what the spec says...). unfortunately that is exactly the position i'm in at the moment with cosmo, if i choose not to place non-calendar content in subcollections. again, serving calendar data is not the be-all and end-all of my software. calendar is just one of the many content types cosmo supports. i'd like to be able to masquerade cosmo's collections as calendar collections when it serves my purpose (mainly allowing caldav clients to run reports), but i don't want caldav dictating my content model, which is (rather, will be) much more expansive than just events and tasks. 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 67C947F95F for ; Thu, 16 Mar 2006 12:10:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59939142298 for ; Thu, 16 Mar 2006 12:10:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07160-01 for ; Thu, 16 Mar 2006 12:10:44 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by laweleka.osafoundation.org (Postfix) with ESMTP id B1A0A14228C for ; Thu, 16 Mar 2006 12:10:44 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so463164wra for ; Thu, 16 Mar 2006 12:10:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HTU3fq4gQnVB5BN8VGx0a4Vpe4YuopfvspCYU0DaqrMPvWoaFoywPgkyg91+on60cdZD7tQeQyol+M2Vz3iEkoft4/WLhqhiQhdkw5ixLuJ9ysngCqGnZ6HU7zEtUyaGSPc/YIyCkdIPD3zVGv92hf90Y0d73gD6SOHDYT63c6Q= Received: by 10.54.99.12 with SMTP id w12mr226218wrb; Thu, 16 Mar 2006 12:10:43 -0800 (PST) Received: by 10.54.98.20 with HTTP; Thu, 16 Mar 2006 12:10:43 -0800 (PST) Message-ID: <29a761a00603161210q42a05883jf7bb43a340ff2948@mail.gmail.com> Date: Thu, 16 Mar 2006 12:10:43 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections In-Reply-To: <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 20:10:45 -0000 On 3/16/06, Helge Hess wrote: > Whats the use case for storing additional content in a calendar? cosmo is a generic content repository that happens to allow caldav access. it supports content that is "stamped" as various types - imagine a resource that is simultaneously an event, a task, and an email message. i want to support caldav access to a collection filled with resources with arbitrary media types. one such media type might be something like "text/x-multitype" for a resource that encloses icalendar and mime representations of the same data item. caldav clients should be able to send reports to these collections and get back just calendar resources as they'd expect, including the icalendar representations of these special multitype resources. other "smart" clients should be able to put and get resources of arbitrary types, including multitype as mentioned above. it is certainly true that i can implement cosmo to allow smart clients to put whatever they want into cosmo's collections. however, if cosmo allows a caldav client to behave this way, then it is contradicting the caldav spec as written. of course most caldav clients won't try, but still. i think the issue might be one of perspective. the draft is written such that storing calendar resources is the primary job of a calendar collection. from my point of view, a collection should only be thought of as a calendar collection when it's time to service a caldav report. i understand the issue where a caldav client propfinds a calendar collection and finds resources with media types it can't handle. couldn't we specify that a client may send the Accept header limiting the returned resources to just those that the client can handle? i'd be satisfied if the default server behavior does not provide an Accept header, is to include only text/calendar resources in the response. providing an Accept header certainly seems to be the responsibility of a "smart" client. 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 F1FA77F954 for ; Thu, 16 Mar 2006 11:41:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E2BE71422B7 for ; Thu, 16 Mar 2006 11:41:11 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24501-06 for ; Thu, 16 Mar 2006 11:41:11 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 979AF142298 for ; Thu, 16 Mar 2006 11:41:11 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k2GJf1wV029173; Thu, 16 Mar 2006 11:41:01 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id C8135324002; Thu, 16 Mar 2006 11:41:01 -0800 (PST) In-Reply-To: <44196B25.8040004@gmx.de> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <44196B25.8040004@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10889910-48B1-4153-A26D-A15CDEDF317A@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Thu, 16 Mar 2006 11:41:01 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 16 Mar 2006 19:41:12 -0000 This isn't exactly true. In a CalDAV server, a calendar collection is never generic; it _must_ be managed by the server. For example, when you PUT a calendar resource, it has to verify that the UID of the resource isn't already in use by another. -wsv On Mar 16, 2006, at 5:41 AM, Julian Reschke wrote: > If your server is a generic server where a calendar just happens to > be a special case, it really doesn't make sense requiring the > server to reject other content. 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 0F8EF7F969; Thu, 16 Mar 2006 07:10:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F32331422B7; Thu, 16 Mar 2006 07:10:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20796-10; Thu, 16 Mar 2006 07:10:51 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 64E671422A4; Thu, 16 Mar 2006 07:10:51 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2GFAnlR026421; Thu, 16 Mar 2006 09:10:50 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2GFAnjq011647; Thu, 16 Mar 2006 08:10:49 -0700 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2GFAcc4011579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 16 Mar 2006 08:10:39 -0700 Message-ID: <44197F87.6010605@oracle.com> Date: Thu, 16 Mar 2006 10:08:55 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> In-Reply-To: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 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, 16 Mar 2006 15:10:52 -0000 Hi Brian, Servers may allow clients to create regular collections in calendar collections for this purpose. Clients can store any kind of resources in those regular sub-collection including calendar resources that don't obey the restrictions of calendar collection. Sub-collections and their content is simply ignored by the calendaring reports. Servers may provide support for calendar resources of different media type (e.g., text/calendar for iCalendar, text/x-vCalendar for vCalendar). So, a resource might be considered as a non-calendar resource by one CalDAV server and as a calendar resource by another CalDAV server. If you could store a calendar resource in a media type not supported by the CalDAV server in a calendar collection (i.e., a non-calendar resource as far as this server can tell), you'll be stuck with an ugly problem the day the CalDAV server will be upgraded to support calendar resource of this media type. After the upgrade either some calendar resources that never appeared in your calendar will now show up or some calendar resources in your calendar collections will be considered invalid as they won't obey the restriction of calendar collections. Cheers, Bernard Brian Moseley wrote: > i'd like to re-examine the decision to blanket disallow non-calendar > resources within calendar collections. > > i recognize that for some servers it may not be possible to allow > anything other than an event or task to be put into a calendar > collection, but surely some would like to be able to support this > without contradicting the spec > > why not state that servers MAY allow non-calendar resources in > calendar collections, and that PUTs containing resources that are not > supported will return 415 responses? > _______________________________________________ > 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 91D9A7F9A0; Thu, 16 Mar 2006 06:44:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8262C1422A4; Thu, 16 Mar 2006 06:44:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28305-04; Thu, 16 Mar 2006 06:44:08 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E69014229A; Thu, 16 Mar 2006 06:44:08 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id F0FE9D40CD5; Thu, 16 Mar 2006 09:44:06 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Thu, 16 Mar 2006 09:44:07 -0500 X-Sasl-enc: vojj8ql+saVpoWgafy+Ksi70+hoZmE1BTd4y988Vptka 1142520242 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 4BF6A66C; Thu, 16 Mar 2006 09:44:02 -0500 (EST) Date: Thu, 16 Mar 2006 09:44:03 -0500 From: Cyrus Daboo To: Brian Moseley , CalDAV DevList Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Message-ID: <5091BE1225EFCA23C188876A@Cyrus-Daboo.local> In-Reply-To: <787A077135802436A7265C5A@ninevah.local> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <787A077135802436A7265C5A@ninevah.local> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 14:44:08 -0000 Hi Cyrus, --On March 16, 2006 9:31:32 AM -0500 Cyrus Daboo wrote: >> i'd like to re-examine the decision to blanket disallow non-calendar >> resources within calendar collections. >> >> i recognize that for some servers it may not be possible to allow >> anything other than an event or task to be put into a calendar >> collection, but surely some would like to be able to support this >> without contradicting the spec >> >> why not state that servers MAY allow non-calendar resources in >> calendar collections, and that PUTs containing resources that are not >> supported will return 415 responses? One other thing I wanted to point out relating to interoperability: if client A creates ancillary resources for a calendar object resource, and client B does not, then when client B copies/moves a calendar object between calendar collections, the ancillary data will likely not be moved (unless the server was somehow aware of it and moved it as well). That would likely 'upset' client A! Also, how would client B modifying the calendar data know to update the ancillary data? Whilst use of WebDAVC properties or X- items embedded in the iCal data solve the problem of moving/copying, they don't address the data consistency issue. So careful thought needs to be given to the use cases for such resources to ensure interoperability at at least the basic iCal level can always be maintained. -- 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 8C63E7F577 for ; Thu, 16 Mar 2006 06:34:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DD7A1422B4 for ; Thu, 16 Mar 2006 06:34:25 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14742-07 for ; Thu, 16 Mar 2006 06:34:25 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 176441422A4 for ; Thu, 16 Mar 2006 06:34:25 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 26DF0D40CAC; Thu, 16 Mar 2006 09:34:24 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Thu, 16 Mar 2006 09:34:24 -0500 X-Sasl-enc: eVHYJMc0zy8TDeKBMC/be8RGaR6pMdKx13RcL17B/e9+ 1142519660 Received: from [10.0.1.4] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id 9219B6D9; Thu, 16 Mar 2006 09:34:18 -0500 (EST) Date: Thu, 16 Mar 2006 09:34:20 -0500 From: Cyrus Daboo To: "Kervin L. Pierre" , Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Message-ID: <211A8C60DF075F76EE0AC461@ninevah.local> In-Reply-To: <44197068.7070402@adevsoft.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <44197068.7070402@adevsoft.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 14:34:25 -0000 Hi Kervin, --On March 16, 2006 9:04:24 AM -0500 "Kervin L. Pierre" wrote: > Client specific resources necessary to render the > calendar, or otherwise tie events to client specific > features. Eg. Additional MAPI properties if your > client uses that API, icons, etc. Could data like that be stored as a WebDAV property on the calendar object resource? Obviously large chunks of data would not be suitable as WebDAV properties, but small bits of 'meta-data' would. > I don't have a strong opinion on this, personally > we haven't needed to do this as yet. And if it > became necessary a 'shadow' regular WebDAV folder > would work just as well, though requiring an > additional piece of information. Obviously a WebDAV property could be used to 'point' to the location of such a 'shadow' collection or resources. -- 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 7191E7F577; Thu, 16 Mar 2006 06:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 627B41422A4; Thu, 16 Mar 2006 06:31:37 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17545-06; Thu, 16 Mar 2006 06:31:37 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id DFB4314229A; Thu, 16 Mar 2006 06:31:36 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id C0608D40C5D; Thu, 16 Mar 2006 09:31:35 -0500 (EST) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend1.internal (MEProxy); Thu, 16 Mar 2006 09:31:35 -0500 X-Sasl-enc: 8E9JqoCMVhIOdEhpA0T5TaNDk+M1VK/QdTgtl3ledTyF 1142519490 Received: from [10.0.1.4] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id 5E4AD5E2; Thu, 16 Mar 2006 09:31:29 -0500 (EST) Date: Thu, 16 Mar 2006 09:31:32 -0500 From: Cyrus Daboo To: Brian Moseley , CalDAV DevList Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Message-ID: <787A077135802436A7265C5A@ninevah.local> In-Reply-To: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 14:31:37 -0000 Hi Brian, --On March 15, 2006 8:47:52 PM -0800 Brian Moseley wrote: > i'd like to re-examine the decision to blanket disallow non-calendar > resources within calendar collections. > > i recognize that for some servers it may not be possible to allow > anything other than an event or task to be put into a calendar > collection, but surely some would like to be able to support this > without contradicting the spec > > why not state that servers MAY allow non-calendar resources in > calendar collections, and that PUTs containing resources that are not > supported will return 415 responses? Note that the current spec does allow regular collections inside of a calendar collection (c.f. Section 4.2). So there is nothing to stop a client creating its own private collection inside a calendar and storing whatever it wants in there. Yes that does mean non-calendar resources at Depth:1 in a calendar collection are disallowed, but you can have that at 'lower' depths than that if needs be. The benefit of keeping non-calendar resources out of the top-level of the calendar is that clients and servers can easily ignore such data by simply doing Depth:1 PROPFINDs etc. Thus clients that don't use the extra 'meta' data resources don't pay the penalty of 'seeing' them in PROPFINDs. Yes they will see the regular collections - but hopefully those will be fewer than the resources they might contain. -- 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 3EF2D7F575 for ; Thu, 16 Mar 2006 06:23:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EA4B1422B4 for ; Thu, 16 Mar 2006 06:23:21 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22040-06 for ; Thu, 16 Mar 2006 06:23:20 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E08B1422A4 for ; Thu, 16 Mar 2006 06:23:20 -0800 (PST) Received: from [128.113.124.232] (kiva-04.dynamic2.rpi.edu [128.113.124.232]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id k2GENJGK002106 for ; Thu, 16 Mar 2006 09:23:19 -0500 Message-ID: <441974D7.3030406@rpi.edu> Date: Thu, 16 Mar 2006 09:23:19 -0500 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: CalDAV DevList Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <44196B25.8040004@gmx.de> In-Reply-To: <44196B25.8040004@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, MISSING_HEADERS 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, 16 Mar 2006 14:23:21 -0000 It makes sense in that it helps to ensure dependencies on non-caldav resources don't become a requirement. I don't think that stops implementors adding features outside of caldav if they wish but I believe the protocol should specify only what is required for caldav interoperability. If it's the case that interoperability with exchange say, requires some extra information, then maybe we should build that in Julian Reschke wrote: > Helge Hess wrote: > >> On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote: >> >>> why not state that servers MAY allow non-calendar resources in >>> calendar collections, and that PUTs containing resources that are not >>> supported will return 415 responses? >> >> >> Whats the use case for storing additional content in a calendar? >> >> I think the danger is that some clients will ignore the MAY in the >> spec and will just not work (properly) with servers not supporting >> arbitary content. > > > Depends on where you come from. > > If your server is a generic server where a calendar just happens to be > a special case, it really doesn't make sense requiring the server to > reject other content. Thinking of it, server implementors aren't > likely to implement that constraint if it doesn't make sense to them > (no matter what the spec says...). > > 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 -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DBBF27F990 for ; Thu, 16 Mar 2006 06:18:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC7381422A4 for ; Thu, 16 Mar 2006 06:18:02 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27706-08 for ; Thu, 16 Mar 2006 06:18:02 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 46E1E14229A for ; Thu, 16 Mar 2006 06:18:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 656983D5E47 for ; Thu, 16 Mar 2006 15:14:43 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id EEAA53D63C7 for ; Thu, 16 Mar 2006 15:14:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44197068.7070402@adevsoft.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> <44197068.7070402@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Thu, 16 Mar 2006 15:18:08 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 14:18:03 -0000 On 16. Mrz 2006, at 15:04 Uhr, Kervin L. Pierre wrote: > Eg. Additional MAPI properties if your > client uses that API, icons, etc. For exactly this a MAY would not be sufficient. Either CalDAV requires the server to support additional resources, then this can be used by a MAPI plugin to store additional stuff directly in the calendar OR it doesn't. In the latter case it must store the additional info somewhere else anyway (or opt to be incompatible with certain CalDAV servers, which is my concern). I'm not so much against the feature itself but I'm against having to many MAYs, this just increases complexity for everyone :-) BTW: for MAPI properties one would preferably either use WebDAV properties on the resource or iCalendar X- fields. However MAPI messages can also contain attachments which could be stored as separate resources (probably better for performance than storing them inside a VATTACH section ...) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 641497F98D for ; Thu, 16 Mar 2006 06:04:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 563471422A4 for ; Thu, 16 Mar 2006 06:04:17 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04162-09 for ; Thu, 16 Mar 2006 06:04:17 -0800 (PST) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by laweleka.osafoundation.org (Postfix) with SMTP id C2A7C14229A for ; Thu, 16 Mar 2006 06:04:16 -0800 (PST) Received: (qmail 13566 invoked from network); 16 Mar 2006 14:04:15 -0000 Received: from unknown (HELO ?192.168.0.70?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 16 Mar 2006 14:04:15 -0000 Message-ID: <44197068.7070402@adevsoft.com> Date: Thu, 16 Mar 2006 09:04:24 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> In-Reply-To: <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 16 Mar 2006 14:04:17 -0000 Helge Hess wrote: > Whats the use case for storing additional content in a calendar? > Client specific resources necessary to render the calendar, or otherwise tie events to client specific features. Eg. Additional MAPI properties if your client uses that API, icons, etc. I don't have a strong opinion on this, personally we haven't needed to do this as yet. And if it became necessary a 'shadow' regular WebDAV folder would work just as well, though requiring an additional piece of information. 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 B9BB07F96C for ; Thu, 16 Mar 2006 05:43:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9834142266 for ; Thu, 16 Mar 2006 05:43:20 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06074-10 for ; Thu, 16 Mar 2006 05:43:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id BCA7B142264 for ; Thu, 16 Mar 2006 05:43:19 -0800 (PST) Received: (qmail invoked by alias); 16 Mar 2006 13:43:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 16 Mar 2006 14:43:16 +0100 X-Authenticated: #1915285 Message-ID: <44196B25.8040004@gmx.de> Date: Thu, 16 Mar 2006 14:41:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> In-Reply-To: <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@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.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 13:43:20 -0000 Helge Hess wrote: > On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote: >> why not state that servers MAY allow non-calendar resources in >> calendar collections, and that PUTs containing resources that are not >> supported will return 415 responses? > > Whats the use case for storing additional content in a calendar? > > I think the danger is that some clients will ignore the MAY in the spec > and will just not work (properly) with servers not supporting arbitary > content. Depends on where you come from. If your server is a generic server where a calendar just happens to be a special case, it really doesn't make sense requiring the server to reject other content. Thinking of it, server implementors aren't likely to implement that constraint if it doesn't make sense to them (no matter what the spec says...). 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 5E8997F98C for ; Thu, 16 Mar 2006 05:30:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F2DE1422A4 for ; Thu, 16 Mar 2006 05:30:28 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11995-09 for ; Thu, 16 Mar 2006 05:30:28 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id D042614229A for ; Thu, 16 Mar 2006 05:30:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1C6F83D58F1 for ; Thu, 16 Mar 2006 14:27:08 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id E4C923D6176 for ; Thu, 16 Mar 2006 14:27:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FC4F7E6-0FDD-46B4-90C7-775F2CBEBE4B@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections Date: Thu, 16 Mar 2006 14:30:33 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 13:30:28 -0000 On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote: > why not state that servers MAY allow non-calendar resources in > calendar collections, and that PUTs containing resources that are not > supported will return 415 responses? Whats the use case for storing additional content in a calendar? I think the danger is that some clients will ignore the MAY in the spec and will just not work (properly) with servers not supporting arbitary content. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 26FEF7F984 for ; Thu, 16 Mar 2006 00:24:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 17BAD1422BC for ; Thu, 16 Mar 2006 00:24:18 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08388-07 for ; Thu, 16 Mar 2006 00:24:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 145131422B7 for ; Thu, 16 Mar 2006 00:24:15 -0800 (PST) Received: (qmail invoked by alias); 16 Mar 2006 08:24:14 -0000 Received: from p508FB80E.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.14] by mail.gmx.net (mp041) with SMTP; 16 Mar 2006 09:24:14 +0100 X-Authenticated: #1915285 Message-ID: <44192068.6080409@gmx.de> Date: Thu, 16 Mar 2006 09:23:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Moseley Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> In-Reply-To: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.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=-1.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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, 16 Mar 2006 08:24:18 -0000 Brian Moseley wrote: > i'd like to re-examine the decision to blanket disallow non-calendar > resources within calendar collections. > > i recognize that for some servers it may not be possible to allow > anything other than an event or task to be put into a calendar > collection, but surely some would like to be able to support this > without contradicting the spec > > why not state that servers MAY allow non-calendar resources in > calendar collections, and that PUTs containing resources that are not > supported will return 415 responses? That sounds like the right approach to me. 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 280067F5D5 for ; Wed, 15 Mar 2006 20:47:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1975E1422AD for ; Wed, 15 Mar 2006 20:47:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06943-05 for ; Wed, 15 Mar 2006 20:47:52 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id A6F061422AA for ; Wed, 15 Mar 2006 20:47:52 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i23so316677wra for ; Wed, 15 Mar 2006 20:47:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=p6ZFpIfODAc+ez3DuF0WsI0wxoxiKwsn3jDwwzoI8GhXLBZfo2xUKvV0mzvklTpTzQM9QnUF2EsKeUURm+UgZSCLCtIxLfhW3fbIRNkdgtUeis4zXDYQMAgda7a2/l+lnCXcjR2dihiZxFZ3O7K4c+k2v/PB/Iz3Vmkyg4smxsc= Received: by 10.54.117.19 with SMTP id p19mr238211wrc; Wed, 15 Mar 2006 20:47:52 -0800 (PST) Received: by 10.54.98.20 with HTTP; Wed, 15 Mar 2006 20:47:52 -0800 (PST) Message-ID: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> Date: Wed, 15 Mar 2006 20:47:52 -0800 From: "Brian Moseley" Sender: ixjonez@gmail.com To: "CalDAV DevList" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_BY_IP X-Spam-Level: Subject: [Ietf-caldav] non-calendar resources in calendar collections 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, 16 Mar 2006 04:47:53 -0000 i'd like to re-examine the decision to blanket disallow non-calendar resources within calendar collections. i recognize that for some servers it may not be possible to allow anything other than an event or task to be put into a calendar collection, but surely some would like to be able to support this without contradicting the spec why not state that servers MAY allow non-calendar resources in calendar collections, and that PUTs containing resources that are not supported will return 415 responses? 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 DA02A7F53C; Wed, 15 Mar 2006 18:35:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAB241422AA; Wed, 15 Mar 2006 18:35:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09020-06; Wed, 15 Mar 2006 18:35:57 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E60D314229A; Wed, 15 Mar 2006 18:35:56 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2G2ZtQa029227; Wed, 15 Mar 2006 19:35:55 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2G2ZsR0000312; Wed, 15 Mar 2006 19:35:54 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-65.vpn.oracle.com [141.144.96.65]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2G2Zm54032749; Wed, 15 Mar 2006 19:35:52 -0700 Message-ID: <4418CF08.7090300@oracle.com> Date: Wed, 15 Mar 2006 21:35:52 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> In-Reply-To: <440D8CFC.3040706@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Ted Hardie , Calsify WG , WebDAV WG 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, 16 Mar 2006 02:35:58 -0000 I thought it would be worthwhile to update everybody on the changes we are planning to make in draft -11 based on the issues that have been brought up so far: - Added new preconditions: * CALDAV:number-of-recurrences-within-limits for PUT; * CALDAV:calendar-collection-location-ok for MOVE and COPY. - Redefined the CALDAV:no-uid-conflict precondition. - Minor editorial changes. - Update to references. - Added element CALDAV:is-not-defined. - Added new attribute "negate-condition" to the CALDAV:text-match element. The last two changes were required to be able to query the to-dos that are *not* completed and *not* cancelled. The issue is that the CALDAV:calendar-query REPORT does not provide support for a "not" operator. To be able to address the above use case without increasing the complexity of the CALDAV:calendar-query REPORT significantly we have decided to add a new condition "is-not-defined" and to add a "negate-condition" attribute to be able to negate the "text-match" condition. Here's the DTD declarations that will be added to the draft: Here's an example for the to-dos use case: REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx CANCELLED Please continue to send us feedback/questions/comments. Thanks, Bernard Bernard Desruisseaux wrote: > Quick update. We will submit the CalDAV draft for Last Call when > Internet-Draft posting will resume after the next IETF meeting. > That will give more time to people to review the draft. > > Cheers, > Bernard > > Bernard Desruisseaux wrote: > >> >> We submitted CalDAV draft -10 to the IETF yesterday. The draft has >> not been officially announced yet, but it is already available for >> you to review at the following URL: >> >> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt >> >> We would like to submit the CalDAV draft for Last Call in time for >> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do >> so, we would like to get as much feedback as possible from the >> participants of the "ietf-caldav" mailing list as well as from the >> members of the WebDAV and Calsify Working Groups. >> >> Once officially announced the draft should be available at: >> >> http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt >> >> Previous versions of the draft are available at: >> >> http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ >> >> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: >> >> mailto:ietf-caldav@osafoundation.org >> >> which is archived at: >> >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >> Reports on the 4 CalDAV Interoperability Events organized by the >> Calendaring and Scheduling Consortium (CalConnect) can be found at: >> >> http://www.calconnect.org/ioppast.html >> >> Finally, additional information on CalDAV can also be found at: >> >> http://ietf.webdav.org/caldav/ >> >> Please review draft -10 and send us feedback/questions/comments. >> >> Thanks for you help! >> >> Cheers, >> Bernard >> >> -- >> >> C.1. Changes in -10 >> >> a. Added new section about support for X- items when storing data. >> >> b. Added new precondition to allow servers to reject queries on >> unsupported X- items, and a new example. >> >> c. Added new text about always supporting X- in calendar-data. >> >> d. Created new section for PUT, COPY and MOVE preconditions. >> >> e. Report examples re-done with full listing of calendar data in >> Appendix. >> >> f. Removed description of using UID, SUMMARY etc as resource name. >> >> g. Indicate that calendar object resource may contain only >> overridden components. >> >> h. Add security consideration about not expose details in resource >> names. >> >> i. Add constraint that free-busy-query can only be run on a >> collection. >> >> j. Add preconditions for calendar-timezone property/elements in >> MKCALENDAR, PROPPATCH and calendar-query REPORT. >> >> k. Fix principal-match example. >> >> >> > > _______________________________________________ > 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 AE2D37F5F8; Tue, 7 Mar 2006 05:41:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9EF8314229B; Tue, 7 Mar 2006 05:41:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10274-03; Tue, 7 Mar 2006 05:41:00 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E271F14229A; Tue, 7 Mar 2006 05:40:59 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27Devri017415; Tue, 7 Mar 2006 07:40:57 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k27DeuaI002847; Tue, 7 Mar 2006 06:40:56 -0700 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 k27Deos3002815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 7 Mar 2006 06:40:51 -0700 Message-ID: <440D8CFC.3040706@oracle.com> Date: Tue, 07 Mar 2006 08:39:08 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList , Calsify WG , WebDAV WG References: <43FD273E.3020702@oracle.com> In-Reply-To: <43FD273E.3020702@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: Ted Hardie Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call 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, 07 Mar 2006 13:41:00 -0000 Quick update. We will submit the CalDAV draft for Last Call when Internet-Draft posting will resume after the next IETF meeting. That will give more time to people to review the draft. Cheers, Bernard Bernard Desruisseaux wrote: > > We submitted CalDAV draft -10 to the IETF yesterday. The draft has > not been officially announced yet, but it is already available for > you to review at the following URL: > > http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt > > We would like to submit the CalDAV draft for Last Call in time for > the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do > so, we would like to get as much feedback as possible from the > participants of the "ietf-caldav" mailing list as well as from the > members of the WebDAV and Calsify Working Groups. > > Once officially announced the draft should be available at: > > http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt > > Previous versions of the draft are available at: > > http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ > > Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: > > mailto:ietf-caldav@osafoundation.org > > which is archived at: > > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Reports on the 4 CalDAV Interoperability Events organized by the > Calendaring and Scheduling Consortium (CalConnect) can be found at: > > http://www.calconnect.org/ioppast.html > > Finally, additional information on CalDAV can also be found at: > > http://ietf.webdav.org/caldav/ > > Please review draft -10 and send us feedback/questions/comments. > > Thanks for you help! > > Cheers, > Bernard > > -- > > C.1. Changes in -10 > > a. Added new section about support for X- items when storing data. > > b. Added new precondition to allow servers to reject queries on > unsupported X- items, and a new example. > > c. Added new text about always supporting X- in calendar-data. > > d. Created new section for PUT, COPY and MOVE preconditions. > > e. Report examples re-done with full listing of calendar data in > Appendix. > > f. Removed description of using UID, SUMMARY etc as resource name. > > g. Indicate that calendar object resource may contain only > overridden components. > > h. Add security consideration about not expose details in resource > names. > > i. Add constraint that free-busy-query can only be run on a > collection. > > j. Add preconditions for calendar-timezone property/elements in > MKCALENDAR, PROPPATCH and calendar-query REPORT. > > k. Fix principal-match example. > > > 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 E29077F5BE for ; Wed, 1 Mar 2006 15:37:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D50D51422BB for ; Wed, 1 Mar 2006 15:37:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08683-08 for ; Wed, 1 Mar 2006 15:37:10 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B9701422B7 for ; Wed, 1 Mar 2006 15:37:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 47D1D3CECCD for ; Thu, 2 Mar 2006 00:35:45 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id B70203CECC9 for ; Thu, 2 Mar 2006 00:35:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <415A0FEE-8E23-48EE-B6B2-7A1AE202093D@osafoundation.org> References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> <415A0FEE-8E23-48EE-B6B2-7A1AE202093D@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <611A1ED9-917C-4C98-A456-156E216AF0A7@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Thu, 2 Mar 2006 00:36:58 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:37:11 -0000 On 2. Mrz 2006, at 00:31 Uhr, Lisa Dusseault wrote: > Not sure what you want a summary of. If you want to know the > practical differences between RFC2518 and RFC2518bis, there's a > section for that at the bottom of the RFC2518bis doc, sorted > roughly according to whether an implementor is likely to have to > make changes as a result of the spec change. Ah thanks, that is what I was looking for. For reference: http://tools.ietf.org/html/draft-ietf-webdav- rfc2518bis-14.txt#page-135 Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 197937F5BE for ; Wed, 1 Mar 2006 15:31:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09F471422BE for ; Wed, 1 Mar 2006 15:31:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31643-04; Wed, 1 Mar 2006 15:31:44 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 34CBA1422BB; Wed, 1 Mar 2006 15:31:44 -0800 (PST) In-Reply-To: References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <415A0FEE-8E23-48EE-B6B2-7A1AE202093D@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Wed, 1 Mar 2006 15:31:26 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Wed, 01 Mar 2006 23:31:45 -0000 Not sure what you want a summary of. If you want to know the practical differences between RFC2518 and RFC2518bis, there's a section for that at the bottom of the RFC2518bis doc, sorted roughly according to whether an implementor is likely to have to make changes as a result of the spec change. Lisa On Mar 1, 2006, at 3:27 PM, Helge Hess wrote: > On 2. Mrz 2006, at 00:19 Uhr, Lisa Dusseault wrote: >> CalDAV would presumably require support for class 1 and class 3, >> but not class 2. This would mean that the server is compliant >> with RFC2518bis requirements (the class 3 part), that it is >> backward compatible with RFC2518 clients (the class 1 part) > > Being lazy reading specs :-), so - Could you summarize the > practical differences between class 1 and 3? I've never heard about > class-3 before ;-| > > Thanks, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D4B757F5B4; Wed, 1 Mar 2006 15:27:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C65331422BA; Wed, 1 Mar 2006 15:27:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01915-02; Wed, 1 Mar 2006 15:27:24 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4FA2A1422B8; Wed, 1 Mar 2006 15:27:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 283EB3CECBA; Thu, 2 Mar 2006 00:25:59 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 8F3063CEC4E; Thu, 2 Mar 2006 00:25:58 +0100 (CET) In-Reply-To: References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Thu, 2 Mar 2006 00:27:11 +0100 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) 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, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:27:25 -0000 On 2. Mrz 2006, at 00:19 Uhr, Lisa Dusseault wrote: > CalDAV would presumably require support for class 1 and class 3, > but not class 2. This would mean that the server is compliant with > RFC2518bis requirements (the class 3 part), that it is backward > compatible with RFC2518 clients (the class 1 part) Being lazy reading specs :-), so - Could you summarize the practical differences between class 1 and 3? I've never heard about class-3 before ;-| Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 438407F4D6 for ; Wed, 1 Mar 2006 15:19:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F7BB1422BA for ; Wed, 1 Mar 2006 15:19:27 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17053-06; Wed, 1 Mar 2006 15:19:26 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 29F0F1422B7; Wed, 1 Mar 2006 15:19:26 -0800 (PST) In-Reply-To: <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Wed, 1 Mar 2006 15:19:09 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Wed, 01 Mar 2006 23:19:27 -0000 Heh, we worried this would be a point of confusion. CalDAV would presumably require support for class 1 and class 3, but not class 2. This would mean that the server is compliant with RFC2518bis requirements (the class 3 part), that it is backward compatible with RFC2518 clients (the class 1 part), and it may or may not support locking (depending on whether class 2 is advertised). Lisa On Mar 1, 2006, at 3:12 PM, Helge Hess wrote: > On 1. Mrz 2006, at 15:46 Uhr, Julian Reschke wrote: >> one important question here is whether CalDav servers can rely on >> their clients speaking WebDAV class 3, and whether CalDav clients >> can rely on CalDAV servers being class 3 compliant. If this is not >> the case, both sides will be harder to implement, because of >> incompatible changes in RFC2518bis (see > Archives/Public/w3c-dist-auth/2006JanMar/0670.html>). > > Sorry if this is a stupid question, but the link you give talks > about LOCKs. Does this mean that "just" class-2 has changed and > class-1 is as is? I would assume that most CalDAV clients talk > class-1 (actually thats all which is required by CalDAV), so this > shouldn't be an issue? > > Thanks, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > 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 7C4B77F4D6 for ; Wed, 1 Mar 2006 15:12:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6580F1422B8 for ; Wed, 1 Mar 2006 15:12:32 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32352-03 for ; Wed, 1 Mar 2006 15:12:32 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA63C1422B7 for ; Wed, 1 Mar 2006 15:12:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E406A3CEC8A; Thu, 2 Mar 2006 00:11:05 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 86D103CE9F7; Thu, 2 Mar 2006 00:11:05 +0100 (CET) In-Reply-To: <4405B3DB.4000003@gmx.de> References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11CE1873-67B9-4199-99E5-64E13BC776B3@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Thu, 2 Mar 2006 00:12:19 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:12:32 -0000 On 1. Mrz 2006, at 15:46 Uhr, Julian Reschke wrote: > one important question here is whether CalDav servers can rely on > their clients speaking WebDAV class 3, and whether CalDav clients > can rely on CalDAV servers being class 3 compliant. If this is not > the case, both sides will be harder to implement, because of > incompatible changes in RFC2518bis (see Archives/Public/w3c-dist-auth/2006JanMar/0670.html>). Sorry if this is a stupid question, but the link you give talks about LOCKs. Does this mean that "just" class-2 has changed and class-1 is as is? I would assume that most CalDAV clients talk class-1 (actually thats all which is required by CalDAV), so this shouldn't be an issue? Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F7187F5F1 for ; Wed, 1 Mar 2006 08:38:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E7F61422B1 for ; Wed, 1 Mar 2006 08:38:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25528-06; Wed, 1 Mar 2006 08:38:04 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7948F1422A6; Wed, 1 Mar 2006 08:38:03 -0800 (PST) In-Reply-To: <4405B3DB.4000003@gmx.de> References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> <4405B3DB.4000003@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A28BD1A-1C22-4E51-B82A-CD270A8A404A@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call Date: Wed, 1 Mar 2006 08:37:46 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 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: Wed, 01 Mar 2006 16:38:04 -0000 I think Julian's proposing that CalDAV build on RFC2518bis, not RFC2518, and I agree. The improvements are all very carefully considered for improving interoperability and maintaining backward- compatibility, and many are applicable to CalDAV. It's not a big cost for existing servers or clients to upgrade from RFC2518 compliance to RFC2518bis compliance (in particular existing clients should incur zero or very small costs), and there's a sizable benefit to those implementing WebDAV for the first time. In the long run existing servers or clients also derive benefit from less ambiguous interoperability with new entrants. Lisa On Mar 1, 2006, at 6:46 AM, Julian Reschke wrote: > Bernard Desruisseaux wrote: >> ... >> Lisa, Cyrus and I already discussed about the possibility of making >> reference to RFC2518bis. We will consider your feedback on this >> issue. >> ... > > Bernard, > > one important question here is whether CalDav servers can rely on > their clients speaking WebDAV class 3, and whether CalDav clients > can rely on CalDAV servers being class 3 compliant. If this is not > the case, both sides will be harder to implement, because of > incompatible changes in RFC2518bis (see Archives/Public/w3c-dist-auth/2006JanMar/0670.html>). > > 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 BC4147F5D9 for ; Wed, 1 Mar 2006 06:48:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AD397142293 for ; Wed, 1 Mar 2006 06:48:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29917-02 for ; Wed, 1 Mar 2006 06:48:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id D9DEC14228A for ; Wed, 1 Mar 2006 06:47:59 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2006 14:47:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 01 Mar 2006 15:47:57 +0100 X-Authenticated: #1915285 Message-ID: <4405B3DB.4000003@gmx.de> Date: Wed, 01 Mar 2006 15:46:51 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Desruisseaux References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> In-Reply-To: <43FDCDC3.3000004@oracle.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.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call 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, 01 Mar 2006 14:48:00 -0000 Bernard Desruisseaux wrote: > ... > Lisa, Cyrus and I already discussed about the possibility of making > reference to RFC2518bis. We will consider your feedback on this issue. > ... Bernard, one important question here is whether CalDav servers can rely on their clients speaking WebDAV class 3, and whether CalDav clients can rely on CalDAV servers being class 3 compliant. If this is not the case, both sides will be harder to implement, because of incompatible changes in RFC2518bis (see ). Best regards, Julian