Re: What is actually locked?

Patrik asked: "Now, Lisa, you seem to either not agree with this view, 
or that the document doesn't specify this clearly enough. Can you 
(Lisa) clarify?"

Yes, I've had various discussions where it seemed that if one binding 
to a
resource was locked then other bindings also had to appear locked, and
I've had other discussions where it seemed the other way.  Reading the
specification might lead a person to one conclusion, but it might lead 
them
to the other conclusion.  By now I've read the spec many times, but I 
recently
reread it carefully and tried to do so with an open mind, and I found 
that it
is unclear -- it is difficult to integrate statements from different 
sections of
the draft to come to a conclusion.  It's not merely that this is more 
work for
the reader of the spec, but it is also prone to parsing and integration 
errors.

Some of the details resulting from the lock model are even more 
definitely
unclear.  For example, can a client use UNLOCK on a binding that isn't 
the
one that was locked?  If not, what's the error?  The spec must say 
whether
a server MUST support UNLOCK on all bindings to a locked resource.

It's my belief that interoperability will suffer from the readability 
problems
in this specification.

Lisa

On Apr 5, 2004, at 12:04 PM, Patrik Fältström wrote:

>
> Julian wrote:
>
>> Lisa Dusseault wrote:
>>
>>> A - Issues relating to 2518 features
>>> 1. Can you UNLOCK a URI that binds to a locked resource, when that 
>>> URI
>>> wasn't directly locked? If not, what's the error?
>>
>> I can't see any language in RFC2518 and/or BIND saying that you can't,
>> so you can. UNLOCK removes the lock identified by the lock token 
>> header
>> from the resource identified by the request URI, so the actual URI 
>> being
>> used for UNLOCK is irrelevant.
>>
>>> 2. Can you LOCK a URI that binds to a locked resource, when that URI
>>> wasn't directly locked? If not, what's the error?
>>
>> You can, as long both locks are compatible (that is, none of them is
>> exclusive). So the situation here is exactly as if you use the same
>> request URI.
>
> To me the above show some communication issues. It continues:
>
>>> 3. In If header evaluation, does a URI "match" a lock token, when 
>>> that
>>> URI wasn't directly locked but the underlying resource was locked 
>>> with
>>> that token?
>>
>> The If header matching description
>> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)
>> talks about resources, not URIs, thus it's not relevant which URI you
>> provide as long as it identifies the right resource.
>>
>>> 4. What exactly does lockdiscovery show on a locked binding? On a 
>>> locked
>>> resource accessed through an unlocked binding? Does 'lockdiscovery' 
>>> look
>>> exactly the same on every binding to a locked resource?
>>
>> Yes. The lock belongs to the state of the resource, so PROPFIND 
>> returns
>> the same operation no matter which binding you use.
>>
>>> 5. What does creationdate refer to, I assume it's the creationdate of
>>> the underlying resource (not the creation date of the binding)? If 
>>> the
>>
>> Yes.
>>
>>> underlying resource, is there any way to tell when a binding was
>>
>> No.
>>
>>> created? and vice versa?
>
> It seems Julian is talking about locking always being on the resource, 
> regardless of what binding was used. This imply it is completely 
> irrelevant what binding has happend, what URI is used etc to reach the 
> resource. If the resource is locked it is.
>
> Now, Lisa, you seem to either not agree with this view, or that the 
> document doesn't specify this clearly enough.
>
> Can you (Lisa) clarify?
>
>    paf
>

Received on Monday, 5 April 2004 15:53:51 UTC