Re: [Bug 23] lock discovery vs shared locks

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