Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Julian Reschke <[e-mail]>]

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