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 18:27:09 +0100
Message-ID: <437B6BED.4000602@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:
> 
> 
> On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote:
> 
>>
>> Lisa Dusseault wrote:
>>> I agree there's a fair argument for allowing servers not to put lock 
>>> tokens in lockdiscovery all the time. I can clarify the text there 
>>> because there certainly isn't a consensus to require servers to do that.
>>> We could, however, treat the LOCK (create lock) response slightly 
>>> differently, and require that the body contains the lockdiscovery 
>>> property *including* the new lock token -- a special case to handle 
>>> those clients that had problems at Interop tests.
>>
>> This does not make any sense. Sorry.
>>
>> It's the "Lock-Token" response header that *always* contains the 
>> result. Why do you insist on changing the spec so that there's a 
>> second mechanism?
>>
> Because that was the rough consensus at the Interop that year, amongst 
> the people there, and I don't want to overthrow that too lightly.  As 
> soon as Cullen declares that there's a consensus for a single mechanism, 
> I'll edit the spec according to the consensus.

Ultimately, consensus needs to be found in the WG (== the mailing list), 
not at a meeting. I don't recall any discussion over here about 
requiring the response body. Did I miss something?

Best regards, Julian
Received on Wednesday, 16 November 2005 17:28:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT