Re: Issues remaining with Bind draft

Lisa Dusseault wrote:

> On Mar 18, 2004, at 5:29 AM, Julian Reschke 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.
> 
> 
> It's not good enough to say that if it's not forbidden, it's allowed.   
> Servers need to either allow this consistently, or disallow it  
> consistently.  Clients need dependable behavior.  The spec needs to say  
> something like "Servers MUST allow UNLOCK to succeed on a binding to a  
> locked resource (provided other conditions are met like lock token),  
> even if the locked resource was originally locked through another  binding.

The behaviour follows directly from what RFC2518 and the BIND spec say. 
The essential fact here is that live properties and locks belong to the 
state of the resource, so *unless stated explicitly otherwise*, the 
request URI does not matter. I think the BIND draft is very clear on 
that generic principle, and this is all we need.

>>> 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.
> 
> 
> Again, this needs to be clear in the spec.  Add language to the spec  
> saying "A lock created on any binding to a resource prevents exclusive  
> locks from being created on any other binding to the same resource."

But that follows from RFC2518's locking semantics. The request URI does 
not matter -- you are accessing the same resource, and thus it behaves 
as if you'd attempt the two locks on the same request URI.

>>> 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.
> 
> 
> So say that in the spec.

Sorry? Are you suggesting that anytime RFC2518 applies, we say that 
explicitly?

>>> 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.
> 
> 
> So say that in the spec.  This clearly needs to be said, because  
> several people have read the spec and come to different conclusions  
> about whether other bindings also appear as locked.

In which case I'd like to hear *how* they came to that conclusion.

> ...

>>> 2. Clarify that a VCR isn't just another binding (because different  
>>> VCRs pointing to the same VHR have different live properties, not 
>>> the  same ones)
>>> etc...
>>
>>
>> As DeltaV doesn't say that, I'm not sure why we would need to clarify  
>> that.
>>
> I had to do a fair bit of thinking and logical deductions to figure  
> that out, and I'm fairly experienced in this area.  Let's save  
> implementors that work and the risk of making an incorrect assumption.   
> A bindings section on the relationship of binding to the  
> resources/properties defined in DeltaV isn't too hard to write.

I'm still not sure which part of DeltaV is supposed to be unclear here. 
But if there is one, this should be fixed as an RFC3253 erratum.

>>> Questions on specific text
>>> -----------------------------------
>>> What does this mean (section 2.3, second-last paragraph): "If 
>>> because  of multiple bindings to a resource, more than one source 
>>> resource  updates a single destination resource, the order of the 
>>> updates is  server defined."
>>>
>>> I don't understand the case when more than one source resource  
>>> updates a single destination resource.
>>
>>
>> This can happen when, for instance, you copy /a with members /a/b and  
>> /a/c (bindings to different resources) to a destination /d with  
>> members /d/a and /d/b (bindings to the same resource). The end result  
>> will be that /d/a and /d/b are still bindings to the same resource,  
>> but the spec doesn't guarantee whether it'll be the content of /a/b 
>> or  /a/c. It's an edge case.
>>
> Do you mean you're copying /a so that it becomes a child of the  
> destination /d or so that it overwrites the destination /d?

The latter.

> ...

>>> Section 2.4
>>> " When DELETE is applied to a collection, it MUST NOT modify the  
>>> membership of any other collection that is not itself a member of 
>>> the  collection being deleted. For example, if both "/a/.../x" and  
>>> "/b/.../y" identify the same collection, C, then applying DELETE to  
>>> "/a" MUST NOT delete an internal member from C or from any other  
>>> collection that is a member of C, because that would modify the  
>>> membership of "/b"."
>>> I don't understand why there's a conditional on the first sentence 
>>> of  "that is not itself a member of the collection being deleted". 
>>> When  would the membership of any other collection be modified? In  
>>> particular,
>>
>>
>> It shouldn't. That's the point of the statement.
> 
> 
> If you agree with me, then the text should simply read:
> 
> "When DELETE is applied to a collection, it MUST NOT modify the  
> membership of any other collection.  For example, if both [continue  
> text unchanged...]"

Well, it *may* change the membership of member collections.

>>> C is a descendant (not a direct member) of /a, but even if it were a  
>>> direct member, it seems the rule should apply.
>>> Section 6 -- REBIND method
>>> One precondition is " (DAV:binding-allowed): The resource identified  
>>> by the DAV:href supports multiple bindings to it." How can this 
>>> error  possibly occur?
>>
>>
>> If a part of your namespace doesn't allow multiple bindings.
> 
> 
> This is in a case where the resource already allowed multiple bindings,
> one of the bindings is simply being rebound.  So "DAV:binding-allowed"  
> means either that the resource doesn't support multiple bindings, OR  
> that the URI namespace area doesn't support multiple bindings?

OK, now I see. This precondition also exists on BIND (where it makes a 
lot of sense), however I'm not sure why we would need it for REBIND. 
Geoff, do you remember why it appears here?

>>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
>>> there's  a compelling reason for backward compatibility.
>>
>>
>> No, it should. REBIND is a "strong" MOVE (that will never attempt a  
>> "weak" resource move using COPY/DELETE). That's the only semantical  
>> difference to MOVE, and thus locks behave just like they do with MOVE.
> 
> 
> I disagree, but in either case, the spec needs to say this one way or  
> another.

OK, we may have to add this piece of information, because it's not obvious.

>>> Does REBIND change the ETag of a resource? Does it change the  
>>> getlastmodified value of the resource?
>>
>>
>> Same as MOVE (which means: usually not).
> 
> 
> Can't we be more specific about this?

No, we can't. It *will* be the same as for MOVE, and for MOVE there's no 
guarantee whatsoever.


Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 18 March 2004 13:51:40 UTC