Issues remaining with Bind draft

I've re-reviewed the bind draft.  Many of these issues have come up 
before but I feel they haven't been resolved in the draft.

General
-----------

The spec must stand alone, not be dependent on changes to RFC2518 in 
'bis'.  Otherwise, bind can't be approved until RFC2518bis is approved. 
  That means no dependencies for things like 'lockroot'.

In general, the spec needs more info to specify how existing things 
work.  All the following questions must be answered in the spec, NOT 
just in email.  The spec must be explicit, because different people 
reading a model description always end up with different ideas how the 
model works in practice.

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?
   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?
   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?
   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?
   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 underlying resource, is there any way to tell when a binding was 
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?)
   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...


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.

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

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

Does REBIND destroy locks, as MOVE does?  It shouldn't, unless there's 
a compelling reason for backward compatibility.

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