RE: Summary of ETag related issues in RFC2518bis

Couldn't agree more with Geoff.
 
    dan


________________________________

	From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
	Sent: Thursday, December 22, 2005 05:54
	To: webdav
	Subject: Re: Summary of ETag related issues in RFC2518bis
	
	

	I believe that you are basing your conclusion on the assumption 
	that the authoring client can ignore the rewriting that is being

	done by the server.  In that case, I (and I'm reasonably sure,
Dan) 
	would agree that there is no need for the server to cancel the
LOCK. 
	
	But the case being discussed here is where the server has 
	rewritten the text and wants the client to base future edits on
the   
	rewritten text.  You may say "my server would never do that" or
even 
	"I would never use a server that did that" (in which case you
might 
	not want to spend any more time on this thread :-), but in case 
	the server did do that (and I have scenarios in which I can
imagine 
	a server wanting to do that), I believe that automatically
breaking 
	the lock is a good way of getting this point across to existing
clients 
	(who don't know about the 205 convention). 
	
	Cheers, 
	Geoff 
	
	Yves wrote on 12/22/2005 03:18:03 AM:
	> On Thu, 22 Dec 2005, Julian Reschke wrote:
	> 
	> >> Julian: I agree with you, but did you think Dan was
suggesting otherwise,
	> >> or were you just agreeing with Dan's statement (or at
least, with the
	> >> "yes, it's OK" part)?   I am assuming that you were not
disagreeing
	> >> with Dan, since I don't believe he suggests anything that
would make ETag
	> >> behavior depend on whether the resource was locked or not.
	> >
	> > I agree that servers can rewrite the content upon PUT, even
if theresource 
	> > is locked. I do not agree that they need to break the lock
to do that.
	> 
	> Agreed, lock is there to ensure other clients won't edit the
resource. The 
	> server can do what it wants.