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

[Wilfredo Sánchez Vega <[e-mail]>]

   I agree with Julian.

   As we've mentioned before, Apache returns a weak ETag on PUT,  
which turns into a strong ETag sometime later.  If clients rely on  
being able to use that ETag on a GET later, they won't work with  
Apache, and IIRC, Apache is pretty popular.

   The ETag requirements in the draft are what many clients authors  
might *like* to be the common case, but it is most certainly not so  
today.

   Additionally, the draft doesn't just say that servers SHOULD  
return an ETag in a response when the data has not changed, but also  
that they MUST NOT do so if the data did change.  It's not entirely  
clear that this is the direction things will go, and any MUST  
requirements which conflict with whatever we do come up with later  
will be a real headache.

	-wsv


On Jun 15, 2006, at 4:02 AM, 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 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-caldav mailing list -- [e-mail]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf