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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf