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

[Filip Navara]

Hi!

> -----Original Message-----
> From: "Shug Boabby" <shug.boabby at gmail.com>
> To: ietf-caldav at osafoundation.org
> Date: 09/24/08 15:01
> Subject: [Ietf-caldav] CalDAV comments, a bit too late...
--snip--
> - basing it on WebDAV instead of HTTP means that most standard
> libraries may not be used

Probably the only case of standard libraries not working with WebDAV
is the one of Java that you mentioned. All the other frameworks that
I worked with supported it without a glitch.

--snip--
> It should also be noted that the current protocol excludes AJAX access to
> data via the usual JSON cross-server route.

Do you realize that the X in AJAX stands for XML? In fact AJAX was used
for the very first time in Outlook Web Access to access WebDAV on the
Exchange server.

--snip--
> 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).

This has been tried and done - see WCAP and Google Data protocols.

--snip--
> - obtain all TODO items that have been modified since a given
> timestamp or ETag was created

At first, this could be done with a single query, but there are experimental
drafts to address this on WebDAV level (http://tools.ietf.org/id/draft-daboo-webdav-sync-00.txt).

--snip--
> I would also assume that queries on the collection-home
> be applied to all collections/calendars! This is not the case, and
> there does not appear to be a way to do it.

There is a way to do it, use the Depth: infinity header. It may not be
supported on the server due to excessive workload, but quite a few
existing servers support it.

--snip--
> 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

This is what WCAP does, but it's not easily extensible, while XML w/ namespaces is.

--snip--
> It might sound like this is purely aesthetic, but it is not. It takes
> a lot of code to be capable of handling and creating the XML queries
> that CalDAV requires, leading to the exclusion of some mobile devices.

What the heck? You can hard code the XML for your common queries as standard text string. Not any harder than passing the parameters in URL.

--snip--
> 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!

The "DAV:" namespace is covered in RFC 4918 (and RFC 3744 and others).
"urn:ietf:params:xml:ns:caldav" is covered in RFC 4791. As far as I know
there are no authoritative complete schemas, but indiviual DTD definitions
of elements are present in the RFCs.

--snip--
> 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.

This is not implementation specific and the error codes are well defined.
Successful PUT can basically result only in 201 or 204 responses where
204 can't happen if "If-None-Match: *" is specified. Anyway, any 2xx
error code should be treated as successful creation of the resource.

--snip--
> Another classic example is timezone support. Prior to using CalDAV, I
> had expected it to do all the grunt work of timezones... such that I
> could make all my queries in GMT and never be confused. However, it
> seems that CalDAV is expecting all clients (even mobile clients) to
> have rich timezone support and to therefore have full international
> iCal support.

Wrong, wrong, wrong. Look again at the "expand" element in RFC
4791.

--snip--
> # No support for sharing

Actually you are confusing two things - sharing and delegating. Both of
which are supported. Sharing is supported through the mandatory
requirement to support WebDAV ACLs. For delegating see
http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-05.txt

Best regards,
Filip Navara