W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 16 Nov 2005 21:23:06 +0100
Message-ID: <437B952A.5010300@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, webdav <w3c-dist-auth@w3.org>

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 


> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC