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

[Lisa Dusseault <[e-mail]>]

On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote:

>   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.

It's worse than that; many client authors *assumed* that to be the  
case, and implemented and deployed their clients assuming that if the  
client receives a strong ETag in response to a PUT, it has no further  
work to do to synchronize that resource.  So the deployed base says  
that *is* the case today.  I don't feel our document makes this  
situation any worse than the deployed base of clients already does.

Lisa


>
>   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-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