Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Lisa Dusseault <lisa@osafoundation.org> Mon, 19 June 2006 19:33 UTC
Return-Path: <lisa@osafoundation.org>
X-Original-To: ietf-caldav@osafoundation.org
Delivered-To: ietf-caldav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9071E7F6A8 for <ietf-caldav@osafoundation.org>; Mon, 19 Jun 2006 12:33:05 -0700 (PDT)
Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0F8C114229C; Mon, 19 Jun 2006 12:33:05 -0700 (PDT)
In-Reply-To: <A53A3668-1C4B-46B2-BE5C-02F3F8D7D45E@apple.com>
References: <D58B890CEBB86771C83E8401@Cyrus-Daboo.local> <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <CD95571B-E80E-4DA4-A522-23C0647CF6B6@osafoundation.org> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <DBB5A293-8F91-4E39-BE97-B6BD5236F5A3@osafoundation.org> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44913E39.7040503@gmx.de> <A53A3668-1C4B-46B2-BE5C-02F3F8D7D45E@apple.com>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org>
Content-Transfer-Encoding: quoted-printable
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Date: Mon, 19 Jun 2006 12:32:53 -0700
To: Wilfredo Sánchez Vega <wsanchez@apple.com>
X-Mailer: Apple Mail (2.750)
Cc: Ted Hardie <hardie@qualcomm.com>, HTTP Working Group <ietf-http-wg@w3.org>, ietf@ietf.org, CalDAV DevList <ietf-caldav@osafoundation.org>
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jun 2006 19:33:05 -0000
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 -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- [Ietf-caldav] Last Call comment on Etag requireme… Julian Reschke
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Cyrus Daboo
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Jay Batson
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Jari Urpalainen
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Julian Reschke
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Lisa Dusseault
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Julian Reschke
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Lisa Dusseault
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Julian Reschke
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Lisa Dusseault
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Julian Reschke
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Lisa Dusseault
- Re: [Ietf-caldav] I-D ACTION:draft-dusseault-cald… Julian Reschke
- [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-1… Cyrus Daboo
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Ted Hardie
- Re: [Ietf-caldav] Last Call comment on Etag requi… Cyrus Daboo
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Robert Sayre
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke