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 find that sufficiently unlikely as to be an acceptable
risk to take. Any standard we write has some risk of making
requirements that are in conflict with future spec requirements and
so we always take this kind of risk.
I do hope that new work on ETags and PUT will clarify this situation
further for all protocols, and if it becomes desirable to re-issue
CalDAV to make use of that general work, I'll be happy to re-issue it.
Lisa
On Apr 27, 2006, at 3:30 AM, Julian Reschke wrote:
Hi,
I note that draft 12 of caldav still makes requirements that are
potentially incompatible with HTTP:
Quoting <http://greenbytes.de/tech/webdav/draft-dusseault-
caldav-12.html#rfc.section.5.3.4.p.4>:
"In the case where the data stored by a server as a result of a PUT
request is not equivalent by octet equality to the submitted
calendar object resource, the behavior of the ETag response header
is undefined, with the exception that a strong entity tag MUST NOT
be returned in the response. As a result, clients may need to
retrieve the modified calendar object resource (and ETag) as a
basis for further changes, rather than use the calendar object
resource it had sent with the PUT request."
This is a requirement that is not in RFC2616. Adding this to CalDav
may make it impossible to implement resources that are both
compliant to CalDav and other HTTP based specifications (which may
have a different opinion about ETags in PUT responses).
If CalDav clients *really* require knowledge about this situation,
please define it in a way that will not potentially be in conflict
with other specifications, such as by adding a *new* response
header, indicating that content was not rewritten (as proposed in
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/
000787.html> two weeks ago).
Best regards, Julian
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav(_at_)osafoundation(_dot_)org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf