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

   Sure, OK, so some clients are broken today because they make some  
assumptions that are only valid on some server implementations.

   We know we need a solution; I just don't agree that CalDAV is the  
right place to specify it.  I do understand how it's convenient.

	-wsv

On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:

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

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

1A-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>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <66682F0C-92F3-45E9-B59A-FB5D34561913@apple.com>
Content-Transfer-Encoding: 7bit
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@apple.com>
Date: Mon, 19 Jun 2006 12:58:28 -0700
To: Lisa Dusseault <lisa@osafoundation.org>
X-Mailer: Apple Mail (2.750)
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-Mailman-Approved-At: Thu, 29 Jun 2006 08:20:30 -0400
Cc: Julian Reschke <julian.reschke@gmx.de>, 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

   Sure, OK, so some clients are broken today because they make some  
assumptions that are only valid on some server implementations.

   We know we need a solution; I just don't agree that CalDAV is the  
right place to specify it.  I do understand how it's convenient.

	-wsv

On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:

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

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