Re: [Bug 23] lock discovery vs shared locks

Cullen Jennings wrote:
> ...
> That said, a skilled programmer still needs to be able to correctly
> implement and understand the protocol by just reading the spec and things it
> normatively references. The spec should help make this easy not hard. And if
> there is something that in the specification that a significant percentage
> of competent implementers might get wrong on the wire, the specification was
> probably not clear enough. 

Yes, and this is certainly the case here. As far as I can tell, there 
are two major problems (and possibly one minor problem) with RFC2518, 
and these should be fixed no matter what. In particular:

1) Normative text and examples are inconsistent. As almost all readers 
look at examples first and only read the rest when things do *not* work, 
making sure that examples are correct is extremely important.

2) The specification introduces two different ways to do things, where 
one would have been absolutely sufficient. To make things worse, one of 
the two things is flawed (it doesn't always work, so clients should not 
rely on in in the first place).

3) The given example at a minimum should have illustrated the potential 
problems with the second approach (for instance, by showing the result 
for the case that a second shared lock was created).

I wasn't part of the WG when this was written, but it certainly looks 
like the "Lock-Token" response header was introduced very late because 
somebody realized that the other approach simply doesn't work. 
Unfortunately, the spec wasn't checked properly for other changes to be 
made.

How to proceed?

a) Make the *fixes* to the spec we obviously need (fix the example to 
use the Lock-Token header and modify the response body so that it 
becomes clear why parsing it will be a bad idea)

b) Collect information what implementations do today (JimL, thanks for 
the feedback in this and all the other cases!).

c) Then decide about what else needs to be done.

Best regards, Julian

Received on Friday, 18 November 2005 06:00:21 UTC