W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

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

From: Peter Dambier <peter@peter-dambier.de>
Date: Thu, 15 Jun 2006 12:00:14 +0000
Message-ID: <44914BC2.6000404@peter-dambier.de>
To: ietf@ietf.org
CC: HTTP Working Group <ietf-http-wg@w3.org>

Julian Reschke wrote:
> 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 am one user of webdavs://mediacenter.gmx.net/

I dont know how many subscribers they serve but they are one of the biggest
ISPs in germany. They belong to United Internet, 1und1, GMX and Schlund.

I dont know what they use but I guess Appache and Linux.

They do change content.

I am running Konqueror on Linux and I can both move and copy documents using
drag and drop. I can delete or rename using the mouse and I can edit and
write back using the browsers builtin editor.

I cannot see ETag flag from my userinterface. But my browser shows me
the before and after. So normally I can see if anything has 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

Kind regards
Peter and Karin Dambier

Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
Received on Thursday, 15 June 2006 13:02:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:39 UTC