Lisa Dusseault wrote:
Thanks for the input. Speaking as a document author here, I'm confident
we've made a decent set of tradeoffs, balancing possible risks against
benefits, and attempting to minimize the risks too.
The basic risk is that any requirements related to ETags may conflict
with future requirements. We've attempted to minimize this risk by
making only one requirement -- that servers MUST NOT return strong ETags
if they have changed the data provided to be stored. We believe that
this requirement is quite within the spirit of ETag design. We didn't
make any requirements about weak ETags, nor did we require any behavior
that future specs might make illegal. Since today with HTTP it's
perfectly acceptable not to return an ETag at all, future requirements
on ETags would at least have to work with a huge deployed base of HTTP
servers that don't return any ETag on PUT responses.
Thus, any future ETag-related requirements that invalidated this CalDAV
requirement, would also conflict with the huge deployed base of HTTP. I
How so?
A potential requirement of an XyzDav spec to return ETags even though
the content was rewritten wouldn't be in conflict with HTTP at all. It
would just be impossible to implement a resource that's both compliant
to CalDAV and XyzDav.
This is why I think CalDav uses the wrong approach. There's a simple way
to give CalDav clients that piece of information and which is guaranteed
to be compatible with other specs, and that's what CalDav should do.
Or, alternatively, it could just stay silent and let that other spec
work out the solution, instead of trying to come up with a fait accompli.
> ...
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf