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?