Re: Issues remaining with Bind draft

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.

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

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

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

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

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

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

> Does REBIND change the ETag of a resource? Does it change the 
> getlastmodified value of the resource?

Same as MOVE (which means: usually not).

Regards, Julian

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

Received on Thursday, 18 March 2004 08:29:38 UTC