X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SNrJaZ007255 for ; Fri, 28 Jan 2005 15:53:20 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 8032B2D0CFA for ; Sat, 29 Jan 2005 00:53:10 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 2D3602D0C96 for ; Sat, 29 Jan 2005 00:53:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <41FACCE1.2070703@mozilla.org> References: <41F99422.7040906@mozilla.org> <41F9FD3A.4020608@gmx.de> <41FACCE1.2070703@mozilla.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings Date: Sat, 29 Jan 2005 00:53:12 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 28 Jan 2005 23:53:23 -0000 On 29. Jan 2005, at 00:38 Uhr, Dan Mosedale wrote: > In my mind, the issue is not a matter of optimization, but of readable > code. But isn't that the same reason why dashes are used in the protocol? XML is supposed to be human readable/writable for various reasons and slashes help with that. > My experience has been that less readable code tends to have more > bugs. As you point out, it's too late to fix existing cases of this > in WebDAV itself, but by changing the new CalDAV-specific elements, we > can at least avoid making the problem worse. If we do this, then > implementors end up having fewer code statements that need to use > hard-to-read escape syntaxes. This should lead, I suspect, to at > least slightly less buggy code in the CalDAV implementations written > in such environments, which is good for the community as a whole. It makes it easier for your specific implementation of the XML parser which may or may not be a worthwhile reason (IMHO its not). Personally I would assume that your XML parser could be easily enhanced to escape dashes with eg underlines prior calling back to the application? Since dashes are regular XML, I would assume that this should be in the parser anyway? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: dmose@mozilla.org X-Envelope-To: Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SNcVaZ006145 for ; Fri, 28 Jan 2005 15:38:31 -0800 Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id j0SNcFV1026093; Fri, 28 Jan 2005 15:38:15 -0800 (PST) (envelope-from dmose@mozilla.org) Received: from [192.168.1.137] (ppp-69-233-165-142.dsl.pltn13.pacbell.net [69.233.165.142]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j0SNc3Sw031877; Fri, 28 Jan 2005 15:38:04 -0800 (PST) (envelope-from dmose@mozilla.org) Message-ID: <41FACCE1.2070703@mozilla.org> Date: Fri, 28 Jan 2005 15:38:09 -0800 From: Dan Mosedale User-Agent: Mozilla Thunderbird 0.6+ (X11/20041214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings References: <41F99422.7040906@mozilla.org> <41F9FD3A.4020608@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 28 Jan 2005 23:38:33 -0000 Cyrus Daboo wrote: > --On January 28, 2005 9:52:10 AM +0100 Julian Reschke > wrote: > >>> Would people be amenable to replacing hyphenated element names in >>> CalDAV >>> with non-hyphenated ones, assuming suitably clear ones could be found >>> and agreed upon? >> >> >> I sympathize with the issue, but hyphen-as-a-separator is almost is a >> common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even >> if you get a small optimization here, you'll be likely to hit similar >> issues with other XML names in WebDAV in the future. So: you may have to >> live with it. If it's no showstopper... >> > > The WebDAV ACL spec uses '-' in several places for XML elements (ones > which a CalDAV client that wants to do calendar sharing would have to > handle), so I am afraid there is really no way of getting around this > problem. Both DASL AND DeltaV use '-' in a number of places too, > though those aren't required for CalDAV. > In my mind, the issue is not a matter of optimization, but of readable code. My experience has been that less readable code tends to have more bugs. As you point out, it's too late to fix existing cases of this in WebDAV itself, but by changing the new CalDAV-specific elements, we can at least avoid making the problem worse. If we do this, then implementors end up having fewer code statements that need to use hard-to-read escape syntaxes. This should lead, I suspect, to at least slightly less buggy code in the CalDAV implementations written in such environments, which is good for the community as a whole. Dan X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SFkdaa001555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Jan 2005 07:46:40 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0SFeD6E002907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2005 10:40:14 -0500 Date: Fri, 28 Jan 2005 10:46:34 -0500 From: Cyrus Daboo To: Julian Reschke , Dan Mosedale Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings Message-ID: In-Reply-To: <41F9FD3A.4020608@gmx.de> References: <41F99422.7040906@mozilla.org> <41F9FD3A.4020608@gmx.de> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 28 Jan 2005 15:46:43 -0000 Hi Julian, --On January 28, 2005 9:52:10 AM +0100 Julian Reschke wrote: >> Would people be amenable to replacing hyphenated element names in CalDAV >> with non-hyphenated ones, assuming suitably clear ones could be found >> and agreed upon? > > I sympathize with the issue, but hyphen-as-a-separator is almost is a > common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even > if you get a small optimization here, you'll be likely to hit similar > issues with other XML names in WebDAV in the future. So: you may have to > live with it. If it's no showstopper... > The WebDAV ACL spec uses '-' in several places for XML elements (ones which a CalDAV client that wants to do calendar sharing would have to handle), so I am afraid there is really no way of getting around this problem. Both DASL AND DeltaV use '-' in a number of places too, though those aren't required for CalDAV. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0S8qNaZ007032 for ; Fri, 28 Jan 2005 00:52:24 -0800 Received: (qmail invoked by alias); 28 Jan 2005 08:52:18 -0000 Received: from pD9E510B9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.185) by mail.gmx.net (mp024) with SMTP; 28 Jan 2005 09:52:18 +0100 X-Authenticated: #1915285 Message-ID: <41F9FD3A.4020608@gmx.de> Date: Fri, 28 Jan 2005 09:52:10 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Mosedale Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings References: <41F99422.7040906@mozilla.org> In-Reply-To: <41F99422.7040906@mozilla.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 28 Jan 2005 08:52:27 -0000 Dan Mosedale wrote: > ... > Would people be amenable to replacing hyphenated element names in CalDAV > with non-hyphenated ones, assuming suitably clear ones could be found > and agreed upon? I sympathize with the issue, but hyphen-as-a-separator is almost is a common usage pattern in WebDAV (see RFC3253, RFC3648, RFC3744). So even if you get a small optimization here, you'll be likely to hit similar issues with other XML names in WebDAV in the future. So: you may have to live with it. If it's no showstopper... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: dmose@mozilla.org X-Envelope-To: Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S1O1aZ008969 for ; Thu, 27 Jan 2005 17:24:01 -0800 Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id j0S1O0V1091749 for ; Thu, 27 Jan 2005 17:24:00 -0800 (PST) (envelope-from dmose@mozilla.org) Received: from [192.168.1.137] (ppp-69-233-165-142.dsl.pltn13.pacbell.net [69.233.165.142]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j0S1Nih3013445 for ; Thu, 27 Jan 2005 17:23:45 -0800 (PST) (envelope-from dmose@mozilla.org) Message-ID: <41F99422.7040906@mozilla.org> Date: Thu, 27 Jan 2005 17:23:46 -0800 From: Dan Mosedale User-Agent: Mozilla Thunderbird 0.6+ (X11/20041214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] hyphens in element names problematic for XML language bindings X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 28 Jan 2005 01:24:06 -0000 A lot of Mozilla's CalDAV implementation is written using E4X, which is a way to very conveniently handle XML data from JavaSript (see for a quick intro). E4X appears to be getting a good reception, and after I've spent a bunch of time coding with it, I can see why; it's very convenient. Various other languages seem to want in on the XML language-binding fun: and . CalDAV's current use of hyphens in XML element names cause a problem: most languages parse a hyphen as the minus operator, and therefore as a separate token. This means that the parser has no way to disambiguate whether the user is attempting to subtract two different objects or simply access one. So in order to use native bindings with any such elements in JS, I have to use an explicit namespacing syntax. For example: var C = new Namespace("urn:ietf:params:xml:ns:caldav") default xml namespace = C; var queryXml = ; queryXml[0].C::filter.C::["icalcomp-filter"] .C::["icalcomp-filter"].@name = "VEVENT"; Note that it's not easy to read, at a glance, exactly what's going on in the last assignment statement. If, for the sake of this example, icalcomp-filter were simply named compfilter, the final assignment could be written as: queryXml[0].filter.compfilter.compfilter.@name = "VEVENT"; which is significantly clearer to the reader. Assuming that native-XML bindings catch on, which seems pretty likely to me, I suspect that most implementors working with it are going to have to use similar obfuscating quoting hacks. Would people be amenable to replacing hyphenated element names in CalDAV with non-hyphenated ones, assuming suitably clear ones could be found and agreed upon? Dan X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJkuaa018457 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Jan 2005 11:46:58 -0800 In-Reply-To: References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 11:46:45 -0800 To: Helge Hess X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 19:47:00 -0000 > Anyway, you asked for comments and you got mine ;-) > > I'm not trying to tell or argue how someone should implement locks or > groupware servers, I'm just raising an issue which will hurt a lot of > existing OpenSource groupware servers due the legacy design. Feel free > to ignore ;-) > Yes, thank-you, and we certainly won't ignore your comments. I was glad you were willing to drill down a little on your feedback, that helps me understand. Lisa X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJcsaZ017703 for ; Tue, 25 Jan 2005 11:38:54 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 2E6722CF46F for ; Tue, 25 Jan 2005 20:38:39 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id C43C12CF45D for ; Tue, 25 Jan 2005 20:38:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 20:38:16 +0100 To: ietf-caldav DevList X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 19:38:56 -0000 On 25. Jan 2005, at 20:23 Uhr, Lisa Dusseault wrote: > So in order to add locking in this environment, can you add a "check > the lock table and respect it" function to each of the loadable > modules? Basically yes. Though locking is very invasive, eg all user interfaces will need to have support for pessimstic locking as well! > (Yes I understand that's more work but I'm trying to find out if there > are more barriers I'm unaware of) So for example, the Web UI would > have to have new logic to respect locks, although it wouldn't > necessarily have to have additional logic to create locks. It could > also have additional logic, if you wanted to get fancy, to have the > owner of a resource blow away a dead or inappropriate lock. Yes, I'm not saying its impossible. But its seems to be so much work to me that it probably isn't worth the effort (for us). We would only supports locks in the WebDAV daemon and accept possible loss of information when used from other clients. > As an aside, another feasible architecture that handles locks > (although too late for many existing systems) is to have the WebUI go > through a WebDAV interface on its way to the database. This might be feasable if you write a new system from scratch. Though I still doubt that it would make a lot of sense to go through WebDAV if the web interface is running on the same machine (if you write from scratch, you can just check the lock table as you outlined). > This could be a WebDAV-aware API that enforced locks, or it could > literally be that the Web application formulates WebDAV requests > instead of SQL requests. Getting PROPFIND results in XML makes it > rather easy to produce HTML listings. Yes, this would be interesting to explore. But I think a "Logic layer" build with WebDAV in mind would make more sense, the additional overhead of HTTP in between might be a bit overly expensive compared to direct access to the RDBMS which already deal with multiuser/locking issues extremely well. Anyway, you asked for comments and you got mine ;-) I'm not trying to tell or argue how someone should implement locks or groupware servers, I'm just raising an issue which will hurt a lot of existing OpenSource groupware servers due the legacy design. Feel free to ignore ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJQBaZ016287 for ; Tue, 25 Jan 2005 11:26:11 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D678A2CF3F4 for ; Tue, 25 Jan 2005 20:25:55 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 867712CF403 for ; Tue, 25 Jan 2005 20:25:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F69B80.70901@cse.ucsc.edu> References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> <41F69B80.70901@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 20:25:33 +0100 To: ietf-caldav DevList X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 19:26:12 -0000 On 25. Jan 2005, at 20:18 Uhr, Elias Sinderson wrote: > Regarding the notion that other interfaces will be used to access a > (DB) repository, one should be very careful. It is astonishingly easy > to break things in this fashion (e.g. when a given client does not > respect the data model that is enforced at the application protocol > level). Nope, it isn't. Actually its a primary reason why one would use a RDBMS system, ACID, right? ;-) Anyway, as mentioned the daemons do implement the same application logic in the OGo case, so the same access behaviour is ensured. Though this probably won't hold true for a lot of other servers (and it doesn't have to if the database schema is properly setup). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJNxaa016052 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Jan 2005 11:23:59 -0800 In-Reply-To: References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 11:23:51 -0800 To: Helge Hess X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 19:24:01 -0000 Yes, I think I do see your point. I am guessing that in these cases the modules that access the database is where the application intelligence lives, and the database backend is a vanilla database with no special logic based on the contents of the tables. So in order to add locking in this environment, can you add a "check the lock table and respect it" function to each of the loadable modules? (Yes I understand that's more work but I'm trying to find out if there are more barriers I'm unaware of) So for example, the Web UI would have to have new logic to respect locks, although it wouldn't necessarily have to have additional logic to create locks. It could also have additional logic, if you wanted to get fancy, to have the owner of a resource blow away a dead or inappropriate lock. As an aside, another feasible architecture that handles locks (although too late for many existing systems) is to have the WebUI go through a WebDAV interface on its way to the database. This could be a WebDAV-aware API that enforced locks, or it could literally be that the Web application formulates WebDAV requests instead of SQL requests. Getting PROPFIND results in XML makes it rather easy to produce HTML listings. Lisa On Jan 25, 2005, at 11:11 AM, Helge Hess wrote: > Hi Lisa, > > On 25. Jan 2005, at 19:29 Uhr, Lisa Dusseault wrote: >> I've implemented a WebDAV server with a DB backend before, and that's >> not how I'd recommend doing it :) > > I think you misunderstood me. I assume CalDAV will be implemented as > an add on to the server. For example the existing web interface will > still used the DB backend directly without going through CalDAV or > being aware of WebDAV locking. > >> One way is to add a table of lock tokens and locked URIs (along with >> other information about lock, like owner). So the server's first >> transaction on receiving a LOCK would be to add an entry to this >> table. Close transaction, reply to LOCK. > > Everything correct :-) But still the *existing functionality* won't > magically use that locking table and adding that kind of WebDAV > specific locking support is quite a major change (and one which > certainly wouldn't be done in OGo, we would just live with possible > overwrites then, its too invasive). > >> Slide already does something like this and it's open source, so I >> fail to see the connection to why this is a hard requirement for open >> source. > > I was thinking in the context of available OpenSource groupware > servers which want to add CalDAV connectivity, like phpGroupware or > OpenGroupware.org of course (or one of the other 200 servers listed in > Freshmeat). Most of those servers are RDBMS based and usually come > from a web interface background. > > Of course pure WebDAV storage servers (like Slide) won't have this > issue since WebDAV is the only way to access them. > > Consider: > > http://www.opengroupware.org/en/devs/docs/OGoArchitecture.png > > the functionality is implemented as loadable modules and will be > loaded in each of the five different daemons, so it only needs to be > implemented once. But each of the daemons connects to the database > separatly and there is no concept of locks, except the one provided by > RDBMS transactions. > > Most other servers won't even reuse the functionality in their > frontends. > > See my point? > > Greets, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: elias@cse.ucsc.edu X-Envelope-To: Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJIPaZ015594 for ; Tue, 25 Jan 2005 11:18:25 -0800 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0PJIOP03721 for ; Tue, 25 Jan 2005 11:18:24 -0800 (PST) Message-ID: <41F69B80.70901@cse.ucsc.edu> Date: Tue, 25 Jan 2005 11:18:24 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav DevList Subject: Re: [Ietf-caldav] Whether to require locks References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> In-Reply-To: <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-caldav DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 19:18:27 -0000 I'll second Lisas' comments below and add that the approach she outlines is very similar to that taken by the Catacomb backend for mod_dav. Locking did not present a great deal of difficulty to implement relative to other WebDAV features. Regarding the notion that other interfaces will be used to access a (DB) repository, one should be very careful. It is astonishingly easy to break things in this fashion (e.g. when a given client does not respect the data model that is enforced at the application protocol level). Cheers, Elias Lisa Dusseault wrote: > I've implemented a WebDAV server with a DB backend before, and that's > not how I'd recommend doing it :) > > One way is to add a table of lock tokens and locked URIs (along with > other information about lock, like owner). So the server's first > transaction on receiving a LOCK would be to add an entry to this > table. Close transaction, reply to LOCK. > > Then let's say the server receives a PUT request. Before applying the > PUT, the server must check to see if it's locked, and if it's locked > that the correct lock token was provided by the correct principal. > Then make the change in transaction #2, close transaction, reply to PUT. > > Finally, the server receives UNLOCK. Remove the lock info in > transaction #3, close transaction, reply to UNLOCK. > > Slide already does something like this and it's open source, so I fail > to see the connection to why this is a hard requirement for open source. > > Lisa > > On Jan 25, 2005, at 10:18 AM, Helge Hess wrote: > >> On Jan 25, 2005, at 19:11, Lisa Dusseault wrote: >> >>> From server implementors, it would be good to know if you were >>> already planning on supporting locking or would find it onerous. >> >> >> I think for most OpenSource servers this would be a rather hard >> requirement since WebDAV won't be the only interface which accesses >> the database. >> >> So the assumption that an event can be locked would be limited to the >> WebDAV interface and you can hardly keep the transaction open for the >> whole locking time in RDBMS servers to ensure that no modifications >> are done by different (server) frontends. >> >> Greets, >> Helge > X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PJCUaZ014867 for ; Tue, 25 Jan 2005 11:12:31 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id AFFED2CEB66 for ; Tue, 25 Jan 2005 20:12:15 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 47FC62CE524 for ; Tue, 25 Jan 2005 20:12:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 20:11:52 +0100 To: ietf-caldav DevList X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 19:12:33 -0000 Hi Lisa, On 25. Jan 2005, at 19:29 Uhr, Lisa Dusseault wrote: > I've implemented a WebDAV server with a DB backend before, and that's > not how I'd recommend doing it :) I think you misunderstood me. I assume CalDAV will be implemented as an add on to the server. For example the existing web interface will still used the DB backend directly without going through CalDAV or being aware of WebDAV locking. > One way is to add a table of lock tokens and locked URIs (along with > other information about lock, like owner). So the server's first > transaction on receiving a LOCK would be to add an entry to this > table. Close transaction, reply to LOCK. Everything correct :-) But still the *existing functionality* won't magically use that locking table and adding that kind of WebDAV specific locking support is quite a major change (and one which certainly wouldn't be done in OGo, we would just live with possible overwrites then, its too invasive). > Slide already does something like this and it's open source, so I fail > to see the connection to why this is a hard requirement for open > source. I was thinking in the context of available OpenSource groupware servers which want to add CalDAV connectivity, like phpGroupware or OpenGroupware.org of course (or one of the other 200 servers listed in Freshmeat). Most of those servers are RDBMS based and usually come from a web interface background. Of course pure WebDAV storage servers (like Slide) won't have this issue since WebDAV is the only way to access them. Consider: http://www.opengroupware.org/en/devs/docs/OGoArchitecture.png the functionality is implemented as loadable modules and will be loaded in each of the five different daemons, so it only needs to be implemented once. But each of the daemons connects to the database separatly and there is no concept of locks, except the one provided by RDBMS transactions. Most other servers won't even reuse the functionality in their frontends. See my point? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PITkaa010117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Jan 2005 10:29:46 -0800 In-Reply-To: <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <134942E5-6EFF-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 10:29:40 -0800 To: Helge Hess X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 18:29:47 -0000 I've implemented a WebDAV server with a DB backend before, and that's not how I'd recommend doing it :) One way is to add a table of lock tokens and locked URIs (along with other information about lock, like owner). So the server's first transaction on receiving a LOCK would be to add an entry to this table. Close transaction, reply to LOCK. Then let's say the server receives a PUT request. Before applying the PUT, the server must check to see if it's locked, and if it's locked that the correct lock token was provided by the correct principal. Then make the change in transaction #2, close transaction, reply to PUT. Finally, the server receives UNLOCK. Remove the lock info in transaction #3, close transaction, reply to UNLOCK. Slide already does something like this and it's open source, so I fail to see the connection to why this is a hard requirement for open source. Lisa On Jan 25, 2005, at 10:18 AM, Helge Hess wrote: > On Jan 25, 2005, at 19:11, Lisa Dusseault wrote: >> From server implementors, it would be good to know if you were >> already planning on supporting locking or would find it onerous. > > I think for most OpenSource servers this would be a rather hard > requirement since WebDAV won't be the only interface which accesses > the database. > > So the assumption that an event can be locked would be limited to the > WebDAV interface and you can hardly keep the transaction open for the > whole locking time in RDBMS servers to ensure that no modifications > are done by different (server) frontends. > > Greets, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PIJ4aZ009313 for ; Tue, 25 Jan 2005 10:19:04 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 52AC82CF320 for ; Tue, 25 Jan 2005 19:18:48 +0100 (CET) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 140E229DE22 for ; Tue, 25 Jan 2005 19:18:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> References: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <950793F8-6EFD-11D9-ACCF-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Whether to require locks Date: Tue, 25 Jan 2005 19:18:59 +0100 To: ietf-caldav DevList X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 18:19:06 -0000 On Jan 25, 2005, at 19:11, Lisa Dusseault wrote: > From server implementors, it would be good to know if you were already > planning on supporting locking or would find it onerous. I think for most OpenSource servers this would be a rather hard requirement since WebDAV won't be the only interface which accesses the database. So the assumption that an event can be locked would be limited to the WebDAV interface and you can hardly keep the transaction open for the whole locking time in RDBMS servers to ensure that no modifications are done by different (server) frontends. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0PIBgaa008559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 25 Jan 2005 10:11:43 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <8D47FD15-6EFC-11D9-81EE-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-caldav DevList From: Lisa Dusseault Date: Tue, 25 Jan 2005 10:11:36 -0800 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Whether to require locks X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 Jan 2005 18:11:44 -0000 Cyrus & Bernard & I discussed recently whether to require locking support in CalDAV servers, and we thought it would be good to get implementor feedback. Strawman proposal: one approach is to require something less complicated than full WebDAV locking. - CalDAV servers MUST support WebDAV locking on individual resources. - CalDAV servers [MUST or MAY?] support WebDAV locking on collections - CalDAV servers MUST allow the LOCK method to work on an unmapped URL, but SHOULD simply create a locked empty resource rather than a special "null resource" [1] The obvious drawback to requiring even minimal locking support means that CalDAV is more work for servers, particularly servers which have an existing installed base to support through some proprietary protocol which does not involve locking. The advantages are kind of scattered, and it depends on the client implementation and user model. We certainly can't gaurantee that all clients will use locking because they certainly don't have to and simple clients probably won't. Overall, we don't know exactly what benefit each client might get from locking so it's kind of hard to evaluate that against the more certain cost of requiring each server to implement. But we know from standards-deployment experience that unless most server implementations support a feature, most clients won't bother to use it -- the value to the client of using a feature like locking goes way down if the client can't rely on the feature being available and if the client must have a "plan B" anyway then why not abandon plan A. Still, we can talk about some of the things clients might do: - It can be frustrating to users to start editing an event that hasn't changed, and then before finishing their edits, the event is changed by somebody else. To avoid this, a client might lock the event with a short-term lock while it's open in an editing window, and unlock when the user is finished or moves to another event without making changes. - One way of dealing with the need to create a new event with a new name would be to send a LOCK request. If the request comes back saying that an existing resource was created the client can UNLOCK it and try again to choose a unique name without harm done. OTOH if the request comes back with "201 Created" status code, then the client knows that it did choose a new URL successfully, and can PUT and PROPPATCH the event. - Some clients might put metadata in the properties. If that metadata is supposed to be consistent with the event body, then the client might LOCK the resource before doing PUT and PROPPATCH to increase the chances that both write requests can be done together and keep the resource consistent. - Chandler is thinking about tying events and tasks together -- a task which is also an event, it has reminders and "doneness", and start and end time, all in one object. We might choose for best interoperability to represent this as a separate VTODO and VEVENT -- two resources with a custom property to link them together. Chandler might want to LOCK both of those resources in order to be confident of being able to change each of them, when our local Event+Task is changed. (We're also considering doing this kind of combination with emails, in extension of the typical flagged-to-do email example, which would require a server that supported not only CalDAV and possibly locking but also had a general file sharing space for sharing Email+Task objects.) Thoughts? From client implementors, it would be good to know if you envision use cases for locks. From server implementors, it would be good to know if you were already planning on supporting locking or would find it onerous. Lisa [1] Note that WebDAV originally required locked null resources -- this was a special kind of resource that showed up in listings but disappeared whenever the lock expired, and this special kind of resource could only support certain methods. Interoperability testing showed that this wasn't necessary, it's actually quite OK for servers to accept a LOCK request to an unmapped URL by creating an empty, locked resource. Some servers already support LOCK to an unmapped URL in exactly that manner. In these interoperability tests and subsequent meetings, we agreed that when WebDAV went to Draft Standard, it should simplify locking by removing the concept of special "lock null resources" and instead replace them with ordinary, but empty, locked resources. X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0NA5caZ014908 for ; Sun, 23 Jan 2005 02:05:39 -0800 Received: (qmail invoked by alias); 23 Jan 2005 10:05:32 -0000 Received: from pD953573C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.60) by mail.gmx.net (mp020) with SMTP; 23 Jan 2005 11:05:32 +0100 X-Authenticated: #1915285 Message-ID: <41F376E1.9060204@gmx.de> Date: Sun, 23 Jan 2005 11:05:21 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Carr Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> <5AFAD3854AA2D907E36AE162@ninevah.local> <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> <41F2A466.6080301@gmx.de> <37322.69.17.124.67.1106438716.squirrel@69.17.124.67> In-Reply-To: <37322.69.17.124.67.1106438716.squirrel@69.17.124.67> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2005 10:05:42 -0000 Scott Carr wrote: > Julian Reschke said: > >>You're not wrong, just inprecise. Any WebDAV server by definition is an >>HTTP server, so you can't have something that does WebDAV but not the >>base HTTP spec. >> >>In this particular case, the question probably is whether software that >>is based on or extends Apache/moddav will be able to do it's own POST >>processing. I'd be surprised if the answer was "no", but that's >>something to be checked... > > > Ok. That is what I thought. I know we won't be removing POST from the > mix. What I was wondering is how would the server be able to > differentiate from a standard POST request, and a CalDav POST request, if > we went with this method. If what you call a "standard POST" is whst browser usually do, you can distinguish this by the Content-Type header. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from progbits.com (www.progbits.com [69.17.124.65]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0N05PaZ023550 for ; Sat, 22 Jan 2005 16:05:25 -0800 Received: from mail.progbits.com (localhost [127.0.0.1]) by progbits.com (Postfix) with ESMTP id 04858446BDD; Sat, 22 Jan 2005 18:05:15 -0600 (CST) Received: from 69.17.124.67 (SquirrelMail authenticated user scarr); by mail.progbits.com with HTTP; Sat, 22 Jan 2005 18:05:16 -0600 (CST) Message-ID: <37322.69.17.124.67.1106438716.squirrel@69.17.124.67> In-Reply-To: <41F2A466.6080301@gmx.de> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> <5AFAD3854AA2D907E36AE162@ninevah.local> <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> <41F2A466.6080301@gmx.de> Date: Sat, 22 Jan 2005 18:05:16 -0600 (CST) Subject: Re: [Ietf-caldav] Creating Items [ideas] From: "Scott Carr" To: ietf-caldav@osafoundation.org User-Agent: SquirrelMail/1.4.3-RC1 X-Mailer: SquirrelMail/1.4.3-RC1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2005 00:05:26 -0000 Julian Reschke said: > You're not wrong, just inprecise. Any WebDAV server by definition is an > HTTP server, so you can't have something that does WebDAV but not the > base HTTP spec. > > In this particular case, the question probably is whether software that > is based on or extends Apache/moddav will be able to do it's own POST > processing. I'd be surprised if the answer was "no", but that's > something to be checked... Ok. That is what I thought. I know we won't be removing POST from the mix. What I was wondering is how would the server be able to differentiate from a standard POST request, and a CalDav POST request, if we went with this method. -- Scott Carr OpenOffice.org Documentation Co-Lead X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0MNxPaZ023116 for ; Sat, 22 Jan 2005 15:59:25 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 1CAB82CE743 for ; Sun, 23 Jan 2005 00:59:08 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 8590A2CE758 for ; Sun, 23 Jan 2005 00:59:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <76f0ff970501221522420fa57e@mail.google.com> References: <41F03EAC.4060108@progbits.com> <76f0ff970501221522420fa57e@mail.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8FE221F1-6CD1-11D9-8107-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Sun, 23 Jan 2005 00:58:50 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 22 Jan 2005 23:59:27 -0000 On 23. Jan 2005, at 00:22 Uhr, Neal Gafter wrote: > I don't see why there is any problem for the client to select a unique > resource name for a calendar entry. The client already has a unique > name - the VEVENT's UID. I suggest we simply require that the > resource's name be the event's UID. That doesn't really resolve the issue discussed since the same problem applies for VEVENT UIDs. But I suppose there seems agreement by majority that server maintained identity is not being supported by CalDAV and its certainly problematic for iCal UIDs. I do agree that it might make a lot of sense to require CalDAV servers/clients to keep UID and relative URL consistent. Is there anything which speaks against that? I suppose it would make both, servers and clients easier. One thing which wouldn't work is dropping an existing ICS file (with some arbitary name) into a CalDAV collection using a generic WebDAV client. This would need to get rejected by the server (or redirected or 'relocated' to the contained UID). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: gafter+cb1019cbba0b037050@google.com X-Envelope-To: Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0MNMMaZ022029 for ; Sat, 22 Jan 2005 15:22:22 -0800 Received: by 216-239-45-4.google.com with SMTP id 8so1441zzb for ; Sat, 22 Jan 2005 15:23:30 -0800 (PST) Received: by 172.25.12.96 with SMTP id 16mr67977zzb; Sat, 22 Jan 2005 15:22:17 -0800 (PST) Received: by 172.25.12.175 with HTTP; Sat, 22 Jan 2005 15:22:17 -0800 (PST) Message-ID: <76f0ff970501221522420fa57e@mail.google.com> Date: Sat, 22 Jan 2005 15:22:17 -0800 From: Neal Gafter To: Scott Carr Subject: Re: [Ietf-caldav] Creating Items [ideas] In-Reply-To: <41F03EAC.4060108@progbits.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F03EAC.4060108@progbits.com> X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Neal Gafter 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, 22 Jan 2005 23:22:27 -0000 I don't see why there is any problem for the client to select a unique resource name for a calendar entry. The client already has a unique name - the VEVENT's UID. I suggest we simply require that the resource's name be the event's UID. X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0MJ9raa009111 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 22 Jan 2005 11:09:55 -0800 In-Reply-To: <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> <5AFAD3854AA2D907E36AE162@ninevah.local> <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2D68D360-6CA9-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Sat, 22 Jan 2005 11:09:45 -0800 To: "Scott Carr" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 22 Jan 2005 19:09:56 -0000 > > I understand that we will need to modify the server to support the > CalDav > extensions. My point about this was what if the server is supposed to > take care of CalDav and regular HTTP requests on the same folder. This > would be difficult to setup, wouldn't it? It might be OK for CalDAV to change the meaning of POST on a resource, as long as the Web server can be modified that way. Since the HTTP 1.1 specification doesn't require POST to have any specific behavior on any given resource, in theory an extension to HTTP can define POST's behavior on certain resources. And you say "if the server is supposed to take care of CalDAV and HTTP requests on the same folder" -- that might indicate some misunderstanding-- since CalDAV extends HTTP, a CalDAV server MUST handle HTTP requests on all CalDAV resources. > > I'll read over the WebDav spec a little more, but I thought the idea of > WebDav was that you could support both WebDav and HTTP on the same > folders... Yes you MUST support WebDAV and HTTP on the same folder -- that means all the requirements of HTTP (and not necessarily all the extensions and implemenation details of any given HTTP server) > > Please, correct me if I am wrong. > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0MJ7paZ009010 for ; Sat, 22 Jan 2005 11:07:52 -0800 Received: (qmail invoked by alias); 22 Jan 2005 19:07:44 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp009) with SMTP; 22 Jan 2005 20:07:44 +0100 X-Authenticated: #1915285 Message-ID: <41F2A466.6080301@gmx.de> Date: Sat, 22 Jan 2005 20:07:18 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Carr Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> <5AFAD3854AA2D907E36AE162@ninevah.local> <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> In-Reply-To: <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 22 Jan 2005 19:07:55 -0000 Scott Carr wrote: > Cyrus Daboo said: > >>In order to support CalDAV, a WebDAV server is going to have to be >>modified >>to support the new CalDAV features such as custom reports, the calendar >>collection resourcetype and MKCALENDAR (though that method will be >>optional). As such modifying a server to do something special when POST >>occurs on a calendar collection is a reasonable thing to do, so I don't >>think we need to worry about how current servers implement POST - the only >>thing that is important (and this is only from the server implementor's >>point of view, not the protocol point of view per se) is how easy it is to >>hook into the server's processing to do something different with a >>'standard' method like POST. > > > I understand that we will need to modify the server to support the CalDav > extensions. My point about this was what if the server is supposed to > take care of CalDav and regular HTTP requests on the same folder. This > would be difficult to setup, wouldn't it? > > I'll read over the WebDav spec a little more, but I thought the idea of > WebDav was that you could support both WebDav and HTTP on the same > folders... > > Please, correct me if I am wrong. You're not wrong, just inprecise. Any WebDAV server by definition is an HTTP server, so you can't have something that does WebDAV but not the base HTTP spec. In this particular case, the question probably is whether software that is based on or extends Apache/moddav will be able to do it's own POST processing. I'd be surprised if the answer was "no", but that's something to be checked... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from progbits.com (www.progbits.com [69.17.124.65]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0MIfbaZ007848 for ; Sat, 22 Jan 2005 10:41:37 -0800 Received: from mail.progbits.com (localhost [127.0.0.1]) by progbits.com (Postfix) with ESMTP id CDF5A129CE; Sat, 22 Jan 2005 12:41:28 -0600 (CST) Received: from 69.17.124.67 (SquirrelMail authenticated user scarr); by mail.progbits.com with HTTP; Sat, 22 Jan 2005 12:41:28 -0600 (CST) Message-ID: <37287.69.17.124.67.1106419288.squirrel@69.17.124.67> In-Reply-To: <5AFAD3854AA2D907E36AE162@ninevah.local> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> <5AFAD3854AA2D907E36AE162@ninevah.local> Date: Sat, 22 Jan 2005 12:41:28 -0600 (CST) Subject: Re: [Ietf-caldav] Creating Items [ideas] From: "Scott Carr" To: ietf-caldav@osafoundation.org User-Agent: SquirrelMail/1.4.3-RC1 X-Mailer: SquirrelMail/1.4.3-RC1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 22 Jan 2005 18:41:38 -0000 Cyrus Daboo said: > In order to support CalDAV, a WebDAV server is going to have to be > modified > to support the new CalDAV features such as custom reports, the calendar > collection resourcetype and MKCALENDAR (though that method will be > optional). As such modifying a server to do something special when POST > occurs on a calendar collection is a reasonable thing to do, so I don't > think we need to worry about how current servers implement POST - the only > thing that is important (and this is only from the server implementor's > point of view, not the protocol point of view per se) is how easy it is to > hook into the server's processing to do something different with a > 'standard' method like POST. I understand that we will need to modify the server to support the CalDav extensions. My point about this was what if the server is supposed to take care of CalDav and regular HTTP requests on the same folder. This would be difficult to setup, wouldn't it? I'll read over the WebDav spec a little more, but I thought the idea of WebDav was that you could support both WebDav and HTTP on the same folders... Please, correct me if I am wrong. X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0MGv8aa003206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Jan 2005 08:57:11 -0800 Received: from ninevah.cyrusoft.com (pool-151-201-132-44.pitt.east.verizon.net [151.201.132.44]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0MGpX6E003163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jan 2005 11:51:36 -0500 Date: Sat, 22 Jan 2005 11:57:00 -0500 From: Cyrus Daboo To: Scott Carr , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: <5AFAD3854AA2D907E36AE162@ninevah.local> In-Reply-To: <41F14E9F.8040405@progbits.com> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> <41F14E9F.8040405@progbits.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 22 Jan 2005 16:57:14 -0000 Hi Scott, --On January 21, 2005 12:49:03 PM -0600 Scott Carr wrote: >> Typically, POST requests to "live Web Servers" are only handled by >> code that generates dynamic responses if the Request-URI identifies a >> servlet, CGI script, or other code handler. Live Web servers already >> have to handle this distinction. You could test this out by finding a >> Web server that had some static file stored on disk, available via GET >> to an arbitrary URL, and try POST to that URL and see what happens. I >> suspect it would say that the resource doesn't handle POST method. > > Just tried this against Apache 2.0. > > I sent the following request: > > POST /~scarr/test.html HTTP/1.1 > Host: progbits.com > > And it returned back with the test.html content immediately. Granted > this is not a WebDav server, but should it make a difference? > In order to support CalDAV, a WebDAV server is going to have to be modified to support the new CalDAV features such as custom reports, the calendar collection resourcetype and MKCALENDAR (though that method will be optional). As such modifying a server to do something special when POST occurs on a calendar collection is a reasonable thing to do, so I don't think we need to worry about how current servers implement POST - the only thing that is important (and this is only from the server implementor's point of view, not the protocol point of view per se) is how easy it is to hook into the server's processing to do something different with a 'standard' method like POST. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0LL4uaZ011301 for ; Fri, 21 Jan 2005 13:04:57 -0800 Received: (qmail invoked by alias); 21 Jan 2005 21:04:50 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp027) with SMTP; 21 Jan 2005 22:04:50 +0100 X-Authenticated: #1915285 Message-ID: <41F16E6F.3010307@gmx.de> Date: Fri, 21 Jan 2005 22:04:47 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> <41F14D84.7030706@gmx.de> <4883E7CF-6BE1-11D9-A07A-000D936E5072@opengroupware.org> <41F166C3.8070304@gmx.de> <6CE5A20C-6BEE-11D9-A07A-000D936E5072@opengroupware.org> In-Reply-To: <6CE5A20C-6BEE-11D9-A07A-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 21:05:01 -0000 Helge Hess wrote: > On 21. Jan 2005, at 21:32 Uhr, Julian Reschke wrote: > >> Well, you can't say "please don't restart it" and then restart it >> yourself (at least it won't work :-). > > > Argh, sorry ;-) No problem. >> My recommendation is to follow up on the HTTP mailing list and ask for >> advice. That's what it's for. > > > Definitely a good advice. Could you give a pointer to the proper list? I > suppose there are multiple lists? Sure, it's . >... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: dmose@mozilla.org X-Envelope-To: Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LKtKaZ010304 for ; Fri, 21 Jan 2005 12:55:21 -0800 Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id j0LKrVVV064953; Fri, 21 Jan 2005 12:55:17 -0800 (PST) (envelope-from dmose@mozilla.org) Received: from [192.168.1.102] (dsl081-050-187.sfo1.dsl.speakeasy.net [64.81.50.187]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j0LKrIxq053189; Fri, 21 Jan 2005 12:53:20 -0800 (PST) (envelope-from dmose@mozilla.org) Message-ID: <41F16BC6.9030506@mozilla.org> Date: Fri, 21 Jan 2005 12:53:26 -0800 From: Dan Mosedale User-Agent: Mozilla Thunderbird 0.6+ (X11/20041214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 20:55:22 -0000 Cyrus Daboo wrote: > The downside of this of course is that there could be multiple > roundtrips between the client and server when creating to get a unique > URI. However careful choice by the client should ensure this is not a > very common situation. We could even suggest a suitable hashing scheme > in the draft so that co-operating clients from different vendors could > improve their likelihood of avoiding a URI clash like this. At the risk of adding a minor dependency on another draft, perhaps using some form of UUIDs as documented in would do the trick? I believe that draft just moved to Proposed Standard status Dan X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LKrRaZ010158 for ; Fri, 21 Jan 2005 12:53:27 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id EB5082CD45D for ; Fri, 21 Jan 2005 21:53:21 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id B0B432CD323 for ; Fri, 21 Jan 2005 21:53:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F166C3.8070304@gmx.de> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> <41F14D84.7030706@gmx.de> <4883E7CF-6BE1-11D9-A07A-000D936E5072@opengroupware.org> <41F166C3.8070304@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CE5A20C-6BEE-11D9-A07A-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 21:52:55 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 20:53:29 -0000 On 21. Jan 2005, at 21:32 Uhr, Julian Reschke wrote: > Well, you can't say "please don't restart it" and then restart it > yourself (at least it won't work :-). Argh, sorry ;-) > My recommendation is to follow up on the HTTP mailing list and ask for > advice. That's what it's for. Definitely a good advice. Could you give a pointer to the proper list? I suppose there are multiple lists? >> Of course. This is how our server operates since the beginning. It >> works just fine since most (all?) of the generic file browsing >> clients just > Most or all? Did you encounter clients with problems? No, I'm not aware that any client had problems in the way that it doesn't work in an unpredictable way. >> In both contexts there are no SHOULD's or MAY's, only a MUST for a) >> and a plain statement for b). > Well, if you think that the absence of UPPERCASED requirements means > that the text isn't normative, you are wrong. Hm, no, actually I think that missing SHOULDs/MAYs make the written text a MUST? Wrong? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0LKWCaZ008347 for ; Fri, 21 Jan 2005 12:32:13 -0800 Received: (qmail invoked by alias); 21 Jan 2005 20:32:06 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp027) with SMTP; 21 Jan 2005 21:32:06 +0100 X-Authenticated: #1915285 Message-ID: <41F166C3.8070304@gmx.de> Date: Fri, 21 Jan 2005 21:32:03 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> <41F14D84.7030706@gmx.de> <4883E7CF-6BE1-11D9-A07A-000D936E5072@opengroupware.org> In-Reply-To: <4883E7CF-6BE1-11D9-A07A-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 20:32:16 -0000 Helge Hess wrote: > On 21. Jan 2005, at 19:44 Uhr, Julian Reschke wrote: > >>> - clients which support redirect will work excellent with >>> PUT/201/location >>> - all actually should, as per HTTP RFC, otherwise they are no HTTP >>> clients, right? >> >> 201 is not a redirect, 3xx is. > > > Sorry, of course. What would be a proper name, "relocation"? > >> You can't say "created" and "look elsewhere" at the same time for PUT. > > > I can say "created" and the new position is specified by "location". > This is documented in the HTTP spec, we had this before (please lets not > restart this discussion, can be read up in the archives ;-) Well, you can't say "please don't restart it" and then restart it yourself (at least it won't work :-). My recommendation is to follow up on the HTTP mailing list and ask for advice. That's what it's for. >>> - the far majority of clients without location support on PUT will >>> still work just >>> fine (reasons already mentioned) >> >> Did you try? > > > Of course. This is how our server operates since the beginning. It works > just fine since most (all?) of the generic file browsing clients just Most or all? Did you encounter clients with problems? > ... > PUT + 201 + location + if-none-match:* is exactly that as per spec - at > least as I read it. It may have issues attached (like that the etag must > be queried after the PUT if reequired, anything else?). > > Again my reasoning: > > a) 9.6 PUT states: > ---snip--- > If a new resource is created, the origin server MUST inform the user > agent via the 201 (Created) response. > ---snap--- > 9.6 doesn't say anything else about that, so I assume that 201 is > completely valid for PUT, all strings attached. It also says: > ---snip--- Of course 201 is ok. But 9.6 also says: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." So that's what the client is asking for. If you do something else, it's not what it was asking for. > ... the origin server can create the resource with that URI. ... > ---snap--- > While I'm not a native speaker, "with that URI" only says that the > server "uses" the URI to create the request, not that it will store the > new object "at that URI". Well, nor am I, but I think RFC2616 is pretty clear here: "If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI." Arguing that this is a license to create a new resource with a different URI seems to be really far-fetched. But we already disagreed on that, and I don't think we'll come to a consensus, so we'll need more people looking at it, such as the members of the HTTP mailing list. > b) 10.2.2 201 Created: > ---snip--- > The newly created resource can be referenced by the URI(s) returned in > the entity of the response, with the most specific URI for the resource > given by a Location header field > ---snap--- > > In both contexts there are no SHOULD's or MAY's, only a MUST for a) and > a plain statement for b). Well, if you think that the absence of UPPERCASED requirements means that the text isn't normative, you are wrong. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: elias@cse.ucsc.edu X-Envelope-To: Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LJa7aZ003498 for ; Fri, 21 Jan 2005 11:36:07 -0800 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0LJa7P19813 for ; Fri, 21 Jan 2005 11:36:07 -0800 (PST) Message-ID: <41F159A7.80909@cse.ucsc.edu> Date: Fri, 21 Jan 2005 11:36:07 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <41F13C6A.1070906@progbits.com> In-Reply-To: <41F13C6A.1070906@progbits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-caldav 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, 21 Jan 2005 19:36:09 -0000 Scott Carr wrote: > The way I see WebDav, is as a glorified directory storage mechanism. That is one way to view it, yes. One can also view WebDAV as a distributed authoring (the 'DA' in 'DAV') protocol that supports collaborative editing of resources... There are other views, to be sure. > With CalDav, we are extending this mechanism to better handle Calendar > events. Shouldn't we be able to extend it in ways that make clients > easier to write. Certainly, provided that said extensions do not subvert or conflict with existing standards and definitions. for example the recent discussion on using HTTP PUT in a non-standard way, which is in conflict with the definition of the PUT method in RFC 2616. >> [...] this is just regular HTTP GET/PUT with an >> text/calendar entity. > > In a normal webdav server that is the case, but with the CalDav > extension, we could make it more 'usable' to our needs. See above and reflect on the definition of interoperability - changing the definition of standardized protocol methods so that they are more useful for caldav, but less useful for existing applications, is a step in the wrong direction. Cheers, Elias X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LJJQaZ002548 for ; Fri, 21 Jan 2005 11:19:27 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id AB2702CD915 for ; Fri, 21 Jan 2005 20:19:20 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id D25BC2CC043 for ; Fri, 21 Jan 2005 20:19:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F14D84.7030706@gmx.de> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> <41F14D84.7030706@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4883E7CF-6BE1-11D9-A07A-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 20:18:51 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 19:19:28 -0000 On 21. Jan 2005, at 19:44 Uhr, Julian Reschke wrote: >> - clients which support redirect will work excellent with >> PUT/201/location >> - all actually should, as per HTTP RFC, otherwise they are no HTTP >> clients, right? > 201 is not a redirect, 3xx is. Sorry, of course. What would be a proper name, "relocation"? > You can't say "created" and "look elsewhere" at the same time for PUT. I can say "created" and the new position is specified by "location". This is documented in the HTTP spec, we had this before (please lets not restart this discussion, can be read up in the archives ;-) >> - the far majority of clients without location support on PUT will >> still work just >> fine (reasons already mentioned) > Did you try? Of course. This is how our server operates since the beginning. It works just fine since most (all?) of the generic file browsing clients just issue a collection reload after a creation and do not keep the URL for anything. A periodic refresh is what they need to do anyway, since other users might have changed the server. So, yes, it has issues attached for non-location aware clients, but a lot of operations still work just fine. Like dropping ICS files into Nautilus folder. In the worst case you need to trigger a manual refresh. > I think you are confusing 201 and 3xx. A location header sent with a > "Created" status is not a redirect. No, I'm not confusing this. I just failed to use proper terminology in some places, sorry about that. Actually I think our past discussion on this was a bit mixed up due to this. I never intended to do a redirect 3xx to achieve the functionality. > I *do* see the merits of having a standard way to let the server > choose a new name (not only for caldav), but as far as I can tell, > there currently is none. It may make sense to define a new one (new > method name?), but that shouldn't be part of CalDav. PUT + 201 + location + if-none-match:* is exactly that as per spec - at least as I read it. It may have issues attached (like that the etag must be queried after the PUT if reequired, anything else?). Again my reasoning: a) 9.6 PUT states: ---snip--- If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. ---snap--- 9.6 doesn't say anything else about that, so I assume that 201 is completely valid for PUT, all strings attached. It also says: ---snip--- ... the origin server can create the resource with that URI. ... ---snap--- While I'm not a native speaker, "with that URI" only says that the server "uses" the URI to create the request, not that it will store the new object "at that URI". b) 10.2.2 201 Created: ---snip--- The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field ---snap--- In both contexts there are no SHOULD's or MAY's, only a MUST for a) and a plain statement for b). As you correctly mention, 'location' + 201 is _not_ a redirect, so the issues on redirects in the spec do not apply. To get back to the discussion, while resolving this issue is probably interesting, it doesn't matter to CalDAV if the majority of the participants does not need this functionality. It indeed makes clients a tad more difficult to write. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LInvaZ032493 for ; Fri, 21 Jan 2005 10:49:57 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 12:50:31 -0600 Message-ID: <41F14E9F.8040405@progbits.com> Date: Fri, 21 Jan 2005 12:49:03 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> In-Reply-To: <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 18:50:31.0859 (UTC) FILETIME=[1555C830:01C4FFEA] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:49:59 -0000 Lisa Dusseault wrote: > Typically, POST requests to "live Web Servers" are only handled by > code that generates dynamic responses if the Request-URI identifies a > servlet, CGI script, or other code handler. Live Web servers already > have to handle this distinction. You could test this out by finding a > Web server that had some static file stored on disk, available via GET > to an arbitrary URL, and try POST to that URL and see what happens. I > suspect it would say that the resource doesn't handle POST method. Just tried this against Apache 2.0. I sent the following request: POST /~scarr/test.html HTTP/1.1 Host: progbits.com And it returned back with the test.html content immediately. Granted this is not a WebDav server, but should it make a difference? -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0LIiQaZ032153 for ; Fri, 21 Jan 2005 10:44:27 -0800 Received: (qmail invoked by alias); 21 Jan 2005 18:44:20 -0000 Received: from p50825326.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.83.38) by mail.gmx.net (mp007) with SMTP; 21 Jan 2005 19:44:20 +0100 X-Authenticated: #1915285 Message-ID: <41F14D84.7030706@gmx.de> Date: Fri, 21 Jan 2005 19:44:20 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> In-Reply-To: <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:44:29 -0000 Helge Hess wrote: > On 21. Jan 2005, at 19:12 Uhr, Cyrus Daboo wrote: > >> That's really the question: do existing webdav clients properly handle >> a re-direct on the creation of a new resource? I think some >> experimentation is needed. If we find that all existing >> clients/libraries cope with that then we're OK. If that's not the >> case, then we have to decide whether we care about 'breaking' those >> clients... > > > As mentioned: > - clients which support redirect will work excellent with PUT/201/location > - all actually should, as per HTTP RFC, otherwise they are no HTTP > clients, right? 201 is not a redirect, 3xx is. You can't say "created" and "look elsewhere" at the same time for PUT. > - the far majority of clients without location support on PUT will still > work just > fine (reasons already mentioned) Did you try? > - the POST approach will work with _no_ existing client nor server That's correct. So the thr working group / community should decide whether that's a scenario that absolutely must be supported for existing clients. As far as I can tell, there is no conformant way to do so. > I do not expect all clients to work fine with that. And this is not just > a client _application_ issue - a client _library_ is very likely to > include redirect/location support (since this is without question widely > supported for GET). So as a client developer I can just reuse existing > functionality for PUTs if this isn't even supported already. I think you are confusing 201 and 3xx. A location header sent with a "Created" status is not a redirect. > Now allowing the client to choose arbitary names is certainly the > approach which provides the best possible compatibility with generic > clients. But has other issues as mentioned. > Since I'm apparently the only one who wishes for the server maintained > namespace support, I suppose Lisa's proposal might indeed be the way to > go :-| I *do* see the merits of having a standard way to let the server choose a new name (not only for caldav), but as far as I can tell, there currently is none. It may make sense to define a new one (new method name?), but that shouldn't be part of CalDav. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LIVHaZ031652 for ; Fri, 21 Jan 2005 10:31:17 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 12:31:51 -0600 Message-ID: <41F14A3F.5000605@progbits.com> Date: Fri, 21 Jan 2005 12:30:23 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> <41F14811.7090508@gmx.de> In-Reply-To: <41F14811.7090508@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 18:31:51.0577 (UTC) FILETIME=[79985090:01C4FFE7] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:31:18 -0000 Julian Reschke wrote: > I think what's important here is that the spec doesn't contain any > normative requirements that are in conflict with PUT semantics (and I > think those would be). > > Proposal: > > - have a normative way to use POST to do that operation (or a new > verb), but A new verb would work as well, something like PUTNEW, or a variation thereof. > - allow server implementers to do with PUT with they want on their own > risk. This will be a part of the spec no matter what we come up with. The client can still use the normal WebDav functionality. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LIUlaZ031600 for ; Fri, 21 Jan 2005 10:30:47 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0FC3D2CDB15 for ; Fri, 21 Jan 2005 19:30:41 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id C1F132CDAB9 for ; Fri, 21 Jan 2005 19:30:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7EA70B80-6BDA-11D9-A07A-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 19:30:15 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:30:49 -0000 On 21. Jan 2005, at 19:12 Uhr, Cyrus Daboo wrote: > That's really the question: do existing webdav clients properly handle > a re-direct on the creation of a new resource? I think some > experimentation is needed. If we find that all existing > clients/libraries cope with that then we're OK. If that's not the > case, then we have to decide whether we care about 'breaking' those > clients... As mentioned: - clients which support redirect will work excellent with PUT/201/location - all actually should, as per HTTP RFC, otherwise they are no HTTP clients, right? - the far majority of clients without location support on PUT will still work just fine (reasons already mentioned) - the POST approach will work with _no_ existing client nor server I do not expect all clients to work fine with that. And this is not just a client _application_ issue - a client _library_ is very likely to include redirect/location support (since this is without question widely supported for GET). So as a client developer I can just reuse existing functionality for PUTs if this isn't even supported already. Now allowing the client to choose arbitary names is certainly the approach which provides the best possible compatibility with generic clients. But has other issues as mentioned. Since I'm apparently the only one who wishes for the server maintained namespace support, I suppose Lisa's proposal might indeed be the way to go :-| Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0LILEaZ030997 for ; Fri, 21 Jan 2005 10:21:14 -0800 Received: (qmail invoked by alias); 21 Jan 2005 18:21:08 -0000 Received: from p50825326.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.83.38) by mail.gmx.net (mp023) with SMTP; 21 Jan 2005 19:21:08 +0100 X-Authenticated: #1915285 Message-ID: <41F14811.7090508@gmx.de> Date: Fri, 21 Jan 2005 19:21:05 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:21:16 -0000 Cyrus Daboo wrote: > Hi Helge, > > --On January 21, 2005 7:02:58 PM +0100 Helge Hess > wrote: > >> Since HTTP clients are required to support redirects in any case, I don't >> see why CalDAV should restrict HTTP here. As mentioned before in the >> discussion with Julian, the location header is explicitly specified for >> 201. >> > > That's really the question: do existing webdav clients properly handle a > re-direct on the creation of a new resource? I think some > experimentation is needed. If we find that all existing > clients/libraries cope with that then we're OK. If that's not the case, > then we have to decide whether we care about 'breaking' those clients... I think what's important here is that the spec doesn't contain any normative requirements that are in conflict with PUT semantics (and I think those would be). Proposal: - have a normative way to use POST to do that operation (or a new verb), but - allow server implementers to do with PUT with they want on their own risk. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LICiaa030325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 10:12:45 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LI7O6E004144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 13:07:25 -0500 Date: Fri, 21 Jan 2005 13:12:42 -0500 From: Cyrus Daboo To: Helge Hess , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:12:46 -0000 Hi Helge, --On January 21, 2005 7:02:58 PM +0100 Helge Hess wrote: > Since HTTP clients are required to support redirects in any case, I don't > see why CalDAV should restrict HTTP here. As mentioned before in the > discussion with Julian, the location header is explicitly specified for > 201. > That's really the question: do existing webdav clients properly handle a re-direct on the creation of a new resource? I think some experimentation is needed. If we find that all existing clients/libraries cope with that then we're OK. If that's not the case, then we have to decide whether we care about 'breaking' those clients... -- Cyrus Daboo X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LI6oaZ030039 for ; Fri, 21 Jan 2005 10:06:51 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 12:07:25 -0600 Message-ID: <41F14485.2000908@progbits.com> Date: Fri, 21 Jan 2005 12:05:57 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> <41F13DB1.8090805@progbits.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 18:07:25.0390 (UTC) FILETIME=[0FADEEE0:01C4FFE4] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:06:52 -0000 Cyrus Daboo wrote: > The proper distinction is this: > > A 'level 0' server is one in which an entire iCalendar 'agenda' is > accessed as a single resource. i.e. all events, to-dos, timezones etc > are bundled up into one iCalendar object. > > A 'level 1' server is one in which each separate component in an > iCalendar 'agenda' is accessed as a separate resource. i.e. each > event, to-do etc has a separate URI. > Ohhhh, thanks. Makes sense now. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LI3UaZ029691 for ; Fri, 21 Jan 2005 10:03:30 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id DA8CF2CDA40 for ; Fri, 21 Jan 2005 19:03:23 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 9328D2CC4F7 for ; Fri, 21 Jan 2005 19:03:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 19:02:58 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:03:32 -0000 On 21. Jan 2005, at 18:31 Uhr, Lisa Dusseault wrote: > Then what about the client choosing to upload an event where the final > URL segment is "lunch.ics" vs. "event128" vs. "foo.cal.event"? Can > we require the server to allow any of these without doing a redirect > or rename? I think we can and probably should. After all, we're only > asking the server to maintain an extra table mapping client-chosen > resource names to its existing naming. I'm rather allergic against protocols which require me to change or extend the datastorage (the RDBMS database schema in our server). Changing a database schema is a maintenance/update nightmare. Since HTTP clients are required to support redirects in any case, I don't see why CalDAV should restrict HTTP here. As mentioned before in the discussion with Julian, the location header is explicitly specified for 201. > E.g. if the existing calendar server has a global table of events > where every event is indexed by its UID, then we're requiring it to > persist the mappings between UIDs and client-chosen segment names and > calendar paths (another table, column, cache, etc.) Thats an interesting point. Of course server side namespaces also affect iCalendar UIDs! After all thats the point, using the server side "primary key" in all places to avoid additional lookup tables. > Now I'm not responsible for implementing one of these servers, but if > those who do can get behind this this, it would sure simplify by > removing the feature for a calendar server to choose a resource name > on behalf of the client, and that *should* allow existing WebDAV > clients to synchronize (both upload and download) directories of > events in iCalendar files. I don't think existing WebDAV clients will be affected at all. Could you give an example where the given PUT approach is a real world issue with existing clients? Having said that, sure, should CalDAV specify that clients are allowed to choose arbitary names and must not implement redirection, we would implement it. But this is significant additional work which will hinder adoption (IMO). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LI3Qaa029692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 10:03:28 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LHw86E003731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 12:58:08 -0500 Date: Fri, 21 Jan 2005 13:03:26 -0500 From: Cyrus Daboo To: Scott Carr , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: In-Reply-To: <41F13DB1.8090805@progbits.com> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> <41F13DB1.8090805@progbits.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 18:03:30 -0000 Hi Scott, --On January 21, 2005 11:36:49 AM -0600 Scott Carr wrote: >>> The problem is the 'whole calendar' 'level 0' approach will not >>> interact very well with the 'per component' 'level 1' (current >>> design) scheme. >> > Just to make sure I have this concept correct before I start talking > about it... > > Level 0: Server would get a URL and have to decide what Events the > request is dealing with itself. > > Level 1: Server would geta full URL with Filename and would be able to > know which file to work with based on URL. > > Do I have this correct? > The proper distinction is this: A 'level 0' server is one in which an entire iCalendar 'agenda' is accessed as a single resource. i.e. all events, to-dos, timezones etc are bundled up into one iCalendar object. A 'level 1' server is one in which each separate component in an iCalendar 'agenda' is accessed as a separate resource. i.e. each event, to-do etc has a separate URI. -- Cyrus Daboo X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHxoaZ028994 for ; Fri, 21 Jan 2005 09:59:50 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 12:00:24 -0600 Message-ID: <41F142E0.7030001@progbits.com> Date: Fri, 21 Jan 2005 11:58:56 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <41F13C6A.1070906@progbits.com> <390D48B2-6BD4-11D9-A07A-000D936E5072@opengroupware.org> In-Reply-To: <390D48B2-6BD4-11D9-A07A-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 18:00:24.0905 (UTC) FILETIME=[150D0390:01C4FFE3] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:59:51 -0000 Helge Hess wrote: > On 21. Jan 2005, at 18:31 Uhr, Scott Carr wrote: > >>> I won't object, but IMO this does not belong into the CalDAV >>> discussion nor should be codified as some standard - lets just hope >>> that this approach of calendar sharing is a thing of history very soon. >> >> >> This approach of Calendar sharing? Could you elaborate, please. >> Unfortunately, I haven't been involved with these discussions for >> that long. > > > I referred to the current approach implemented by most/all OpenSource > clients which package all vevents in a single HTTP entity. This > results in the various issues the others have just mentioned. > > Personally I hope that CalDAV will replace the above approach (I call > it iCal-over-HTTP) completely. Though it needs to be simple enough to > accomplish that. Ohhhh, I understand it now. I have used Sunbird and they are looking to use CalDav. I think the developers are currently using something from Oracle to play around with the CalDav implementation. That is how I came to be aware of CalDav. So I think things should come together once the spec is there. > >> The way I see WebDav, is as a glorified directory storage mechanism. >> With CalDav, we are extending this mechanism to better handle >> Calendar events. Shouldn't we be able to extend it in ways that make >> clients easier to write. > > > Definitely. > > Clients are easier to write if we reuse existing technology to the > largest possible degree. That is WebDAV/HTTP client libraries and > tools. Why invent something like a POST on a collection if HTTP > libraries already implement etag processing and redirection as per spec? > There need to be very good reasons for that. Understand. We should have a very good reason for changes of this magnitude. We shouldn't just add stuff because it makes us feel better. ;-) > >>> BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT >>> with an text/calendar entity. >> >> In a normal webdav server that is the case, but with the CalDav >> extension, we could make it more 'usable' to our needs. > > > With a CalDAV extension there is no reason to use the 'old' approach > anymore. Ok, just making sure I understood things clearly. ;-) -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHwGaa028841 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:58:19 -0800 In-Reply-To: <41F13EAF.5010700@progbits.com> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> <41F13EAF.5010700@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02759D62-6BD6-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:58:09 -0800 To: Scott Carr X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:58:21 -0000 Typically, POST requests to "live Web Servers" are only handled by code that generates dynamic responses if the Request-URI identifies a servlet, CGI script, or other code handler. Live Web servers already have to handle this distinction. You could test this out by finding a Web server that had some static file stored on disk, available via GET to an arbitrary URL, and try POST to that URL and see what happens. I suspect it would say that the resource doesn't handle POST method. Lisa On Jan 21, 2005, at 9:41 AM, Scott Carr wrote: > Lisa Dusseault wrote: > >> There's a certain amount of "allergic reaction" to the use of POST >> because in the past there have been proposals to write entire >> layerable protocols on top of HTTP using POST. This arose rather >> naturally from the fact that POST allows WebUIs with user >> interaction, and a WebUI's fields and forms constitute a de facto >> "protocol" that is modeled by assigning values to field names and >> uploading those names and values in the Web form format. > > Correct me if I am wrong, please, but: > > Isn't a WebDav server also, potentially a LIVE web server? If we use > POST in the CalDav protocol, isn't it possible that a WebServer could > get confussed and think it is supposed to GET the resource instead of > editing the resource? > > -- > Scott Carr > OpenOffice.org > Documentation Co-Lead > http://documentation.openoffice.org > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHu9aa028687 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:56:10 -0800 In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:55:46 -0800 To: Helge Hess X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:56:12 -0000 > >> The goal with that would be that CalDAV 'aware' clients can use POST >> to ensure that they avoid the 412 errors on PUT and avoid extra >> roundtrips (which are actually quite expensive in that the data gets >> uploaded each time, only to be rejected by the server - defintiely >> not ideal for mobile devices). > > Good point. Yet I'm not sure whether it matters in practice. The 412 > errors only occur if a name is already taken which should be a > extremely rare (though important) exception in practice if the client > generates sufficiently unique identifiers. > In theory HTTP has a way of avoiding this too! --client--- PUT /users/lisa/calendar/event1284.ics HTTP/1.1 If-None-Match: * Content-Type: text/icalendar Content-Length: 882 Expect: 100-continue ---server--- HTTP/1.1 100 Continue ---client--- BEGIN:VCALENDAR ....more stuff END:VCALENDAR ---- Result: if the server could not satisfy the request due to permissions, policy, disallowed MIME format, excessive length, failure to satify If-None-Match or any other problem, it would respond with 412 instead of 100. However unless the event has a very large attachment I just wouldn't bother. Besides, the client could always create the event with a very small file then add the attachment in a first modification. Y'all need to read my book again :) Lisa X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHjsaZ028149 for ; Fri, 21 Jan 2005 09:45:54 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D83AA2CB719 for ; Fri, 21 Jan 2005 18:45:47 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 609112CC410 for ; Fri, 21 Jan 2005 18:45:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F13C6A.1070906@progbits.com> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <41F13C6A.1070906@progbits.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <390D48B2-6BD4-11D9-A07A-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 18:45:21 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:45:55 -0000 On 21. Jan 2005, at 18:31 Uhr, Scott Carr wrote: >> I won't object, but IMO this does not belong into the CalDAV >> discussion nor should be codified as some standard - lets just hope >> that this approach of calendar sharing is a thing of history very >> soon. > > This approach of Calendar sharing? Could you elaborate, please. > Unfortunately, I haven't been involved with these discussions for that > long. I referred to the current approach implemented by most/all OpenSource clients which package all vevents in a single HTTP entity. This results in the various issues the others have just mentioned. Personally I hope that CalDAV will replace the above approach (I call it iCal-over-HTTP) completely. Though it needs to be simple enough to accomplish that. > The way I see WebDav, is as a glorified directory storage mechanism. > With CalDav, we are extending this mechanism to better handle Calendar > events. Shouldn't we be able to extend it in ways that make clients > easier to write. Definitely. Clients are easier to write if we reuse existing technology to the largest possible degree. That is WebDAV/HTTP client libraries and tools. Why invent something like a POST on a collection if HTTP libraries already implement etag processing and redirection as per spec? There need to be very good reasons for that. >> BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT >> with an text/calendar entity. > In a normal webdav server that is the case, but with the CalDav > extension, we could make it more 'usable' to our needs. With a CalDAV extension there is no reason to use the 'old' approach anymore. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHg0aZ027537 for ; Fri, 21 Jan 2005 09:42:00 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 11:42:31 -0600 Message-ID: <41F13EAF.5010700@progbits.com> Date: Fri, 21 Jan 2005 11:41:03 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> In-Reply-To: <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 17:42:31.0546 (UTC) FILETIME=[95476DA0:01C4FFE0] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:42:02 -0000 Lisa Dusseault wrote: > There's a certain amount of "allergic reaction" to the use of POST > because in the past there have been proposals to write entire > layerable protocols on top of HTTP using POST. This arose rather > naturally from the fact that POST allows WebUIs with user interaction, > and a WebUI's fields and forms constitute a de facto "protocol" that > is modeled by assigning values to field names and uploading those > names and values in the Web form format. Correct me if I am wrong, please, but: Isn't a WebDav server also, potentially a LIVE web server? If we use POST in the CalDav protocol, isn't it possible that a WebServer could get confussed and think it is supposed to GET the resource instead of editing the resource? -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHbhaZ027300 for ; Fri, 21 Jan 2005 09:37:43 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 11:38:18 -0600 Message-ID: <41F13DB1.8090805@progbits.com> Date: Fri, 21 Jan 2005 11:36:49 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> In-Reply-To: <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 17:38:18.0109 (UTC) FILETIME=[FE3802D0:01C4FFDF] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:37:44 -0000 Helge Hess wrote: > On 21. Jan 2005, at 16:46 Uhr, Cyrus Daboo wrote: > >> The problem is the 'whole calendar' 'level 0' approach will not >> interact very well with the 'per component' 'level 1' (current >> design) scheme. > Just to make sure I have this concept correct before I start talking about it... Level 0: Server would get a URL and have to decide what Events the request is dealing with itself. Level 1: Server would geta full URL with Filename and would be able to know which file to work with based on URL. Do I have this correct? -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHavaa027220 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:36:59 -0800 In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <080A7842-6BD3-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:36:49 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:37:02 -0000 There's a certain amount of "allergic reaction" to the use of POST because in the past there have been proposals to write entire layerable protocols on top of HTTP using POST. This arose rather naturally from the fact that POST allows WebUIs with user interaction, and a WebUI's fields and forms constitute a de facto "protocol" that is modeled by assigning values to field names and uploading those names and values in the Web form format. However, I *believe* there is now sufficient understanding of when it's OK to use POST that this might be widely considered to be an acceptable definition, rather than simply trigger the allergic reaction of "nobody can use POST!" On the other hand the sufficient understanding and lack of allergic reaction might exist and yet the community might deduce that it's not OK to use POST on a WebDAV collection to create a new resource to be named by the server. We could always float this and see -- that is, if we agree that this is a requirement for CalDAV. My previous email suggested that it is not. Lisa On Jan 21, 2005, at 9:26 AM, Cyrus Daboo wrote: > Hi Scott, > > --On January 21, 2005 11:18:24 AM -0600 Scott Carr > wrote: > >>> Really the core problem we have here is the fact that some servers >>> may >>> prefer to use a URI naming scheme that they define because they need >>> to operate on top of an existing calendar store with specific >>> requirements for naming resources. So we need to solve the redirect >>> problem in a way that has minimal impact for 'plain' WebDAV clients >>> and with minimum complexity for CalDAV clients that can expect a >>> redirect. >>> >> I think having a method in the spec to keep from doing a roundtrip >> would >> be a good idea as well. With WebDav, if the client wants to use the >> standard way of doing things, we won't be removing functionality. We >> are >> adding functionality that better helps our specific needs. >> >> If we add a way to set something and be done with it, then it will >> help >> "dumb down" the clients needed logic. > > Currently my personal preference for this is to use 'POST' on the > calendar collection with a text/calendar body - that tells the server > to create a new resource for the calendar data, and the server would > return the new location in a Location (or other appropriate header). > However, I have been told that there are 'issues' with POST, so I'm > not sure how viable that would be. > > The goal with that would be that CalDAV 'aware' clients can use POST > to ensure that they avoid the 412 errors on PUT and avoid extra > roundtrips (which are actually quite expensive in that the data gets > uploaded each time, only to be rejected by the server - defintiely not > ideal for mobile devices). Regular WebDAV clients would continue to > use PUT in their normal way and would have to cope with the roundtrips > as they would anyway. > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHaMaZ027087 for ; Fri, 21 Jan 2005 09:36:22 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 194442CDBBD for ; Fri, 21 Jan 2005 18:36:16 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id D48162CDB31 for ; Fri, 21 Jan 2005 18:36:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 18:35:50 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:36:24 -0000 On 21. Jan 2005, at 18:26 Uhr, Cyrus Daboo wrote: > Currently my personal preference for this is to use 'POST' on the > calendar collection with a text/calendar body - that tells the server > to create a new resource for the calendar data, and the server would > return the new location in a Location (or other appropriate header). > However, I have been told that there are 'issues' with POST, so I'm > not sure how viable that would be. One major drawback is that you won't be able create items with existing WebDAV clients (or client libraries). You need to write special code to handle the POST even though all the functionality is available in the base protocol. > The goal with that would be that CalDAV 'aware' clients can use POST > to ensure that they avoid the 412 errors on PUT and avoid extra > roundtrips (which are actually quite expensive in that the data gets > uploaded each time, only to be rejected by the server - defintiely not > ideal for mobile devices). Good point. Yet I'm not sure whether it matters in practice. The 412 errors only occur if a name is already taken which should be a extremely rare (though important) exception in practice if the client generates sufficiently unique identifiers. > Regular WebDAV clients would continue to use PUT in their normal way > and would have to cope with the roundtrips as they would anyway. Regular WebDAV clients still might want to know about the new URL the item will live on for servers which require namespace maintenance. IMO the location header with 201 is the best solution and while Julian raised several issues in the past, I think there are no strong objections towards that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHWYaa026138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:32:37 -0800 In-Reply-To: <20440EFC300937DC4EF16548@ninevah.local> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <4F6D47F1-6BCD-11D9-961E-000A95B2BB72@osafoundation.org> <20440EFC300937DC4EF16548@ninevah.local> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6C25B592-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:32:28 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Dan Mosedale , ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:32:38 -0000 Yep, it's not easy, that's why I'd like to see a separate document describing it! lisa On Jan 21, 2005, at 9:21 AM, Cyrus Daboo wrote: > Hi Lisa, > > --On January 21, 2005 8:55:52 AM -0800 Lisa Dusseault > wrote: > >> - The server MUST split up the full calendar whenever uploaded and >> attempt to apply each changed event one by one, matching UIDs to >> existing >> events. The server MUST NOT cause an existing event to change if the >> data in it is unchanged. > > Determining whether the data is unchanged or not is not easy. There > are issues like: > > - clients simply re-ordering the properties but not changing the > content (e.g. my client reads all props into a database, and writes > them out in alphabetic order due to the way the database works - that > may not match the original order) > > - clients re-wrapping long lines at a slightly different location than > in the original. > > - clients using a different unicode normalisation on non-ascii text > that results in the same effective unicode text (stringprep would > solve that - uggh). > > There is also the issue of not wanting to rely on timestamps in the > component (e.g. 'LAST-MODIFIED') because often clients and servers are > NOT in sync wrt their clocks. > > -- > Cyrus Daboo X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHWGaZ026080 for ; Fri, 21 Jan 2005 09:32:16 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 11:32:50 -0600 Message-ID: <41F13C6A.1070906@progbits.com> Date: Fri, 21 Jan 2005 11:31:22 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 17:32:50.0796 (UTC) FILETIME=[3B2002C0:01C4FFDF] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:32:27 -0000 Helge Hess wrote: > On 21. Jan 2005, at 07:00 Uhr, Dan Mosedale wrote: > >>> This is actually something we do in our ZideStore server. You can >>> either retrieve/store a collection as a single iCalendar entity >>> containing all events or treat it like a WebDAV collection >>> containing individual events. >>> >>> Good for compatibility with existing clients. >> >> >> This is an elegant semantic, because it allows people to advertise a >> single URL as their calendar URL, and smart clients can access it as >> CalDAV, while simpler ones can access it as WebDAV. Codifying this >> in some way in the standard (as a MAY, perhaps) seems worthwhile to me. > > > I won't object, but IMO this does not belong into the CalDAV > discussion nor should be codified as some standard - lets just hope > that this approach of calendar sharing is a thing of history very soon. This approach of Calendar sharing? Could you elaborate, please. Unfortunately, I haven't been involved with these discussions for that long. The way I see WebDav, is as a glorified directory storage mechanism. With CalDav, we are extending this mechanism to better handle Calendar events. Shouldn't we be able to extend it in ways that make clients easier to write. > > Its just a 'smart' way to support two different approaches in one > server. Our server also supports some WCAP and Exchange WebDAV API at > the same time, that doesn't imply that CalDAV should specify the to ;-) > > BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT > with an text/calendar entity. In a normal webdav server that is the case, but with the CalDav extension, we could make it more 'usable' to our needs. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHVraa025994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 09:31:56 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LHQT6E002928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 12:26:29 -0500 Date: Fri, 21 Jan 2005 12:31:46 -0500 From: Cyrus Daboo To: Helge Hess , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: <702A1BC7966747FE8ADD5037@ninevah.local> In-Reply-To: <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:32:01 -0000 Hi Helge, --On January 21, 2005 6:25:58 PM +0100 Helge Hess wrote: >> In terms of how to do it, as Julian points out, you cannot use PUT on >> the collection. > > This I can't follow and I don't think that this is what Julian said. He > said that a PUT on a collection writes the content of the collection and > does NOT write content for new items inside the collection. In other > words: PUT on a collection is already specified in HTTP and can't be > redefined to do something else. > > It should be perfectly valid for a WebDAV collection to have content as > well as children protocolwise. > Please correct me by pointing to the proper section of the WebDAV spec in > case I'm wrong. > > Thanks, > Helge > > PS: yes, I'm perfectly aware that several WebDAV servers might not allow > for that, that doesn't imply its forbidden by the protocol ;-) Sorry, I think my wording was a bit lax there - I agree with your analysis of this situation: PUT on the collection is allowed via the spec, but may not be supported by a server and certainly won't have the desired effect of actually creating a new resource inside the collection. -- Cyrus Daboo X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHVIaa025966 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:31:20 -0800 In-Reply-To: References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3E595BD6-6BD2-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:31:11 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:31:23 -0000 > > > Really the core problem we have here is the fact that some servers may > prefer to use a URI naming scheme that they define because they need > to operate on top of an existing calendar store with specific > requirements for naming resources. So we need to solve the redirect > problem in a way that has minimal impact for 'plain' WebDAV clients > and with minimum complexity for CalDAV clients that can expect a > redirect. > > Perhaps we haven't looked closely enough at whether it's reasonable to require servers to support arbitrary event URLs chosen by clients. After all, the server can already restrict where to create calendars and can even provision the calendar locations -- e.g. a server isn't actually required to support MKCALENDAR because it can simply create a calendar wherever it likes for every defined user. So rather than store locations like "/users/ldusseault/calendar" and "/users/cdaboo/calendar" it can generate those paths from its provisioning policies. Then what about the client choosing to upload an event where the final URL segment is "lunch.ics" vs. "event128" vs. "foo.cal.event"? Can we require the server to allow any of these without doing a redirect or rename? I think we can and probably should. After all, we're only asking the server to maintain an extra table mapping client-chosen resource names to its existing naming. E.g. if the existing calendar server has a global table of events where every event is indexed by its UID, then we're requiring it to persist the mappings between UIDs and client-chosen segment names and calendar paths (another table, column, cache, etc.) Now I'm not responsible for implementing one of these servers, but if those who do can get behind this this, it would sure simplify by removing the feature for a calendar server to choose a resource name on behalf of the client, and that *should* allow existing WebDAV clients to synchronize (both upload and download) directories of events in iCalendar files. Lisa X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHQeaa025280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 09:26:41 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LHLH6E002787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 12:21:17 -0500 Date: Fri, 21 Jan 2005 12:26:35 -0500 From: Cyrus Daboo To: Scott Carr , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: In-Reply-To: <41F13960.3060406@progbits.com> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> <41F13960.3060406@progbits.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:26:44 -0000 Hi Scott, --On January 21, 2005 11:18:24 AM -0600 Scott Carr wrote: >> Really the core problem we have here is the fact that some servers may >> prefer to use a URI naming scheme that they define because they need >> to operate on top of an existing calendar store with specific >> requirements for naming resources. So we need to solve the redirect >> problem in a way that has minimal impact for 'plain' WebDAV clients >> and with minimum complexity for CalDAV clients that can expect a >> redirect. >> > I think having a method in the spec to keep from doing a roundtrip would > be a good idea as well. With WebDav, if the client wants to use the > standard way of doing things, we won't be removing functionality. We are > adding functionality that better helps our specific needs. > > If we add a way to set something and be done with it, then it will help > "dumb down" the clients needed logic. Currently my personal preference for this is to use 'POST' on the calendar collection with a text/calendar body - that tells the server to create a new resource for the calendar data, and the server would return the new location in a Location (or other appropriate header). However, I have been told that there are 'issues' with POST, so I'm not sure how viable that would be. The goal with that would be that CalDAV 'aware' clients can use POST to ensure that they avoid the 412 errors on PUT and avoid extra roundtrips (which are actually quite expensive in that the data gets uploaded each time, only to be rejected by the server - defintiely not ideal for mobile devices). Regular WebDAV clients would continue to use PUT in their normal way and would have to cope with the roundtrips as they would anyway. -- Cyrus Daboo X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHQUaZ025207 for ; Fri, 21 Jan 2005 09:26:30 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A608D2CDB3E for ; Fri, 21 Jan 2005 18:26:23 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 585802CDAF7 for ; Fri, 21 Jan 2005 18:26:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <0147A834B4CF6EFB7750ED80@ninevah.local> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <838CC848-6BD1-11D9-A07A-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 18:25:58 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:26:31 -0000 On 21. Jan 2005, at 16:46 Uhr, Cyrus Daboo wrote: > The problem is the 'whole calendar' 'level 0' approach will not > interact very well with the 'per component' 'level 1' (current design) > scheme. ... > This adds a lot more complexity to the server. Exactly. I would really like to keep iCal-over-HTTP out of the discussion. I would like to have clarification on that: > In terms of how to do it, as Julian points out, you cannot use PUT on > the collection. This I can't follow and I don't think that this is what Julian said. He said that a PUT on a collection writes the content of the collection and does NOT write content for new items inside the collection. In other words: PUT on a collection is already specified in HTTP and can't be redefined to do something else. It should be perfectly valid for a WebDAV collection to have content as well as children protocolwise. Please correct me by pointing to the proper section of the WebDAV spec in case I'm wrong. Thanks, Helge PS: yes, I'm perfectly aware that several WebDAV servers might not allow for that, that doesn't imply its forbidden by the protocol ;-) -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHL6aa024828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 09:21:07 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LHFk6E002634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 12:15:46 -0500 Date: Fri, 21 Jan 2005 12:21:03 -0500 From: Cyrus Daboo To: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: <20440EFC300937DC4EF16548@ninevah.local> In-Reply-To: <4F6D47F1-6BCD-11D9-961E-000A95B2BB72@osafoundation.org> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> <4F6D47F1-6BCD-11D9-961E-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Dan Mosedale , ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:21:08 -0000 Hi Lisa, --On January 21, 2005 8:55:52 AM -0800 Lisa Dusseault wrote: > - The server MUST split up the full calendar whenever uploaded and > attempt to apply each changed event one by one, matching UIDs to existing > events. The server MUST NOT cause an existing event to change if the > data in it is unchanged. Determining whether the data is unchanged or not is not easy. There are issues like: - clients simply re-ordering the properties but not changing the content (e.g. my client reads all props into a database, and writes them out in alphabetic order due to the way the database works - that may not match the original order) - clients re-wrapping long lines at a slightly different location than in the original. - clients using a different unicode normalisation on non-ascii text that results in the same effective unicode text (stringprep would solve that - uggh). There is also the issue of not wanting to rely on timestamps in the component (e.g. 'LAST-MODIFIED') because often clients and servers are NOT in sync wrt their clocks. -- Cyrus Daboo X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHJHaZ024720 for ; Fri, 21 Jan 2005 09:19:18 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 11:19:52 -0600 Message-ID: <41F13960.3060406@progbits.com> Date: Fri, 21 Jan 2005 11:18:24 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 17:19:52.0280 (UTC) FILETIME=[6B17E580:01C4FFDD] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:19:20 -0000 Cyrus Daboo wrote: > Hi Scott, > > --On January 21, 2005 10:07:18 AM -0600 Scott Carr > wrote: > >> The problem that I see in the this is, how do we know that the >> following: >> >> PUT /scarr/Calendar/1234.evt HTTP/1.1 >> >> Is not meant to edit 1234.evt if it already exists. The / could denote >> an add operation to a CalDav based server. The return header would >> include the filename that was generated for the new resource. Of >> course, >> there are several ways we could do this, as well. >> > > ETags and the If-Match/If-None-Match header can be used by clients to > ensure expected behaviour when creating or editing existing resources > - this is just standard http behaviour. > > e.g.: > > To create a new resource: > > PUT /calendar/cyrus/1234.ics HTTP/1.1 > Host: localhost > If-None-Match: * > ... > > In the above request, if a resource already exists at the specified > URI, then the server will return a '412 (Precondition Failed)' and the > client will know to try another URI for create. > > To edit an existing resource: > > PUT /calendar/cyrus/1234.ics HTTP/1.1 > Host: localhost > If-Match: 1234etag-2005-01-21 > ... > > In the above request, if the resource on the server has changed or > been deleted, the server will respond with a '412 (Precondition > Failed)' and the client will know to take remedial action. > Ok. Thanks for the explanation. It makes sense as well. > Right now this is what my implementation does: it generates a unique > uri based on a hash of the component UID, SEQUENCE, DTSTAMP & > RECURRENCE-ID, and tries to create that with the If-None-Match header > present. If that fails with 412, we add a counter into the string > being hashed, rehash it and try with that. The downside of this of > course is that there could be multiple roundtrips between the client > and server when creating to get a unique URI. However careful choice > by the client should ensure this is not a very common situation. We > could even suggest a suitable hashing scheme in the draft so that > co-operating clients from different vendors could improve their > likelihood of avoiding a URI clash like this. > > Really the core problem we have here is the fact that some servers may > prefer to use a URI naming scheme that they define because they need > to operate on top of an existing calendar store with specific > requirements for naming resources. So we need to solve the redirect > problem in a way that has minimal impact for 'plain' WebDAV clients > and with minimum complexity for CalDAV clients that can expect a > redirect. > I think having a method in the spec to keep from doing a roundtrip would be a good idea as well. With WebDav, if the client wants to use the standard way of doing things, we won't be removing functionality. We are adding functionality that better helps our specific needs. If we add a way to set something and be done with it, then it will help "dumb down" the clients needed logic. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LHEVaZ024471 for ; Fri, 21 Jan 2005 09:14:32 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 523FB2CDB3C for ; Fri, 21 Jan 2005 18:14:25 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id EF0162CDB2D for ; Fri, 21 Jan 2005 18:14:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F09A8C.5090406@mozilla.org> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 18:14:00 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:14:33 -0000 On 21. Jan 2005, at 07:00 Uhr, Dan Mosedale wrote: >> This is actually something we do in our ZideStore server. You can >> either retrieve/store a collection as a single iCalendar entity >> containing all events or treat it like a WebDAV collection containing >> individual events. >> >> Good for compatibility with existing clients. > > This is an elegant semantic, because it allows people to advertise a > single URL as their calendar URL, and smart clients can access it as > CalDAV, while simpler ones can access it as WebDAV. Codifying this in > some way in the standard (as a MAY, perhaps) seems worthwhile to me. I won't object, but IMO this does not belong into the CalDAV discussion nor should be codified as some standard - lets just hope that this approach of calendar sharing is a thing of history very soon. Its just a 'smart' way to support two different approaches in one server. Our server also supports some WCAP and Exchange WebDAV API at the same time, that doesn't imply that CalDAV should specify the to ;-) BTW: there isn't a lot to specify, this is just regular HTTP GET/PUT with an text/calendar entity. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LH5faa023817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 09:05:42 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LH0N6E001913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 12:00:23 -0500 Date: Fri, 21 Jan 2005 12:05:40 -0500 From: Cyrus Daboo To: Scott Carr , ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: In-Reply-To: <41F128B6.9070600@progbits.com> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:05:45 -0000 Hi Scott, --On January 21, 2005 10:07:18 AM -0600 Scott Carr wrote: > The problem that I see in the this is, how do we know that the following: > > PUT /scarr/Calendar/1234.evt HTTP/1.1 > > Is not meant to edit 1234.evt if it already exists. The / could denote > an add operation to a CalDav based server. The return header would > include the filename that was generated for the new resource. Of course, > there are several ways we could do this, as well. > ETags and the If-Match/If-None-Match header can be used by clients to ensure expected behaviour when creating or editing existing resources - this is just standard http behaviour. e.g.: To create a new resource: PUT /calendar/cyrus/1234.ics HTTP/1.1 Host: localhost If-None-Match: * ... In the above request, if a resource already exists at the specified URI, then the server will return a '412 (Precondition Failed)' and the client will know to try another URI for create. To edit an existing resource: PUT /calendar/cyrus/1234.ics HTTP/1.1 Host: localhost If-Match: 1234etag-2005-01-21 ... In the above request, if the resource on the server has changed or been deleted, the server will respond with a '412 (Precondition Failed)' and the client will know to take remedial action. Right now this is what my implementation does: it generates a unique uri based on a hash of the component UID, SEQUENCE, DTSTAMP & RECURRENCE-ID, and tries to create that with the If-None-Match header present. If that fails with 412, we add a counter into the string being hashed, rehash it and try with that. The downside of this of course is that there could be multiple roundtrips between the client and server when creating to get a unique URI. However careful choice by the client should ensure this is not a very common situation. We could even suggest a suitable hashing scheme in the draft so that co-operating clients from different vendors could improve their likelihood of avoiding a URI clash like this. Really the core problem we have here is the fact that some servers may prefer to use a URI naming scheme that they define because they need to operate on top of an existing calendar store with specific requirements for naming resources. So we need to solve the redirect problem in a way that has minimal impact for 'plain' WebDAV clients and with minimum complexity for CalDAV clients that can expect a redirect. -- Cyrus Daboo X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LH4paa023760 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 09:04:54 -0800 In-Reply-To: <41F128B6.9070600@progbits.com> References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> <41F128B6.9070600@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C72A3AB-6BCE-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 09:04:44 -0800 To: Scott Carr X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 17:04:57 -0000 The problem with PUT doing an overwrite vs. only creating a new resource is solved by HTTP already with ETags and the If-None-Match header. There's a kind of paper which might help explain this: http://www.w3.org/1999/04/Editing/ Lisa On Jan 21, 2005, at 8:07 AM, Scott Carr wrote: > Julian Reschke wrote: > >> Scott Carr wrote: >> >>> I agree, post/redirect would be way too complex of a design for this. >>> >>> How about something like: >>> >>> -- New Entry -- >>> PUT /scarr/Calendar/ HTTP/1.1 >>> >>> Notice the last /, this should be a required item, so WebDav/CalDav >>> knows this is supposed to go into this directory as a generated >>> file. >> >> >> That breaks the HTTP semantics for PUT. If you send a representation >> for "/scarr/Calendar/", and the server accepts it (200/201), then >> that's the new content for "/scarr/Calendar/". >> > The problem that I see in the this is, how do we know that the > following: > > PUT /scarr/Calendar/1234.evt HTTP/1.1 > > Is not meant to edit 1234.evt if it already exists. The / could > denote an add operation to a CalDav based server. The return header > would include the filename that was generated for the new resource. > Of course, there are several ways we could do this, as well. > > -- Example 1 -- > PUT /scarr/Calendar/new HTTP/1.1 > > This would visually denote that a new operation is requested by the > client. The server would then look at the contents being added, and > would be able to deside what filename and extension to use. > > -- Example 2 -- > PUT /scarr/Calendar/1234.evt HTTP/1.1 > X-Operation: new > > Here, we would be able to see that a new operation is requested, and > the server could change the filename as needed. I personally like the > 1st example, because it is one line that we have to look at. > > -- Problem with Redirection -- > The problem I see with redirection, is that it would require two > different requests to the server to get something added. If you > multiply that by n number of users, it could put a big strain on the > server. The company where I work has 100 employees, and they use > scheduling constantly. If you take one person creating a meeting > request for 10 people, and each of those requests having to do 2 > operations potentially to get something saved, it adds up quick, and > that is only one meeting request. > > -- > Scott Carr > OpenOffice.org > Documentation Co-Lead > http://documentation.openoffice.org > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LGu0aa023424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jan 2005 08:56:05 -0800 In-Reply-To: <0147A834B4CF6EFB7750ED80@ninevah.local> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> <0147A834B4CF6EFB7750ED80@ninevah.local> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F6D47F1-6BCD-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 08:55:52 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Dan Mosedale , ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 16:56:08 -0000 I was hoping Dan Winship would write a draft explaining how a server should support both level 1 and level 0 approaches together, Dan are you out there and are you still interested? This would be partly specification (knowing which URL to use for the level 0 version) and partly requirements for how not to screw up CalDAV clients. E.g. A server MAY support downloading the full calendar as a single resource without allowing upload -- a read-only 'level 0' calendar. This can be useful for CalDAV clients to publish their calendars through the CalDAV server to be consumed by clients that do not support CalDAV but know how to interpret an entire calendar in a single iCalendar-formatted document available as a HTTP resource. If a server wishes to support a read-write 'level 0' calendar, in addition to supporting CalDAV clients, these are the requirements for how to do that: - The server MUST split up the full calendar whenever uploaded and attempt to apply each changed event one by one, matching UIDs to existing events. The server MUST NOT cause an existing event to change if the data in it is unchanged. - The server MUST respect locks on existing events as it goes through and applies these changes. ... etc... I think a fair bit of thought needs to go into this to do it right, including understanding how writing a 'level 1' calendar works in practice, and understanding how to handle the UIDs and recurrances and stuff. Lisa On Jan 21, 2005, at 7:46 AM, Cyrus Daboo wrote: > Hi Mike, > > --On January 21, 2005 12:10:26 AM -0800 Mike Shaver > wrote: > >>> This is an elegant semantic, because it allows people to advertise a >>> single URL as their calendar URL, and smart clients can access it as >>> CalDAV, while simpler ones can access it as WebDAV. Codifying this >>> in >>> some way in the standard (as a MAY, perhaps) seems worthwhile to me. >> >> This is something that I've been pushing for as "CalDAV Level Zero" >> for a few months now. I'm glad to see it gathering support! >> > > The problem is the 'whole calendar' 'level 0' approach will not > interact very well with the 'per component' 'level 1' (current design) > scheme. The biggest problem is 'level 0' clients uploading an entire > calendar with only one changed component - in the worst case the > server ends up overwriting all the existing components, changing the > ETags, and forcing level 1 clients to resync the entire set of events > - this is bad for 'level 1'. In the best case the server has to do a > lot more work by trying to sync each component in the 'level 0' PUT > with each existing component in the separate resource collection and > only overwrite those that have changed, are new or ones deleted. This > adds a lot more complexity to the server. > > The bottom line is I (personally) am not adverse to a 'level 0' type > solution but it MUST NOT have any negative impact on 'level 1'. The > other issue is whether wereally want to contin ue to promote 'level 0' > type access when we believe (at least I do) that 'level 1' is > potentially much superior. > > In terms of how to do it, as Julian points out, you cannot use PUT on > the collection. What I would suggest is that we define a 'standard' > resource name in each calendar collection that represents the entire > set of components, e.g. the resource 'TOTALCALENDAR' inside the > calendar collection: > , and > then PUT/GET on that does 'level 0' behaviour. The alternative would > be to have a property on the calendar collection that specifies a > server-defined URI that can be used for 'level 0' operations and can > be easily discovered, and would remove the need to have a fixed > pre-defined resource name. > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from avgateway01.corp.dccusa.com ([12.107.242.100]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0LGeKaZ022340 for ; Fri, 21 Jan 2005 08:40:20 -0800 Received: from 10.1.1.101 by avgateway01.corp.dccusa.com (InterScan E-Mail VirusWall NT); Fri, 21 Jan 2005 10:09:14 -0600 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 10:08:47 -0600 Message-ID: <41F128B6.9070600@progbits.com> Date: Fri, 21 Jan 2005 10:07:18 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <41F0BBDB.3030608@gmx.de> In-Reply-To: <41F0BBDB.3030608@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 16:08:47.0577 (UTC) FILETIME=[7D21DC90:01C4FFD3] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 16:40:22 -0000 Julian Reschke wrote: > Scott Carr wrote: > >> I agree, post/redirect would be way too complex of a design for this. >> >> How about something like: >> >> -- New Entry -- >> PUT /scarr/Calendar/ HTTP/1.1 >> >> Notice the last /, this should be a required item, so WebDav/CalDav >> knows this is supposed to go into this directory as a generated file. > > > That breaks the HTTP semantics for PUT. If you send a representation > for "/scarr/Calendar/", and the server accepts it (200/201), then > that's the new content for "/scarr/Calendar/". > The problem that I see in the this is, how do we know that the following: PUT /scarr/Calendar/1234.evt HTTP/1.1 Is not meant to edit 1234.evt if it already exists. The / could denote an add operation to a CalDav based server. The return header would include the filename that was generated for the new resource. Of course, there are several ways we could do this, as well. -- Example 1 -- PUT /scarr/Calendar/new HTTP/1.1 This would visually denote that a new operation is requested by the client. The server would then look at the contents being added, and would be able to deside what filename and extension to use. -- Example 2 -- PUT /scarr/Calendar/1234.evt HTTP/1.1 X-Operation: new Here, we would be able to see that a new operation is requested, and the server could change the filename as needed. I personally like the 1st example, because it is one line that we have to look at. -- Problem with Redirection -- The problem I see with redirection, is that it would require two different requests to the server to get something added. If you multiply that by n number of users, it could put a big strain on the server. The company where I work has 100 employees, and they use scheduling constantly. If you take one person creating a meeting request for 10 people, and each of those requests having to do 2 operations potentially to get something saved, it adds up quick, and that is only one meeting request. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0LGUYaa021700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2005 08:30:37 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j0LFfS6E032571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2005 10:41:29 -0500 Date: Fri, 21 Jan 2005 10:46:45 -0500 From: Cyrus Daboo To: Mike Shaver , Dan Mosedale Subject: Re: [Ietf-caldav] Creating Items [ideas] Message-ID: <0147A834B4CF6EFB7750ED80@ninevah.local> In-Reply-To: References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 16:30:40 -0000 Hi Mike, --On January 21, 2005 12:10:26 AM -0800 Mike Shaver wrote: >> This is an elegant semantic, because it allows people to advertise a >> single URL as their calendar URL, and smart clients can access it as >> CalDAV, while simpler ones can access it as WebDAV. Codifying this in >> some way in the standard (as a MAY, perhaps) seems worthwhile to me. > > This is something that I've been pushing for as "CalDAV Level Zero" > for a few months now. I'm glad to see it gathering support! > The problem is the 'whole calendar' 'level 0' approach will not interact very well with the 'per component' 'level 1' (current design) scheme. The biggest problem is 'level 0' clients uploading an entire calendar with only one changed component - in the worst case the server ends up overwriting all the existing components, changing the ETags, and forcing level 1 clients to resync the entire set of events - this is bad for 'level 1'. In the best case the server has to do a lot more work by trying to sync each component in the 'level 0' PUT with each existing component in the separate resource collection and only overwrite those that have changed, are new or ones deleted. This adds a lot more complexity to the server. The bottom line is I (personally) am not adverse to a 'level 0' type solution but it MUST NOT have any negative impact on 'level 1'. The other issue is whether wereally want to contin ue to promote 'level 0' type access when we believe (at least I do) that 'level 1' is potentially much superior. In terms of how to do it, as Julian points out, you cannot use PUT on the collection. What I would suggest is that we define a 'standard' resource name in each calendar collection that represents the entire set of components, e.g. the resource 'TOTALCALENDAR' inside the calendar collection: , and then PUT/GET on that does 'level 0' behaviour. The alternative would be to have a property on the calendar collection that specifies a server-defined URI that can be used for 'level 0' operations and can be easily discovered, and would remove the need to have a fixed pre-defined resource name. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j0L8N0aZ028565 for ; Fri, 21 Jan 2005 00:23:01 -0800 Received: (qmail invoked by alias); 21 Jan 2005 08:22:54 -0000 Received: from pD9E5152F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.21.47) by mail.gmx.net (mp022) with SMTP; 21 Jan 2005 09:22:54 +0100 X-Authenticated: #1915285 Message-ID: <41F0BBDB.3030608@gmx.de> Date: Fri, 21 Jan 2005 09:22:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Carr Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> In-Reply-To: <41F03EAC.4060108@progbits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 08:23:03 -0000 Scott Carr wrote: > Continuation of this post: [Thanks Mike for pointing me to it] > http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html > > > I agree, post/redirect would be way too complex of a design for this. > > How about something like: > > -- New Entry -- > PUT /scarr/Calendar/ HTTP/1.1 > > Notice the last /, this should be a required item, so WebDav/CalDav > knows this is supposed to go into this directory as a generated file. That breaks the HTTP semantics for PUT. If you send a representation for "/scarr/Calendar/", and the server accepts it (200/201), then that's the new content for "/scarr/Calendar/". > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: mike.shaver@gmail.com X-Envelope-To: Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0L8AXaZ027377 for ; Fri, 21 Jan 2005 00:10:34 -0800 Received: by wproxy.gmail.com with SMTP id 36so83192wra for ; Fri, 21 Jan 2005 00:10:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Rl2AM5PJbMfJ6bdulw1IUWS8lrEDkz165LL8VJiwVIZuroYmIApMKSs7Yf38JaH9CfzMOfjgQL/x9L5cauiibSf9NrA/G/ZI3kj4yD9CjUpljod8gEBg5lvAjH9iwbKVejdUtQY4FUOrNjsMVU5q9H+1cR40Vu+q+Ugi48BBJto= Received: by 10.54.49.20 with SMTP id w20mr10972wrw; Fri, 21 Jan 2005 00:10:26 -0800 (PST) Received: by 10.54.48.40 with HTTP; Fri, 21 Jan 2005 00:10:26 -0800 (PST) Message-ID: Date: Fri, 21 Jan 2005 00:10:26 -0800 From: Mike Shaver To: Dan Mosedale Subject: Re: [Ietf-caldav] Creating Items [ideas] In-Reply-To: <41F09A8C.5090406@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> <41F09A8C.5090406@mozilla.org> X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Mike Shaver 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, 21 Jan 2005 08:10:36 -0000 On Thu, 20 Jan 2005 22:00:44 -0800, Dan Mosedale wrote: > Helge Hess wrote: > > >> Another thing that PUT on a collection could do would be to define a > >> body *for the collection*. > > > > > > This is actually something we do in our ZideStore server. You can > > either retrieve/store a collection as a single iCalendar entity > > containing all events or treat it like a WebDAV collection containing > > individual events. > > > > Good for compatibility with existing clients. > > This is an elegant semantic, because it allows people to advertise a > single URL as their calendar URL, and smart clients can access it as > CalDAV, while simpler ones can access it as WebDAV. Codifying this in > some way in the standard (as a MAY, perhaps) seems worthwhile to me. This is something that I've been pushing for as "CalDAV Level Zero" for a few months now. I'm glad to see it gathering support! Mike X-Envelope-From: dmose@mozilla.org X-Envelope-To: Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0L61aaZ016718 for ; Thu, 20 Jan 2005 22:01:36 -0800 Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id j0L61CVF044349; Thu, 20 Jan 2005 22:01:30 -0800 (PST) (envelope-from dmose@mozilla.org) Received: from [192.168.1.102] (dsl081-050-187.sfo1.dsl.speakeasy.net [64.81.50.187]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j0L60bOv002085; Thu, 20 Jan 2005 22:00:37 -0800 (PST) (envelope-from dmose@mozilla.org) Message-ID: <41F09A8C.5090406@mozilla.org> Date: Thu, 20 Jan 2005 22:00:44 -0800 From: Dan Mosedale User-Agent: Mozilla Thunderbird 0.6+ (X11/20041214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> In-Reply-To: <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Thu, 20 Jan 2005 22:26:58 -0800 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 06:01:38 -0000 Helge Hess wrote: >> Another thing that PUT on a collection could do would be to define a >> body *for the collection*. > > > This is actually something we do in our ZideStore server. You can > either retrieve/store a collection as a single iCalendar entity > containing all events or treat it like a WebDAV collection containing > individual events. > > Good for compatibility with existing clients. This is an elegant semantic, because it allows people to advertise a single URL as their calendar URL, and smart clients can access it as CalDAV, while simpler ones can access it as WebDAV. Codifying this in some way in the standard (as a MAY, perhaps) seems worthwhile to me. Dan X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0L007aZ022910 for ; Thu, 20 Jan 2005 16:00:07 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 18:00:41 -0600 Message-ID: <41F04600.3060205@progbits.com> Date: Thu, 20 Jan 2005 18:00:00 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Creating Items [ideas] References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> In-Reply-To: <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 00:00:41.0030 (UTC) FILETIME=[3EDA2E60:01C4FF4C] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 21 Jan 2005 00:00:10 -0000 Lisa Dusseault wrote: > That's kind of an elegant solution, since as yet PUT isn't defined on > a collection. > > Another thing that PUT on a collection could do would be to define a > body *for the collection*. There's no reason why a collection can't > itself have a body -- presumably that would make the behavior of GET > on a collection defined, which is also at the moment undefined. > > To answer this whole problem, however, we first need to make clear > our goal. > - Is our goal for new CalDAV clients to be able to create items > without selecting a URL, to make the server do the work of avoiding > URL conflicts with existing resources? For that problem, we have a > nearly unlimited set of workable solutions, including POST, > redirects, PUT request headers, new verbs like CREATE, etc. I would suggest defining the behavior such that if a URL is there then it is up to the Client to make sure it is unique. Otherwise an error occurs. If it is a directory store with no filename then the CalDav implementation would create the file and respond in the header. This solution seems like the best of both worlds. It seems like asking alot of a client to require they keep track of what's on a server, but if the Spec defines a way around this, we would probably get more buyin from Server developers. BTW, I am talking about this after looking over the Slide implementation. I have talked to James about the implementation and have started putting things together to start building the extensions. > > - Is our goal for existing WebDAV clients to be able to > successfully create items in a server which wants to control > precisely the URL space? Such that a client like WebDAV FS on a Mac > could use its existing code to synchronize a local directory > containing .ics files by uploading each of them with PUT? In that > case, we can't specify any new client request syntax because we > already know what request those clients send - a PUT which includes > the exact URL to be created. See above. The implementation would require a client to handle Uniqueness if it specifies a complete URL. This also has ramnifications if there are multiple people adding records, because the client could not know that that filename has already been used until after it tries to save. But, if the server has a way to handle unspecified filenames in the directory, and a way of notifying the Client after it is complete, then this should fix most issues, and puts ownership on the server, which is where I think it should be. In this type of implementation, anyway. > > Some servers find it easy to assign whatever URL the client chooses, > but some implementors would find that much more of a challenge -- > server implementors should speak up, here, about the constraints and > goals. It may be a little more difficult, but it is much easier to fix the server than it is to have each new software client do things the same way. > > Lisa > > On Jan 20, 2005, at 3:28 PM, Scott Carr wrote: > >> Continuation of this post: [Thanks Mike for pointing me to it] >> http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/ >> 000102.html >> >> I agree, post/redirect would be way too complex of a design for this. >> >> How about something like: >> >> -- New Entry -- >> PUT /scarr/Calendar/ HTTP/1.1 >> >> Notice the last /, this should be a required item, so WebDav/CalDav >> knows this is supposed to go into this directory as a generated file. >> >> Then the WebDav server could be extended to Generate the filename >> itself. For now CalDav, could extend the Put method to generate a >> filename. This would be doable, and it also makes for future use of >> the same feature. Thinking about doing a Contact directory, and a >> Notes directory the same basic way, in the future. >> >> The response would include a Header item that tells the client the >> generated name. This would need to be put in the spec as well. >> >> -- Edited Entry -- >> PUT /scarr/Calendar/msg01234.evt HTTP/1.1 >> >> Here there wouldn't be a problem because the client already knows >> the name of the file to save with. >> >> Does this make sense? This sounds like a good extension to WebDav >> in general. >> >> -- >> Scott Carr >> OpenOffice.org >> Documentation Co-Lead >> http://documentation.openoffice.org >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KNxPaZ022812 for ; Thu, 20 Jan 2005 15:59:26 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D7FEA2CD8FD for ; Fri, 21 Jan 2005 00:59:13 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 84C232CD7A2 for ; Fri, 21 Jan 2005 00:59:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> References: <41F03EAC.4060108@progbits.com> <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <523997BA-6B3F-11D9-AD40-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Fri, 21 Jan 2005 00:59:29 +0100 To: ietf-caldav X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 23:59:28 -0000 On Jan 21, 2005, at 0:43, Lisa Dusseault wrote: > That's kind of an elegant solution, since as yet PUT isn't defined on > a collection. Really? I think PUT is defined generically on any URL and has pretty clear and defined semantics (but would need to look this up to prove it). Requiring the trailing "/" would be against all HTTP URL resource rules unless I'm missing something very crucial. > Another thing that PUT on a collection could do would be to define a > body *for the collection*. This is actually something we do in our ZideStore server. You can either retrieve/store a collection as a single iCalendar entity containing all events or treat it like a WebDAV collection containing individual events. Good for compatibility with existing clients. > Is our goal for new CalDAV clients to be able to create items without > selecting a URL, to make the server do the work of avoiding URL > conflicts with existing resources? For that problem, we have a nearly > unlimited set of workable solutions, including POST, redirects, PUT > request headers, new verbs like CREATE, etc. There are two issues at hand: a) there are servers which enforce maintenance of URLs, this needs to be supported b) the client will need to write to some 'creation' URL For a) I still think that PUT + 201/location is the best possible solution. For b) - I think the if-none-match:* solution is pretty much ok. The client can invent arbitary names for new resources and the server will tell him in case the name is already taken. > - Is our goal for existing WebDAV clients to be able to successfully > create items in a server which wants to control precisely the URL > space? I don't think that this needs to be a primary goal though this is pretty well supported by PUT+location. > Such that a client like WebDAV FS on a Mac could use its existing code > to synchronize a local directory containing .ics files by uploading > each of them with PUT? Would work with the PUT+location solution. The new local item would disappear and a new server item would come up. The location is only relevant for clients which need to maintain "open windows". Generic WebDAV synchronisation should work without issues. > In that case, we can't specify any new client request syntax because > we already know what request those clients send - a PUT which includes > the exact URL to be created. Yes. I would prefer to keep it like that. > Some servers find it easy to assign whatever URL the client chooses, > but some implementors would find that much more of a challenge -- > server implementors should speak up, here, about the constraints and > goals. First case doesn't work. The server needs to check for existing URLs in any case unless the client locks the whole collection. The latter - yes, I speak up. We need the redirect (or some other solution) to allow the server maintain IDs after initial creation. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [10.0.1.12] (ip01.oracle.com [148.87.53.130]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KNh9aa019740 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Jan 2005 15:43:10 -0800 In-Reply-To: <41F03EAC.4060108@progbits.com> References: <41F03EAC.4060108@progbits.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0950C253-6B3D-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating Items [ideas] Date: Thu, 20 Jan 2005 15:43:07 -0800 To: Scott Carr X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 23:43:10 -0000 That's kind of an elegant solution, since as yet PUT isn't defined on a collection. Another thing that PUT on a collection could do would be to define a body *for the collection*. There's no reason why a collection can't itself have a body -- presumably that would make the behavior of GET on a collection defined, which is also at the moment undefined. To answer this whole problem, however, we first need to make clear our goal. - Is our goal for new CalDAV clients to be able to create items without selecting a URL, to make the server do the work of avoiding URL conflicts with existing resources? For that problem, we have a nearly unlimited set of workable solutions, including POST, redirects, PUT request headers, new verbs like CREATE, etc. - Is our goal for existing WebDAV clients to be able to successfully create items in a server which wants to control precisely the URL space? Such that a client like WebDAV FS on a Mac could use its existing code to synchronize a local directory containing .ics files by uploading each of them with PUT? In that case, we can't specify any new client request syntax because we already know what request those clients send - a PUT which includes the exact URL to be created. Some servers find it easy to assign whatever URL the client chooses, but some implementors would find that much more of a challenge -- server implementors should speak up, here, about the constraints and goals. Lisa On Jan 20, 2005, at 3:28 PM, Scott Carr wrote: > Continuation of this post: [Thanks Mike for pointing me to it] > http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/ > 000102.html > > I agree, post/redirect would be way too complex of a design for this. > > How about something like: > > -- New Entry -- > PUT /scarr/Calendar/ HTTP/1.1 > > Notice the last /, this should be a required item, so WebDav/CalDav > knows this is supposed to go into this directory as a generated file. > > Then the WebDav server could be extended to Generate the filename > itself. For now CalDav, could extend the Put method to generate a > filename. This would be doable, and it also makes for future use of > the same feature. Thinking about doing a Contact directory, and a > Notes directory the same basic way, in the future. > > The response would include a Header item that tells the client the > generated name. This would need to be put in the spec as well. > > -- Edited Entry -- > PUT /scarr/Calendar/msg01234.evt HTTP/1.1 > > Here there wouldn't be a problem because the client already knows the > name of the file to save with. > > Does this make sense? This sounds like a good extension to WebDav in > general. > > -- > Scott Carr > OpenOffice.org > Documentation Co-Lead > http://documentation.openoffice.org > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: charles@thewybles.com X-Envelope-To: Received: from mail1.pds.com (mail1.pds.com [192.245.142.130]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KNblaZ019371 for ; Thu, 20 Jan 2005 15:37:47 -0800 Received: from morris.pds.com (morris.pds.com [10.1.1.1]) by mail1.pds.com (NRW-Mail) with ESMTP id D5EEA38490 for ; Thu, 20 Jan 2005 15:35:21 -0800 (PST) Received: from [10.1.50.28] (charles [10.1.50.28]) by morris.pds.com (NRW-Mail) with ESMTP id D93241E38 for ; Thu, 20 Jan 2005 15:37:46 -0800 (PST) Message-ID: <41F03F5E.4030700@thewybles.com> Date: Thu, 20 Jan 2005 15:31:42 -0800 From: Charles N Wyble User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.762 (**) DNS_FROM_RFC_BOGUSMX, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] CalDAV Server Project X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 23:37:50 -0000 Hello Everyone,

    I want to bring to your attention a CalDAV server project of interest. It is part of the open connector (www.openconnector.org) project and shows promise. From the web page (http://openconnector.org/caldav/)......

The goal of this sub-project is to develop a prototype CalDAV server derived from the Apache Slide WebDAV server and a prototype client library functions developed using Microsoft XML parser.

Hope someone finds this interesting/helpful. 

-- 
Charles N Wyble
Homepage: http://www.thewybles.com/~charles
Blog: http://jackshck.livejournal.com
Developer/Consultant. 30.00 an hour is my fee.
X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KNTpaZ018443 for ; Thu, 20 Jan 2005 15:29:51 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 17:30:24 -0600 Message-ID: <41F03EAC.4060108@progbits.com> Date: Thu, 20 Jan 2005 17:28:44 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2005 23:30:24.0718 (UTC) FILETIME=[043EF6E0:01C4FF48] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Creating Items [ideas] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 23:29:54 -0000 Continuation of this post: [Thanks Mike for pointing me to it] http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html I agree, post/redirect would be way too complex of a design for this. How about something like: -- New Entry -- PUT /scarr/Calendar/ HTTP/1.1 Notice the last /, this should be a required item, so WebDav/CalDav knows this is supposed to go into this directory as a generated file. Then the WebDav server could be extended to Generate the filename itself. For now CalDav, could extend the Put method to generate a filename. This would be doable, and it also makes for future use of the same feature. Thinking about doing a Contact directory, and a Notes directory the same basic way, in the future. The response would include a Header item that tells the client the generated name. This would need to be put in the spec as well. -- Edited Entry -- PUT /scarr/Calendar/msg01234.evt HTTP/1.1 Here there wouldn't be a problem because the client already knows the name of the file to save with. Does this make sense? This sounds like a good extension to WebDav in general. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: mike.shaver@gmail.com X-Envelope-To: Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KKrZaZ017449 for ; Thu, 20 Jan 2005 12:53:36 -0800 Received: by wproxy.gmail.com with SMTP id 69so61327wri for ; Thu, 20 Jan 2005 12:53:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Zkc65ko3uMjabgFy62cqHUOoxzA03t0tuEHJ3vxwUfSE167/OVxg7FVyvE5PWthAcuvXsBSklkQF7adPBoklDaj/cMQohMr3gnZid9N4IBiQZaRPM2QCFZSa2ustMySHhBbvsQg0kKcdQ6sfj+B34cz0lQeHyuobLq3PR5C1K9A= Received: by 10.54.28.64 with SMTP id b64mr272033wrb; Thu, 20 Jan 2005 12:53:23 -0800 (PST) Received: by 10.54.48.40 with HTTP; Thu, 20 Jan 2005 12:53:22 -0800 (PST) Message-ID: Date: Thu, 20 Jan 2005 12:53:22 -0800 From: Mike Shaver To: Scott Carr Subject: Re: [Ietf-caldav] Event Naming in WebDav In-Reply-To: <41F00730.5050409@progbits.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F00730.5050409@progbits.com> X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Mike Shaver 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, 20 Jan 2005 20:53:37 -0000 On Thu, 20 Jan 2005 13:32:00 -0600, Scott Carr wrote: > Are clients going to have to keep track of Resource naming themselves? > > When an item is placed in the WebDav repository, is the client going to > be required to specify a unique filename to save the event to? Still an open issue. This thread has some of the prior discussion on the topic: http://lists.osafoundation.org/pipermail/ietf-caldav/2004-October/000102.html Mike X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0KJWWaZ009633 for ; Thu, 20 Jan 2005 11:32:33 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 13:33:05 -0600 Message-ID: <41F00730.5050409@progbits.com> Date: Thu, 20 Jan 2005 13:32:00 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2005 19:33:05.0718 (UTC) FILETIME=[DD23FD60:01C4FF26] X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Event Naming in WebDav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 19:32:36 -0000 Are clients going to have to keep track of Resource naming themselves? When an item is placed in the WebDav repository, is the client going to be required to specify a unique filename to save the event to? -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from progbits.com (www.progbits.com [69.17.124.65]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0K2pxaZ032434 for ; Wed, 19 Jan 2005 18:51:59 -0800 Received: from mail.progbits.com (localhost [127.0.0.1]) by progbits.com (Postfix) with ESMTP id D638C166C; Wed, 19 Jan 2005 20:51:54 -0600 (CST) Received: from 69.17.124.67 (SquirrelMail authenticated user scarr); by mail.progbits.com with HTTP; Wed, 19 Jan 2005 20:51:54 -0600 (CST) Message-ID: <34082.69.17.124.67.1106189514.squirrel@69.17.124.67> In-Reply-To: References: <33732.69.17.124.67.1106111444.squirrel@69.17.124.67> Date: Wed, 19 Jan 2005 20:51:54 -0600 (CST) From: "Scott Carr" To: ietf-caldav@osafoundation.org User-Agent: SquirrelMail/1.4.3-RC1 X-Mailer: SquirrelMail/1.4.3-RC1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Re: CalDav Draft X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 Jan 2005 02:52:01 -0000 Moving the discussion to the list. Thanks, Lisa for letting me know about the list. Comments inline. Lisa Dusseault said: > Hi Scott, > > We're removing Scheduling from CalDAV in the -05 draft, which is in > progress. So we probably won't finalize the design of scheduling quite > yet, but this is an interesting approach. Is the scheduling being removed so the draft will be easier to approve? .. or is there some other reason? > > The problem of keeping the Originator's event and the Attendee's event > synchronized is a very tough one. In the worst case, the Originator is > on one CalDAV server, and the Attendee is on a different CalDAV server, > and there's no way for the two servers to access each other, or for > either client to access the other person's server (both servers might > be behind different firewalls, accessible via VPN). So there is a UID > (defined in the iCalendar specification) which might help depending on > exactly what the use case is. We probably need to add some language on > that. But, in the worst case, how are the events going to get to their respective attendees anyway? Would a directory that is not inside normal ACL priviledge work? Something like SMTP where there is no password to send an event request. > > On Jan 18, 2005, at 9:10 PM, Scott Carr wrote: > >> http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html >> >> Section 9.3 Acting on iTip Messages >> >> You have in this section a TODO entry. >> >> With an iTip acceptance, would it be a good idea to have an AcceptEvent >> method? If we have an iTip store, wouldn't we have to know what state >> a >> specific iTip is in at any given point? With an AcceptEvent method the >> server would basically create the event in the users store, and set the >> original message to an Accepted state, or delete the iTip message >> totally. >> >> We would also have to send an iTip or some other message to the >> Originators event store, to let them know that the user accepted the >> event. All this could be handled by the AcceptEvent method. >> >> Another issue I can see with this is how would we keep the event on the >> Originators box in sync with the event in the Attendees. Is there an >> Event ID that would co-exist in each users event store? If so, we >> would >> need to be able to initiate change requests across user storage >> boundaries. >> -- Scott Carr OpenOffice.org Documentation Co-Lead X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0HJDNaa004008 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 17 Jan 2005 11:13:25 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j0HJCmXB004484 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Jan 2005 11:12:50 -0800 Message-ID: <41EC0E30.6020109@Royer.com> Date: Mon, 17 Jan 2005 12:12:48 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Lennox References: <41EAF475.3060407@Royer.com> <16875.63611.998914.411492@cnr.cs.columbia.edu> In-Reply-To: <16875.63611.998914.411492@cnr.cs.columbia.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108000109080403050606" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org, CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] Re: IANA Time Zone Registration X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2005 19:13:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030108000109080403050606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you - I just sent the email. Jonathan Lennox wrote: > On Sunday, January 16 2005, "Doug Royer" wrote to "ietf-calendar@imc.org, ietf-calsify@osafoundation.org, CalDAV DevList" saying: > > >>A couple of years ago there was talk on the CALSCH mailing list >>to have an IANA time zone registration process. I have submitted >>a proposal for that registry to the IETF. > > > This proposal should also be shared with the TZ mailing list, > . > > I note that your list of time zone names is out of date with respect > to the current version of tzdata (2005b). > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030108000109080403050606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMTE3MTkxMjQ4WjAjBgkqhkiG9w0BCQQxFgQUZcNCdo0bmDkYRSCSameU QhD7ivUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAmNKZOBnr/xRMfLWzag8+wXJGSGYeVom2FfR6aaU+2OQZU8J0ec5spUM0q/aOOlhn V6/1NN8K2PLPlGSpSFA46I8nmq810VTw6SmGXt+ZoKTsTpBAN3Mp45FO7olSPFdbBWMTGS2z QQSx3m82MI46+GiFkZXFHE9YbrBSLoP1phi/3GEJnmcrBcSVuI/qldrECPDngkze7SClaQq0 BjZh1bx5g67YKb94pxLvyXmNg8Wl0s9dsoRw+VdCkJc0EPQCF2pvf5uMkjJKDdgmVryIwVFV NBgYyHKvDulFkXiOOBvsGkD4nPLk1hv9TNmCeck+QPzgIOnEZanOPouJ0VrN3QAAAAAAAA== --------------ms030108000109080403050606-- X-Envelope-From: lennox@cnr.cs.columbia.edu Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0HHeGaa029136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2005 09:40:17 -0800 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j0HHeCrM031686; Mon, 17 Jan 2005 12:40:12 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j0HHeCbE031683; Mon, 17 Jan 2005 12:40:12 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16875.63611.998914.411492@cnr.cs.columbia.edu> Date: Mon, 17 Jan 2005 12:40:11 -0500 To: Doug Royer In-Reply-To: <41EAF475.3060407@Royer.com> References: <41EAF475.3060407@Royer.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Thu, 20 Jan 2005 22:27:22 -0800 Cc: ietf-calsify@osafoundation.org, CalDAV DevList , "ietf-calendar@imc.org" Subject: [Ietf-caldav] Re: IANA Time Zone Registration X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2005 17:40:20 -0000 On Sunday, January 16 2005, "Doug Royer" wrote to "ietf-calendar@imc.org, ietf-calsify@osafoundation.org, CalDAV DevList" saying: > A couple of years ago there was talk on the CALSCH mailing list > to have an IANA time zone registration process. I have submitted > a proposal for that registry to the IETF. This proposal should also be shared with the TZ mailing list, . I note that your list of time zone names is out of date with respect to the current version of tzdata (2005b). -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0GNAqaa004411 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sun, 16 Jan 2005 15:10:53 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j0GNAjXB013606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 16 Jan 2005 15:10:48 -0800 Message-ID: <41EAF475.3060407@Royer.com> Date: Sun, 16 Jan 2005 16:10:45 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , ietf-calsify@osafoundation.org, CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040804090802090308080209" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-caldav] IANA Time Zone Registration X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2005 23:10:55 -0000 This is a cryptographically signed message in MIME format. --------------ms040804090802090308080209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ] A couple of years ago there was talk on the CALSCH mailing list to have an IANA time zone registration process. I have submitted a proposal for that registry to the IETF. A copy can be found at: http://inet-consulting.com/draft-royer-timezone-registry-00.txt And an HTML version: http://inet-consulting.com/draft-royer-timezone-registry-00.html I am adding the POLYGON property targeted for the -01 version that has an ADD/DELETE parameter to allow for the optional inclusion of latitude/longitude geographic areas to be included that include (add) and exclude (delete) areas from the time zone geographic region (again from the CALSCH mailing list discussions). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040804090802090308080209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMTE2MjMxMDQ1WjAjBgkqhkiG9w0BCQQxFgQU28qXQ3/WDhyyxowMM5fY PDQDNDEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAoXoh/+6muQiZ2iqZ0GvWmcM5ttOmYHnHLM/jcKYme+RNzKdb2Y/SnBk180CPOISr 9RhlrCUmWazcfPeSYwaSJKhUz0k40+ntVklg2EzcyAvBDFoOztGfMAF/Wyd3p7s/hPsHGFvk ekmhk/nU7BqqWdDYDCF6LxPwLT92JDeQn4jODGr3BQfcPyvxznb6JUxIxjP34EM6bUwbYfXO gbXDKdSl9aT4Xcx1QO8ZyrGMoRGpsfCbNdSjYi36tR6TQVACOdndY+8cOCnOwQja7eVXWGkA al+EH9k7xzlNSYqjW7q2tM9naLcxnxGAwUqZeRuJ+ssUDTuzpt+7uGwWvpGAhAAAAAAAAA== --------------ms040804090802090308080209-- X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0GLC8aa032073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sun, 16 Jan 2005 13:12:09 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j0GLBiXB012077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 16 Jan 2005 13:11:46 -0800 Message-ID: <41EAD88F.1030601@Royer.com> Date: Sun, 16 Jan 2005 14:11:43 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , ietf-calsify@osafoundation.org, CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010605090304020907010903" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-caldav] draft-royer-ical-basic-01.txt - sent to IETF X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2005 21:12:11 -0000 This is a cryptographically signed message in MIME format. --------------ms010605090304020907010903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I send -01 of iCal-Basis to the IETF. It fixed some problems and typos that were sent to me and the lists. It also deprecates DTEND and replaced the examples and ABNF with DURATION. Copy at: http://inet-consulting.com/draft-royer-ical-basic-01.txt And HTML version at: http://inet-consulting.com/draft-royer-ical-basic-01.html -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010605090304020907010903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMTE2MjExMTQzWjAjBgkqhkiG9w0BCQQxFgQUFb6XvIwXNGn9yHKiY5io /6m4WWIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAp4NTaawdYGULqlo+0N8it4EqpLVr+TZVBZNPmosMcC4pcL0pMNWlJrzL4NOZW3MG vSZxaUtcrd/2oyoDX6kM19TXD423na24SX3tyvSlgDDvEXFbGKr8WL9jM6LxBIw96sdtDJmi euz5GghdfWlk4qFt4oIwXaEzTxZCl4ZfQuIW4aMFGwCLpOrEIBwbChN6e8hsE2vCLQKIsL6c FObH6AXdmLMRO5g58CyheMGrRqjrr6jmlL2C240HMv1Zrls6Frw4J79t01oUHoF2Wh6vBBqL R2iLbMBbWTzNuRyQRrkmJ1Bmo+H1Oddo9/lL8n0Lk0xh+naGE9tn5WLQHnJFVAAAAAAAAA== --------------ms010605090304020907010903-- X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0AL6Eaa027683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 10 Jan 2005 13:06:16 -0800 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j0AL62eW002729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 Jan 2005 13:06:05 -0800 Message-ID: <41E2EE39.3000404@Royer.com> Date: Mon, 10 Jan 2005 14:06:01 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , ietf-calsify@osafoundation.org, CalDAV DevList Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040000010404040105070301" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-royer-ical-basic-00.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 21:06:19 -0000 This is a cryptographically signed message in MIME format. --------------ms040000010404040105070301 Content-Type: multipart/mixed; boundary="------------090801060904050606000008" This is a multi-part message in MIME format. --------------090801060904050606000008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-royer-ical-basic-00.txt Date: Mon, 03 Jan 2005 15:40:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Basic Internet Calendaring and Scheduling Core Object Specification (iCalendar Basic) Author(s) : D. Royer Filename : draft-royer-ical-basic-00.txt Pages : 104 Date : 2005-1-3 This is the second release of a iCalendar. After having learned from RFC-2445. This document represents the common objects needed for calendaring. VTODO, VJOURNAL, VTIMEZONE, recurrence rules, and scheduling and their associated properties have been removed. These removals are expected to appear in new memos at a later time and will be independent extensions of this specification. The new EXTENSIONS property will exist to allow for compatible sets of extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-ical-basic-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-ical-basic-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-ical-basic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-4638 http://Royer.com | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------090801060904050606000008 Content-Type: Message/External-body; name="draft-royer-ical-basic-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-royer-ical-basic-00.txt" Content-Type: text/plain Content-ID: <2005-1-3151136.I-D@ietf.org> --------------090801060904050606000008 Content-Type: text/plain; name="file:///tmp/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------090801060904050606000008-- --------------ms040000010404040105070301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMTEwMjEwNjAxWjAjBgkqhkiG9w0BCQQxFgQUwZoSlsnFO7nmJYTkdX6p k71B4HwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAij5lyFVP5HpczNrPr80Exug2HAjT9JOez4VD3tobQWSSwpwdDF9f0PTxSB8IIPsp sYTA4JC/N18ZlB5QCc9DSCVVSfZgGjlzAfFbkMay8SzIginXyOL/CW11+DGbStrfZ9rDmU+7 0DmUt1FRMwNQkKFzqMPv/1P24qbdj6JbSlKplXFigJ4cn7xX0Stz+eJjZ52ty4tnf8vazBNU x3Zlw2Nq3rjD6v8GlF2NMgqjuDzIHyLFIDdHxLy0TV+TSblPA6sMacqX4rfoGwogFvOiFktQ shVRdM7l5CCQJz6ksC0sAs8Lx4Is0ziNCI1SpYfBUe2sdK+1dwnFiYUzYUQRFwAAAAAAAA== --------------ms040000010404040105070301-- X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j038LkaZ000308 for ; Mon, 3 Jan 2005 00:21:47 -0800 Received: (qmail invoked by alias); 03 Jan 2005 08:21:37 -0000 Received: from pD9E51069.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.105) by mail.gmx.net (mp012) with SMTP; 03 Jan 2005 09:21:37 +0100 X-Authenticated: #1915285 Message-ID: <41D9008B.6060308@gmx.de> Date: Mon, 03 Jan 2005 09:21:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> <41D84B9A.6010006@gmx.de> <6CF88E30-5CFD-11D9-BF99-000D936E5072@opengroupware.org> <41D862CE.7060207@gmx.de> <4148C64D-5D0D-11D9-BF99-000D936E5072@opengroupware.org> In-Reply-To: <4148C64D-5D0D-11D9-BF99-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 08:21:52 -0000 Helge Hess wrote: > Since the URI is not supposed to be stable by the protocol and since > server side ID generation is nothing unusual either I don't consider > this very far fetched. But anyway. To rephrase it differently: server-side URL assignment is quite common, but I have never seen it before used for PUT. > ... >> Basically, the PUT operation defined in RFC2616 doesn't have the >> semantics CalDAV seems to require. Historically, servers have been >> using POST to a container resource to actually create new members. Is >> there a particular reason why CalDAV can't do the same? > > > I also considered this. Why don't we require a POST on a collection to > create items? POST + 201 with location. It seems to me that this would be the most straighforward way to spec it. If a server wants to support PUT the way it's currently defined for teh sake of making demos with existing clients simpler, that's fine and simply an implementation issue. Just don't put *that* into the spec. > For me I had the impression the PUT+location is perfectly valid and > that POST is somewhat too generic. POST also has the disadvantage that > it won't work with generic servers nor with generic clients. PUT isn't > a perfect fit for them but works for the majority. I thought that generic clients weren't considered to be major focus? Maybe the spec should first state what the requirements are... >> Thus this will not help with a generic client anyway. So what *are* >> the requirements? Do you expect a non-CalDAV-aware client to be able >> to PUT new events this way? > > > I can only speak for myself, but I would not expect generic clients to > be very useful with CalDAV servers. Being able to drop an iCal file > into a WebDAV mounted iDisk is a nice demo but has little value in > practice. See above: it's ok if a server implementor chooses to implement it that way for demo purposes; just don't make it the single (or recommended) way to do it. > Personally I assumed that this paragraph was written with PUT in mind. > But I also found (POST 9.5): > "If a resource has been created on the origin server, the response > SHOULD be 201 > (Created) and contain an entity which describes the status of the > request and refers > to the new resource, and a Location header (see Section 14.30)." > > > I'm still very interested on how to implement the mentioned > functionality in the best possible "HTTP way". Maybe POST is really the > way to go (but this will be completely unavailable to generic clients! > Interoperability is much worse than with PUT+loc). Again: the spec should be clear about what it's trying to achieve. If generic PUT-aware clients are required to work then I think this is not generally achievable. If that's not the requirement, just define a different way that fits better into the HTTP framework. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j02MPuaZ002272 for ; Sun, 2 Jan 2005 14:25:57 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 007722C541C; Sun, 2 Jan 2005 23:24:47 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 6AA802C5407; Sun, 2 Jan 2005 23:24:46 +0100 (CET) In-Reply-To: <41D862CE.7060207@gmx.de> References: <41D8433E.2000305@gmx.de> <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> <41D84B9A.6010006@gmx.de> <6CF88E30-5CFD-11D9-BF99-000D936E5072@opengroupware.org> <41D862CE.7060207@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4148C64D-5D0D-11D9-BF99-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 Date: Sun, 2 Jan 2005 23:25:49 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 22:26:01 -0000 On 2. Jan 2005, at 22:08 Uhr, Julian Reschke wrote: > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI." OK, 2:1 for you ;-) > ...so I think the interpretation that the server may choose a > different URI is really far-fetched. Since the URI is not supposed to be stable by the protocol and since server side ID generation is nothing unusual either I don't consider this very far fetched. But anyway. > Using the Location response header is fine for methods that create new > resources in locations other than the request URI (such for instance a > POST). The question is whether it's ok to let PUT choose a different > location. Si, thats the question. >> Technically I don't see the issue with it either. The server is free >> to move the resource afterwards anyway, there is nothing in HTTP >> which ensures that a GET following the PUT will succeed (more >> exactly: no transactions). >> Am I missing something? > > Of course a server can do anything it wants. How much it deviates in > doing this affects how well generic clients will work. Any generic > client that issues PUT requests today will assume that a 201 upon PUT > means that the resource indeed was created at the request URI. Of course. 201 means the resource was created on the request URI. But the client may not assume that the same URI is still there after creation (Q: unless it locked the whole collection?) since HTTP systems are to be considered "heavily multiuser". I don't think the major focus of CalDAV is being able to access a server using generic clients. Thats should be pretty useless except for debugging (and notably Cadaver doesn't have any issues with the mentioned PUT+location combination). > Basically, the PUT operation defined in RFC2616 doesn't have the > semantics CalDAV seems to require. Historically, servers have been > using POST to a container resource to actually create new members. Is > there a particular reason why CalDAV can't do the same? I also considered this. Why don't we require a POST on a collection to create items? POST + 201 with location. For me I had the impression the PUT+location is perfectly valid and that POST is somewhat too generic. POST also has the disadvantage that it won't work with generic servers nor with generic clients. PUT isn't a perfect fit for them but works for the majority. > Depends on the requirements. A generic client will not automatically > follow a redirect upon PUT because of the reasons given in > rfc2616.html#rfc.section.10.3.3.p.3>: Thanks for the pointer, valid issue. > Thus this will not help with a generic client anyway. So what *are* > the requirements? Do you expect a non-CalDAV-aware client to be able > to PUT new events this way? I can only speak for myself, but I would not expect generic clients to be very useful with CalDAV servers. Being able to drop an iCal file into a WebDAV mounted iDisk is a nice demo but has little value in practice. > If a spec that builds on HTTP chooses to override SHOULD-level > requirements of HTTP, I'd expect a very good rational for that. Si. > Right now, there doesn't seem to be a compelling reason except that it > reduces the amount of work for the authors of the spec :-). I think I brought up a good reason (which you may accept or not). I still think that PUT+location is the best way to represent what one wants without affecting the idea behind the data/protocol model and retaining good interoperability at the same time. >> Actually during this I found: >> http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30 >> it explicitly states: >> "For 201 (Created) responses, the Location is that of the new >> resource >> which was created by the request." >> I assume this makes us happy? ;-) > > Nope (see above). Of course the Location header is the right thing to > use if a method creates a resource at a location other than the > Request-URI. The question was whether it's ok for PUT to actually do > that. Personally I assumed that this paragraph was written with PUT in mind. But I also found (POST 9.5): "If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see Section 14.30)." I'm still very interested on how to implement the mentioned functionality in the best possible "HTTP way". Maybe POST is really the way to go (but this will be completely unavailable to generic clients! Interoperability is much worse than with PUT+loc). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j02LMraZ032323 for ; Sun, 2 Jan 2005 13:22:53 -0800 Received: (qmail invoked by alias); 02 Jan 2005 21:22:47 -0000 Received: from pD9E51069.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.105) by mail.gmx.net (mp012) with SMTP; 02 Jan 2005 22:22:47 +0100 X-Authenticated: #1915285 Message-ID: <41D86616.20508@gmx.de> Date: Sun, 02 Jan 2005 22:22:30 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> In-Reply-To: <41D8433E.2000305@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 21:22:56 -0000 Here's another minor issue: 04-C17, Section 6.2 In the example response, the value for "ETag:" is invalid (ETags are always quoted, see ). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j02L8oaZ031620 for ; Sun, 2 Jan 2005 13:08:51 -0800 Received: (qmail invoked by alias); 02 Jan 2005 21:08:44 -0000 Received: from pD9E51069.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.105) by mail.gmx.net (mp027) with SMTP; 02 Jan 2005 22:08:44 +0100 X-Authenticated: #1915285 Message-ID: <41D862CE.7060207@gmx.de> Date: Sun, 02 Jan 2005 22:08:30 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> <41D84B9A.6010006@gmx.de> <6CF88E30-5CFD-11D9-BF99-000D936E5072@opengroupware.org> In-Reply-To: <6CF88E30-5CFD-11D9-BF99-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 21:08:56 -0000 Helge Hess wrote: > On 2. Jan 2005, at 20:29 Uhr, Julian Reschke wrote: > >> From : >> >> "If the resource could not be created or modified with the >> Request-URI, an appropriate error response SHOULD be given that >> reflects the nature of the problem." >> >> That is, PUT is not allowed to succeed by creating a resource at a >> different URI. > > > Hm, I'm not a native speaker, so its not unlikely I'm wrong, but "with > the Request-URI" is not the same like "*at* the Request-URI" to me. Nor am I, but it also says...: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." ...so I think the interpretation that the server may choose a different URI is really far-fetched. > The resource could be successfully created "with" the URL, which is why > there is a 201. It afterward lives at a new URL, which is what is hinted > by the location header. Using the Location response header is fine for methods that create new resources in locations other than the request URI (such for instance a POST). The question is whether it's ok to let PUT choose a different location. > Technically I don't see the issue with it either. The server is free to > move the resource afterwards anyway, there is nothing in HTTP which > ensures that a GET following the PUT will succeed (more exactly: no > transactions). > Am I missing something? Of course a server can do anything it wants. How much it deviates in doing this affects how well generic clients will work. Any generic client that issues PUT requests today will assume that a 201 upon PUT means that the resource indeed was created at the request URI. Basically, the PUT operation defined in RFC2616 doesn't have the semantics CalDAV seems to require. Historically, servers have been using POST to a container resource to actually create new members. Is there a particular reason why CalDAV can't do the same? > ... >> I'm not sure that using a 3xx is a good idea either, unless the server >> is going to continue to send redirects to the target resource. > > > Good point. But 302 is a temporary redirect which assumes that the > redirect will go away, right? Again: what in HTTP requires that the > server ensures objects not going away? > Anyway, I'm not really pleased with the 302 solution anyway, see above. Depends on the requirements. A generic client will not automatically follow a redirect upon PUT because of the reasons given in : "If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued." Thus this will not help with a generic client anyway. So what *are* the requirements? Do you expect a non-CalDAV-aware client to be able to PUT new events this way? >>> IMHO the 201+location says, yes, it was successfully created and just >>> got moved afterwards. Just an optimization of 201 and a move by a >>> thirdparty (actually CalDAV might need to require a full rescan of a >>> collection [unless we have notifications], eg in case the server >>> 'flattened' cyclic events). >> >> But that's not the semantics of PUT as defined by RFC2616 (see above). > > > Read that. But I don't see something which forbids it either, actually > the spec for PUT is very open being composed of a lot of SHOULD's. From RFC2119: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." If a spec that builds on HTTP chooses to override SHOULD-level requirements of HTTP, I'd expect a very good rational for that. Right now, there doesn't seem to be a compelling reason except that it reduces the amount of work for the authors of the spec :-). > Actually during this I found: > http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30 > > it explicitly states: > "For 201 (Created) responses, the Location is that of the new resource > which was created by the request." > > I assume this makes us happy? ;-) Nope (see above). Of course the Location header is the right thing to use if a method creates a resource at a location other than the Request-URI. The question was whether it's ok for PUT to actually do that. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j02KWbaZ028854 for ; Sun, 2 Jan 2005 12:32:37 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A02792C4D2F; Sun, 2 Jan 2005 21:31:27 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 1B82F2C4D24; Sun, 2 Jan 2005 21:31:27 +0100 (CET) In-Reply-To: <41D84B9A.6010006@gmx.de> References: <41D8433E.2000305@gmx.de> <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> <41D84B9A.6010006@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CF88E30-5CFD-11D9-BF99-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 Date: Sun, 2 Jan 2005 21:32:30 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 20:32:41 -0000 On 2. Jan 2005, at 20:29 Uhr, Julian Reschke wrote: > From : > > "If the resource could not be created or modified with the > Request-URI, an appropriate error response SHOULD be given that > reflects the nature of the problem." > > That is, PUT is not allowed to succeed by creating a resource at a > different URI. Hm, I'm not a native speaker, so its not unlikely I'm wrong, but "with the Request-URI" is not the same like "*at* the Request-URI" to me. The resource could be successfully created "with" the URL, which is why there is a 201. It afterward lives at a new URL, which is what is hinted by the location header. Technically I don't see the issue with it either. The server is free to move the resource afterwards anyway, there is nothing in HTTP which ensures that a GET following the PUT will succeed (more exactly: no transactions). Am I missing something? > I'm not sure why this capability is needed, but if the protocol really > needs it, it could fail the PUT and return a new Request-URI in the > response headers or body (I'd put that into a DAV:error/precondition > element that contains a DAV:href). IMHO we really need a way to represent "a method which creates the object on a new URL". It is a very common thing that the server will enforce maintenance of unique ids. What I said before, a "redirect to URL, then PUT" is an improvement (covering an additional class of servers) but still leaves out some. > I'm not sure that using a 3xx is a good idea either, unless the server > is going to continue to send redirects to the target resource. Good point. But 302 is a temporary redirect which assumes that the redirect will go away, right? Again: what in HTTP requires that the server ensures objects not going away? Anyway, I'm not really pleased with the 302 solution anyway, see above. >> IMHO the 201+location says, yes, it was successfully created and just >> got moved afterwards. Just an optimization of 201 and a move by a >> thirdparty (actually CalDAV might need to require a full rescan of a >> collection [unless we have notifications], eg in case the server >> 'flattened' cyclic events). > But that's not the semantics of PUT as defined by RFC2616 (see above). Read that. But I don't see something which forbids it either, actually the spec for PUT is very open being composed of a lot of SHOULD's. Actually during this I found: http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30 it explicitly states: "For 201 (Created) responses, the Location is that of the new resource which was created by the request." I assume this makes us happy? ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j02JTmaZ023648 for ; Sun, 2 Jan 2005 11:29:49 -0800 Received: (qmail invoked by alias); 02 Jan 2005 19:29:42 -0000 Received: from pD9E51069.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.105) by mail.gmx.net (mp015) with SMTP; 02 Jan 2005 20:29:42 +0100 X-Authenticated: #1915285 Message-ID: <41D84B9A.6010006@gmx.de> Date: Sun, 02 Jan 2005 20:29:30 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> In-Reply-To: <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 19:29:52 -0000 Helge Hess wrote: > On 2. Jan 2005, at 19:53 Uhr, Julian Reschke wrote: > >> 04-C06, Section 6.2 >> >> > -04.html#rfc.section.6.2> >> >> The example given (resource created at a different URI) seems to >> violate HTTP semantics: if PUT doesn't actually create a resource at >> the Request-URI, a status code of 201 (actually any 2xx code) seems >> to be wrong. > > > What would be your suggestion to fix this? > > Return a 302 and then make the HTTP client repeat the PUT? (which has > the disadvantage that the server may not yet know the final location at > creation time). > > Or is there any other 3xx code which could be used for 201+Location? > > Actually you write "seems to be wrong", I find it quite natural, _is > it_ wrong or not? If yes, could you please point to the HTTP spec > positions in question? From : "If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem." That is, PUT is not allowed to succeed by creating a resource at a different URI. I'm not sure why this capability is needed, but if the protocol really needs it, it could fail the PUT and return a new Request-URI in the response headers or body (I'd put that into a DAV:error/precondition element that contains a DAV:href). I'm not sure that using a 3xx is a good idea either, unless the server is going to continue to send redirects to the target resource. > IMHO the 201+location says, yes, it was successfully created and just > got moved afterwards. Just an optimization of 201 and a move by a > thirdparty (actually CalDAV might need to require a full rescan of a > collection [unless we have notifications], eg in case the server > 'flattened' cyclic events). But that's not the semantics of PUT as defined by RFC2616 (see above). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j02JD4aZ022579 for ; Sun, 2 Jan 2005 11:13:05 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 209442C2B69; Sun, 2 Jan 2005 20:11:54 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 7D8A42BDB3D; Sun, 2 Jan 2005 20:11:53 +0100 (CET) In-Reply-To: <41D8433E.2000305@gmx.de> References: <41D8433E.2000305@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E5F5766-5CF2-11D9-BF99-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 Date: Sun, 2 Jan 2005 20:12:55 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 19:13:09 -0000 On 2. Jan 2005, at 19:53 Uhr, Julian Reschke wrote: > 04-C06, Section 6.2 > > -04.html#rfc.section.6.2> > > The example given (resource created at a different URI) seems to > violate HTTP semantics: if PUT doesn't actually create a resource at > the Request-URI, a status code of 201 (actually any 2xx code) seems to > be wrong. What would be your suggestion to fix this? Return a 302 and then make the HTTP client repeat the PUT? (which has the disadvantage that the server may not yet know the final location at creation time). Or is there any other 3xx code which could be used for 201+Location? Actually you write "seems to be wrong", I find it quite natural, _is it_ wrong or not? If yes, could you please point to the HTTP spec positions in question? IMHO the 201+location says, yes, it was successfully created and just got moved afterwards. Just an optimization of 201 and a move by a thirdparty (actually CalDAV might need to require a full rescan of a collection [unless we have notifications], eg in case the server 'flattened' cyclic events). Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j02IsAaZ020852 for ; Sun, 2 Jan 2005 10:54:11 -0800 Received: (qmail invoked by alias); 02 Jan 2005 18:54:02 -0000 Received: from pD9E51069.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.105) by mail.gmx.net (mp002) with SMTP; 02 Jan 2005 19:54:02 +0100 X-Authenticated: #1915285 Message-ID: <41D8433E.2000305@gmx.de> Date: Sun, 02 Jan 2005 19:53:50 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Comments on draft-dusseault-caldav-04 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 18:54:14 -0000 Hi, below are my comments about the -04 draft (top-down read, focusing on WebDAV/HTTP questions with little Calendaring specific checks): Best regards, Julian -- 04-C01 Section 1.1.1 A few terminology problems here: "WebDAV is an extension to the HTTP/1.1 [4] protocol, therefore its URLs are HTTP URLs." That's a bit misleading, as there are other URLs used within WebDAV which aren't HTTP URLs, for instance lock tokens. "If HTTP GET can be used to represent a calendar object..." GET doesn't represent objects, it *retrieves* representations of objects. In general, this probably should be re-organized into two parts: 1) why it's good to have retrievable URIs for calendar objects, thus HTTP 2) why it's good to re-use existing HTTP extensions, thus WebDAV 04-C03 Section 1.1.8 "Dead properties are client-controlled properties, where the namespace, name and value are entirely controlled by the client. However, the server is required to store these properties and return them, if requested, in PROPFIND queries for individual resources or in listings of collection contents." Why: "however"? "Some servers support text searching on all dead properties through the DASL extensions (a work in progress) [TODO: REF]. Dead properties can also be used in reports." Missing reference. 04-C04, Section 6 "Calendars and individual calendar objects may all be created by either the CalDAV client or by the CalDAV server." This is misleading. It's always the server thst creates objects. If this is about who *initiates* the creation, this should be clarified. 04-C05, Section 6.1 "The successful response to MKCALENDAR is typically 201 (Created)." What is "typically" supposed to mean? Please either be precise here or remove that sentence (thus RFC2616 applies). "Note that there is no semantic value in any other part of a calendar name (or a resource name, other than possibly the file extension)." No, not even the file extension. Neither HTTP nor WebDAV have a notion of "file extension". "Thus, a calendar collection may be called "calendar", "cal", "Calendario" and so on. It's the properties of the resource that define what it is, not the name."" It's the DAV:resourcetype property, right? Why not simply say so? 04-C06, Section 6.2 The example given (resource created at a different URI) seems to violate HTTP semantics: if PUT doesn't actually create a resource at the Request-URI, a status code of 201 (actually any 2xx code) seems to be wrong. 04-C07, Section 7 "A server supporting CalDAV MUST support additional properties on principal resources if these principals are associated with calendars. In addition, certain properties are required on calendars to link to principal resources. These properties are defined in the properties section." This additional requirement will make some existing RFC3744 implementations unable to conform to this spec. I think this is a problem, and an alternate solution (not requiring custom properties on principal resources) should be discussed. 04-C08, Section 9 It's unclear why the discussion about PUT vs PROPPATCH vs SCHEDULE is still in when the document indeed defines a SCHEDULE method in section 9.1. (editorial note: it would be nice if editorial comments and notes would use RFC2629's element for better readability) 04-C09, Section 9.1 Why is the title "SCHEDULE method for WebDAV"? What does it make a method for WebDAV, rather than an HTTP method? What's the difference? Also, it would be good if the method description would be a bit more formal in defining the new HTTP request headers (ABNF?). (forward reference to section 10?) 04-C10, Section 9.1.1 There seems be some confusion about when to return a 207 and when not. For instance, I'd expect a malformed request body to result in a HTTP status of 400. Also, the multistatus response for a successful request needs to be more formally defined (such as: must contain response elements for each Recipient reuqest header URI). 04-C11, Section 11 Which XML namespace are the has-* properties in? 04-C12, Section 12 "Note that the XML Schema declarations used in this document are incomplete, in that they do not include namespace information." There are no XML Schema declarations in this document. 04-C13, Section 12.2 I think it would be good if the document would explain what this property is used for. 04-C14, Section 13 "Generally, if no appropriate value is known for these properties, the properties SHOULD exist but be blank." This seems to be inconsistent with other WebDAV properties (which will simply not be present when not applicable. Also need to specify whether these are live or dead properties, and if they are live, whether protected or not. Furthermore, if live the spec should define whether they should appear on propfind/allrop (same applies to the properties defined in section 12). 04-C15, Section 15 The introduction should point to the normative definition of the REPORT method (RFC3253, 3.6) and it also needs to define whether the DAV:expand-property-report (3.8) is mandatory (it is in RFC3253 and RFC3744). Also, error marshalling shouldn't be repeated (is it the same as in RFC3253? If not, why?), and usage of the DAV:error response element needs to be consistent with RFC3253. 04-C16, Section 15.1 Should define the role of the Depth request header when applied to a collection resource. 04-C17, Section 15.2 There doesn't seem to be a definition of the calendar-query-result request element. It's a bit unclear why the spec needs to extend multistatus, that is, why the requested ical information can't be returned in the form of promoted properties (I think this would greatly simplify the spec). 04-E01, References The following references are not used (RFC2629-wise) in the text: WARNING: unused reference 'RFC3339' WARNING: unused reference 'RDF-ICAL' WARNING: unused reference 'I-D.reschke-webdav-search' -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760