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

Re: [Bug 23] lock discovery vs shared locks

From: Cullen Jennings <fluffy@cisco.com>
Date: Wed, 16 Nov 2005 12:37:34 -0800
To: Julian Reschke <julian.reschke@gmx.de>, Lisa Dusseault <lisa@osafoundation.org>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>
Message-ID: <BFA0D88E.60CF0%fluffy@cisco.com>

On the call this morning, I thought that Geoff outlined 3 proposals

1) change nothing (assuming says MUST put in header)
2) don't change how anything works today but add the clarifying statement
that servers MAY NOT put it in a body
3) change to say that servers MUST put in both body and header

Now I might have the descriptions of these three all wrong but I am pretty
sure that I heard that 1 or 2 worked for someone and 2 or 3 worked for
someone else and that 2 worked for everyone. I thought we decided to put 2
in the next rev of the *draft* and then ask the WG (folks on the list
including people on this thread) had a problem with that draft.

What part of this did I not get? What are we still discussing?

On 11/16/05 12:23 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 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:37:44 UTC

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