W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Comments on bind-08

From: Jim Whitehead <ejw@cs.ucsc.edu>
Date: Mon, 29 Nov 2004 14:03:57 -0800
Message-Id: <200411292204.iATM45vm026136@cats-mx3.ucsc.edu>
To: "WebDAV \(WebDAV WG\)" <w3c-dist-auth@w3.org>

I gave the latest WebDAV Bindings Protocol specification a careful read
today, and was generally very impressed by the solidity of the
specification. I have a number of comments (below) which mostly seek to
clarify the intent of the specification. I'm fine with these being
considered last-call comments if the WG wants to proceed with a WG last call
on the -08 specification -- IMO, the specification is certainly ready for
such a review.

Also, I'm not sure whether current WG practice is for those submitting
comments to directly enter them into the issue tracking system. If so, let
me know, and I'll enter these in.

OK, the comments:

* Terminology section (1.1): There is a reference to
draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs
elsewhere in the specification as well). References in RFCs need to be to
documents of RFC level stability (or equivalent). If
draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should
just revert back to RFC 2396.

* Section 2, paragraph 3. The language here would preclude the future
definition of a DESTROY method which had the semantics of removing the state
of a resource from a server, irregardless of any containment relationships
that may hold it. Such a method could be quite useful for records management
functionality, in order to implement a records disposition policy that
specified deletion at a certain time. My recommended tweak to the language
of section 2 is minor: add the following sentence to the end of the
paragraph:

"It is permissible, however, for future method definitions (e.g., a DESTROY
method) to have semantics that remove all bindings and/or immediately
reclaim system resources."

* Section 2.1. I think it would be more clear to separate out the discussion
of loops and bindings, and make it a separate section (say, 2.2) This issue
comes up frequently enough that it would be good to make it easy to find
this issue in the TOC. Also, a mention of the Already Reported status code
would be good to have here, since it also mentions 506.

* Section 2.3. This section doesn't clearly address the semantics of COPY
with Depth infinity. My recommendation is to add, after paragraph 3, text
like this:

"As specified in [RFC2518], a COPY with Depth infinity causes the collection
resource to be duplicated, all of its bound children to be duplicated, and
their children's bound children, and so on, to the bottom of the containment
hierarchy. All of the segments of the bindings of the destination collection
are the same as for the destination collection. However, the destination
resource for all bindings in the destination collection are different from
those of the source collection, since all resources have been duplicated,
creating new resources with distinct DAV:resource-id properties."

* There should also be some text addressing COPY depth infinity and loops --
in some instances during a COPY with Depth infinity, the server really wants
to recreate the binding that causes the loop, rather than continuing to make
duplicate resources. This is somewhat addressed by the final paragraph in
Section 2.3, but not exactly.

* One gap in the current COPY semantics is the ability to copy a collection
and its bindings. COPY depth 0 says copy all non-binding state. COPY depth
infinity copies all bindings and makes duplicates of all bound resources.
But, there's no single atomic operation (call it BINDDUP) that duplicates
the collection and its bindings, but doesn't duplicate the bound resources.
That is, there is no operation that does a COPY Depth 0 plus BIND for all
members. So, two questions. Is there a compelling scenario for having a
BINDDUP method? I confess I'm having a hard time coming up with one. Second,
assuming there is a compelling scenario, can it be accomplished just using
COPY, LOCK, and BIND, rather than having a special purpose method. Also
unclear.

* It might make sense to create an example covering the situation described
in the final paragraph of Section 2.3. I'm not 100% sure I know what
scenario this paragraph addresses, other reading the spec. for the first
time would presumably have a tougher time.

* Section 2.4, second paragraph. "MUST NOT" is used in the text of an
example -- seems like it should be lower case here instead.

* Section 2.6 -- there needs to be some discussion on the interactions of
DAV:resource-id and versioning. As near as I can tell, the intent is that
every revision will have a unique DAV:resource-id value.

* Section 2.6 -- I think it would help clarify the text to say that one
possible implementation technique is to use a GUID for the unique
identifier, and then reference the same GUID document as is referenced in
RFC 2518.

* Section 2.6, final paragraph, last two sentences. Change "must not" to
"MUST NOT" (and eliminate the "For example" at the start of the sentence --
perhaps change to "Specifically,"

* Section 2.6. Need to add a note indicating that REBIND does not affect the
value of DAV:resource-id.

* Section 3.2, final sentence -- delete the word "either", add a comma after
"or".

* Section 3.2. I think it would be helpful to have an example of this
property. I'd be happy to help develop such an example.

* Section 4. The intent of the BIND method is for its behavior to be atomic.
However, this is never actually stated explicitly in the specification.
Seems like it should be.

* Section 4. Need a new condition to cover the case where the BIND
half-succeeded, and then needed to be rewound. This condition would address
the case where Overwrite is true, the destination binding has been removed,
but the new binding couldn't be created.

* Section 4.1, final sentence. Remove comma after the URI.

* Section 5. Same comment as for BIND. The intent of UNBIND is that it's
supposed to be atomic, but that's never explicitly stated.

* Section 5. I think we need a condition for a cross-server UNBIND failure.

* Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be
atomic, but this is not explicitly stated.

* Section 6. Should precondition DAV:rebind-into-collection be named
DAV:rebind-from-collection, to mirror the similar precondition for UNBIND?

* Section 6. Precondition DAV:rebind-source-exists is incorrect. The
DAV:href element identifies the destination binding to be created, not the
source. Seems like this precondition, and the previous one, reflect an older
marshalling of the arguments.

* Section 6.2. I think it would be helpful to have an example including
REBIND and locks, showing submission of one or more lock tokens in the If
header.

* Section 7.1.1. Might just be a personal preference, but I'd rather see
plain GUIDs rather than opaqulocktoken URI GUIDs in the example.

That's it.

- Jim
Received on Monday, 29 November 2004 22:07:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC