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.