[Ietf-caldav] CalDAV comments, a bit too late...
julian.reschke at gmx.de
Wed Sep 24 06:59:59 PDT 2008
Shug Boabby wrote:
> - basing it on WebDAV instead of HTTP means that most standard
> libraries may not be used
> - 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
I agree with this one. See for instance
> 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
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:
More information about the Ietf-caldav