I noticed that the ID tracker now has a comment from the authors (see
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=52124>),
which I'd like to comment over here...:
Author's response to Last Call comments on ETags
1) Best common practice in WebDAV
Currently very few, if any at all, WebDAV servers change the content of
resource data during a PUT request. Most WebDAV servers do return an ETag on
PUT. Thus clients have come to rely on the presence of the ETag to effectively
mean that the resource data was stored unchanged and that the ETag can be used
in subsequent GET requests etc. This justifies our statement that servers
SHOULD return an ETag in a response when the data has not changed.
I have my doubts that this statement is based on actual testing. In
particular it seems to me that making claims about "most" servers isn't
useful here; servers that do rewrite content do exist, but they are
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs
which implement WebDAV as a "dumb" store (in that they don't support
special semantics on specific content types). But that doesn't mean that
being incompatible with that class of servers (being fully compliant to
RFC2616 and RFC2518) is acceptable.
That being said, I just tested:
- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT
- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT
- Xythos WFS (on www.sharemation.com): ETag returned
- SAP Netweaver KM: ETag returned although content may be rewritten
It seems to me that this shows that the statement above is misleading.
Now we have CalDAV servers where the resource data MAY be changed. Therefore to
be compatible with existing client behavior a server MUST NOT send the ETag in
a PUT response when the data changes, otherwise clients will misinterpret it.
This justifies our 'MUST NOT' statement.
It would be helpful if you could provide an example of a *shipping*
client that breaks if an ETag is returned upon PUT although content was
rewritten.
2) Restricted behavior
The ETag behavior we are talking about is restricted solely to calendar object
resources being stored in calendar collections - i.e. it is very specific to
CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this
one specific application need.
But it's still an HTTP and WebDAV resource. A CalDAV server that also
happens to be a generic WebDAV server may need to make this a special
case then. And this may be hard to do should there be another
HTTP/WebDAV related specification making an incompatible requirement.
As a matter of fact, in February the IESG has decided to solve that very
problem in a separate activity (see draft-whitehead-http-etag-00),
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the
revision of WebDAV) delegates resolution of the question to that very
spec, instead of coming up with it's own. This is what CalDAV should
also be doing.
3) Future conflicts
One of Julian's arguments is that our requirement will "risk making CalDAV
incompatible with other specs extending HTTP (or HTTP itself, for that matter)".
Since we have been careful to require only behavior that already exists in deployed
WebDAV servers, CalDAV adds no further incompatibility. If future work to better define
the meaning of ETag on PUT ever happens, it will need to take into account the deployed
base, and the subset of CalDAV servers will simply happen to be a consistently behaving
subset. We believe that our requirements improve the interoperability of CalDAV, without
making the future/potential incompatibility problem any worse than it already is.
See notes above. The behavior required by CalDAV is *not* what current
servers do. At least not the majority.
4) Need/usefulness
In addition to the authors' evaluation of the usefulness of this feature for
keeping an offline calendar correct, there have been other requests for
predictable behavior w.r.t. PUT and ETags and calendar resources. This was one
of the first feature requests from client implementors, including Dan Mosedale
and Grant Baillie.
I totally agree that clients may be interested in finding out whether
content was rewritten. The solution to this is to either put more energy
into draft-whitehead-http-etag-00, or to have a CalDAV-specific solution
that by design wouldn't interfere with what we define in other specs
later, as outlined in
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html>.
I'd really like to here why the solution suggested back then isn't
sufficient for CalDAV.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf