Re: Issues remaining with Bind draft

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.

>> 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."

>> 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.

>> 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.

>> 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.

etc...

>> underlying resource, is there any way to tell when a binding was
>
> No.
>
>> created? and vice versa?
>
>> B - Issues related to versioning features (massively incomplete), or  
>> how does a server supporting bindings and versioning work
>> 1. If a resource is checked out, do all bindings appear checked out?  
>> (In general, are all the live properties defined in versioning the  
>> same on all bindings?)
>
> Yes, again; that's the nature of bindings.
>
>> 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.

>> 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?

>> I also don't see how this could arise: " If a COPY request would  
>> cause a new resource to be created as a copy of an existing resource,  
>> and that COPY request has already created a copy of that existing  
>> resource, the COPY request instead creates another binding to the  
>> previous copy, instead of creating a new resource."
>
> See  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -03.html#rfc.issue.2.3_COPY_SHARED_BINDINGS>.
>
>> 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...]"

>
>> 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?

>
>> 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.

>
>> 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?

Lisa

Received on Thursday, 18 March 2004 13:16:41 UTC