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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf