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

Julian Reschke <julian.reschke@gmx.de> Wed, 21 June 2006 00:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqMh-0001pa-7u; Tue, 20 Jun 2006 20:14:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqMf-0001pV-On for ietf@ietf.org; Tue, 20 Jun 2006 20:14:37 -0400
Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsqMe-0002cE-CM for ietf@ietf.org; Tue, 20 Jun 2006 20:14:37 -0400
Received: (qmail invoked by alias); 21 Jun 2006 00:14:34 -0000
Received: from p508FBE07.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.7] by mail.gmx.net (mp001) with SMTP; 21 Jun 2006 02:14:34 +0200
X-Authenticated: #1915285
Message-ID: <44988F67.9050803@gmx.de>
Date: Wed, 21 Jun 2006 02:14:31 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
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> <4136E0DE-F4F4-4A6E-9AC0-1C6297910ECA@osafoundation.org> <4496FDDD.8010405@gmx.de> <5B9360D3-01CB-477F-AE25-640AB5F4BCC4@osafoundation.org> <449828CC.3030700@gmx.de> <430D8860-3906-4210-8DD9-5CFCC5843176@osafoundation.org>
In-Reply-To: <430D8860-3906-4210-8DD9-5CFCC5843176@osafoundation.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Wilfredo Sánchez Vega <wsanchez@apple.com>, Ted Hardie <hardie@qualcomm.com>, HTTP Working Group <ietf-http-wg@w3.org>, ietf@ietf.org, CalDAV DevList <ietf-caldav@osafoundation.org>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Lisa Dusseault schrieb:
> My assertion was that if a strong ETag is returned, Xythos WFC assumes 
> that what it PUT was what the server stored, and it seems you agree.  
> You found that if a Last-Modified is returned instead, WFC makes the 
> same assumption -- naturally, they're very similar.

It seems that the client always assumes that the server does no 
content-rewriting, no matter what it returns. So it's incorrect to 
assume it makes specific assumptions about ETags on PUTs. It doesn't.

> You're probably quite right about the general case, that existing WebDAV 
> clients don't handle content-rewriting servers at all.  What's the best

Several clients handle it well, because they don't have a local content 
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP 
Netweaver KM.

> thing a content-rewriting server can do in this situation?  I would hope 
> that if a client receives neither an ETag nor a Last-Modified in a PUT 
> response, then the next time it synchronizes and sees an ETag that it's 
> never seen before, the client downloads the resource.  This allows the 
> content to eventually get synchronized although perhaps not as fast as 
> would be ideal.

As there's no guarantee in HTTP about content rewriting not occurring, 
clients should always re-sync (at some point of time). An optimization 
(which happens to be the one I've been proposing several times now) 
would be a way for the server to indicate that content was *not* 
rewritten, avoiding the additional retrieval.

> But CalDAV clients will have to handle content-rewriting servers at 
> least handling events (calendar component resources), because during 
> protocol development we heard from a couple server developers that 
> they'd need to add custom iCalendar properties to an event as soon as it 
> was stored, thus rewriting the content.

Yes. I'm not sure how this is different from the generic case, though.

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf