Re: [Bug 23] lock discovery vs shared locks

Lisa Dusseault wrote:
> I checked back in the email archives, and it looks like there was a very 
> closely related discussion which I thought covered it but it didn't get 
> into this specific issue.  Naturally consensus needs to be found in the 
> WG and I'm sure we can accomplish this.  So are there any other opinions 

(nod)

> on whether the server MUST return the lock token in the body as well as 
> the header of a response when a new lock is created -- even though we 
> all agree the server doesn't need to normally put that info in the 
> lockdiscovery property?

Making a normative change to the spec because of specific broken clients 
IMHO is as bad as the other way round. Just because we say so will not 
resolve the interop issue, if it still exists. Does anybody know whether 
this is still the case?

To me, this seems to a a perfect example, for an interop guide, not a 
change to the spec.

Such as:

1) What to do if the LOCK request suceeds, but no Lock-Token respnse 
header is there (answer: complain to the server vendor, and then in the 
worst case check the response body).

2) What to do if a PROPFIND response contains *multipple* 
<lockdiscovery> properties? (answer: complain to the server vendor, 
and/or assume that this is this server's idea how to return info about 
shared locks).

We've talked about a document like that several times. Should I start one?

Best regards, Julian

Received on Wednesday, 16 November 2005 20:23:54 UTC