Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Julian Reschke <julian.reschke@gmx.de> Tue, 25 July 2006 20:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TWn-0007uN-Rx; Tue, 25 Jul 2006 16:29:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TWm-0007s1-6D for ietf@ietf.org; Tue, 25 Jul 2006 16:29:16 -0400
Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5TWj-0008B2-MZ for ietf@ietf.org; Tue, 25 Jul 2006 16:29:16 -0400
Received: (qmail invoked by alias); 25 Jul 2006 20:29:12 -0000
Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp042) with SMTP; 25 Jul 2006 22:29:12 +0200
X-Authenticated: #1915285
Message-ID: <44C67F07.1050802@gmx.de>
Date: Tue, 25 Jul 2006 22:28:55 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
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>
In-Reply-To: <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local>
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: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: Ted Hardie <hardie@qualcomm.com>, 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
Cyrus Daboo schrieb: > Hi Julian, > > --On June 5, 2006 8:30:25 PM +0200 Julian Reschke > <julian.reschke@gmx.de> wrote: > >> I notice that draft-dusseault-caldav-12 now is in IESG Evaluation >> (<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag >> =11253>). >> >> For the record: as far as I can tell, the issue that I raised below is >> critical (given the fact that we have a separate activity to clarify this >> in HTTP), and has not been addressed. It's not clear to me whether the >> client issue it attempts to solve really is important. If it is, there is >> a simpler way to accomplish this ([1]) that doesn't risk making CalDAV >> incompatible with other specs extending HTTP (or HTTP itself, for that >> matter). > > We are planning on addressing this ETag issue in a revision now that > last-call is over. Authors are discussing right now. The new text says (<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-13.html#rfc.section.5.3.4.p.2>): "A response to a GET request targeted at a calendar object resource MUST contain an ETag response header field indicating the current value of the strong entity tag of the calendar object resource. Servers SHOULD return a strong entity tag (ETag header) in a PUT response when the stored calendar object resource is equivalent by octet equality to the calendar object resource submitted in the body of the PUT request. This allows clients to reliably use the returned strong entity tag for data synchronization purposes. For instance, the client can do a PROPFIND request on the stored calendar object resource and have the DAV:getetag property returned, and compare that value with the strong entity tag it received on the PUT response, and know that if they are equal, then the calendar object resource on the server has not been changed. In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request." Again, this profiles HTTP in a way that may turn out to be incompatible with the way the issue will be resolved in general; also this conflicts with ETag requirements in XCAP, which is also under IESG evaluation. By all means, please let this issue be clarified in a *single* place and in a way consistent for all HTTP resources. Also note a proposal was made back in April how CalDAV *could* resolve the syncing issue without relying on a specific ETag behavior which may not be the one a clarification of HTTP yields (see [1]). It would have been nice if the authors would have given feedback on why the proposed solution doesn't work for them. Best regards, Julian [1] <http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Last Call comment on Etag requirements in draft-d… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- 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… Cyrus Daboo
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Peter Dambier
- Re: [Ietf-caldav] Last Call comment on Etag requi… Lisa Dusseault
- 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… 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… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Julian Reschke
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- 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… Robert Sayre
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega
- Re: PMTUD Milestones past due Matt Mathis
- Re: [Ietf-caldav] Last Call comment on Etag requi… Wilfredo Sánchez Vega