Re: [Ietf-caldav] CalDAV comments, a bit too late...

Julian Reschke <julian.reschke@gmx.de> Wed, 24 September 2008 14:00 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf-caldav@osafoundation.org
Delivered-To: ietf-caldav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7AE2C80D9B for <ietf-caldav@osafoundation.org>; Wed, 24 Sep 2008 07:00:19 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B47981421FD for <ietf-caldav@osafoundation.org>; Wed, 24 Sep 2008 07:00:17 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -4.452
X-Spam-Level:
X-Spam-Status: No, score=-4.452 tagged_above=-50 required=4 tests=[AWL=-1.852, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDIDALnUDWaz for <ietf-caldav@osafoundation.org>; Wed, 24 Sep 2008 07:00:03 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 1D5641421FC for <ietf-caldav@osafoundation.org>; Wed, 24 Sep 2008 07:00:02 -0700 (PDT)
Received: (qmail invoked by alias); 24 Sep 2008 14:00:02 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp050) with SMTP; 24 Sep 2008 16:00:02 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX198lzYaqfJ8j+g1LefICnDl582gQbf7RqLnihSnJg J7nWsWkr2u1pXj
Message-ID: <48DA47DF.5000008@gmx.de>
Date: Wed, 24 Sep 2008 15:59:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Shug Boabby <shug.boabby@gmail.com>
Subject: Re: [Ietf-caldav] CalDAV comments, a bit too late...
References: <9508491d0809240600w6e4890f5n17bcaca59688b7ea@mail.gmail.com>
In-Reply-To: <9508491d0809240600w6e4890f5n17bcaca59688b7ea@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53
Cc: ietf-caldav@osafoundation.org
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Sep 2008 14:00:19 -0000

Shug Boabby wrote:
> ...
> - basing it on WebDAV instead of HTTP means that most standard
> libraries may not be used
> ...

"most"?

> ...
> - sharing resources with other users (even other users on the same
> server) is not even considered
> ...

I though it was by explicitly requiring WebDAV ACL support.

> ...
> CalDAV is based on WebDAV, which is covered with HTTP compatibility
> problems. For example, all flavours of Java exclude WebDAV support in
> their standard network library and use of methods such as REPORT and
> PROPFIND are forbidden. Other languages face similar troubles. Support
> is available from third parties on J2SE and J2EE (but no
> maintenance!). No support is available for J2ME and raw socket access
 > ...

What exactly do you mean by "no maintenance"?

> ...
> My preferred solution would have been to stick with plain old HTTP!
> There is nothing in this protocol that could not have been achieved
> with simple GET, POST and (optionally) PUT. I wouldn't even have
> considered HTTP headers to contain anything special... something
> CalDAV relies on heavily (e.g. Depth and If-None-Match).
 > ...

How is if-none-match "special"?

> One of the things I really like about the Freebase API is the fact
> that non-standard queries can be formulated in fairly simple JSON
> format (but could easily have been XML), but that for most things a
> simple GET-based query will also work. It would have been highly
> desirable if the most common CalDAV queries could have been achieved
> as simply as sending a GET query to
> server.com/caldav/todo/username/calendar?state=incomplete&from=20060712T182145Z
 > ...

I agree with this one. See for instance 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.C>.

> ...
> Also, where is the definition of the "urn:ietf:params:xml:ns:caldav"
> and "DAV" namespaces? A schema is needed if correct XML is to be
> expected!
> ...

No, a schema is not needed :-) A spec is needed, though. See the WebDAV 
and the CalDAV specs.

> ...
> I've already hinted that creating XML is often burdensome on mobile
> devices, and also that creating new resources is not guaranteed to
> succeed. As an example, consider creating a new VTODO item, given that
> we know the collection URL. A PUT request is made to a URL that we
> must create ourselves, and we must add the HTTP header "If-None-Match:
> *". It is then non-obvious how one is expected to check the reason for
> failure! Currently I am scanning the text of the Cosmo response for a
> non-201 response and the String "If-None-Match disallows conditional
> request", but this is clearly implementation specific. Creating new
> resources could not have been designed to be more difficult.
> ...

You should check for the right HTTP status (it should be 412).

That being said: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>.

 > ...

BR, Julian