Subject: Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Sep 2006 12:56:57 +0200

Robert Sayre schrieb:
> Why can't the CalDAV spec note the ambiguity with Etags and move on? I
> don't think it's appropriate for this document add semantics to the
> general purpose ETag header with a MUST NOT, since "calendar object
> resource" is meaningless from a general HTTP perspective.
> 
> also concerned,
> 
> Robert Sayre
> 
> "I would have written a shorter letter, but I did not have the time."

As far as I can tell, the base problem is that there are minor flaws in 
the HTTP specifications (RFC2616/2617), so the right thing to do for the 
IETF would be to address those in general, instead of having every 
specification *based* on HTTP having to worry about that.

ETag handling in write operations is just one example (currently 
affecting XCAP, RFC2518bis and CalDAV), authentication considerations 
are another.

Back in February, the IESG advised the WebDAV working group *not* to add 
ETag considerations into RFC2518bis, but to discuss and resolve this in 
a separate spec, so that every spec based on HTTP could reference it. 
That resulted in draft-whitehead-http-etag-00, which wasn't updated 
since and which is going to expire very soon (see 
<http://greenbytes.de/tech/webdav/draft-whitehead-http-etag-00.html>).

My personal opinion is that draft probably spent too much time with a 
very generic discussion of state identifiers, without getting close to 
that actual problem that needs to be resolved. Thus, I wrote down what 
*I* think the problem is, and included a minimal proposal to resolve it. 
This is draft-reschke-http-etag-on-write-01 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html>) 
currently being discussed over on the HTTP mailing list 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/>). I think I got the 
problem analysis right (feedback appreciated), and also that both the 
suggested clarifications for RFC2616 (to go into the errata document) 
and the new header solve the perceived problem.

As far as I am concerned the IESG should ask the authors of CalDAV to 
remove the normative statements about ETag handling (incompatible with 
RFC2616), and instead ask the CalDAV community to participate in the 
discussion over on the HTTP mailing list.

If no new feedback surfaces, I plan to do an informal mailing last call 
in the second half of September, and then to submit a new draft for 
publication as experimental RFC.

Best regards, Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf