Re: Review of draft-ietf-webdav-bind-01.3

Julian wrote on 06/24/2003 11:11:05 AM:


> #1 Section 1, Introduction
> 
> Maybe the last paragraph should contain references to the new sections 
about
> BIND and REBIND

Done.

> (also, the HTML version has an unresolved reference here)

Fixed.
 
> #2 Section 1.1, Terminology
> 
> We may want to add language that explains how the DTD fragments are to 
be
> interpreted (similar to [2]). Similarily, we may want to "import" the
> definitions for pre/postconditions and for error response bodies from
> RFC3253.

Done.

> #3 Section 1.2
> 
> "The authors of this specification anticipate and recommend that future
> revisions of [RFC2518] will update the definition of the state of a
> collection to correspond to the definition in this document."
> 
> -> Is that on the RFC2518 issues list yet.

Jason says yes.

> #4 Section 2.1
> 
> Artwork: can we remove the "(properties)" line from the collection 
boxes? It
> seems to imply that the state of a collection is defined just by 
properties
> and bindings (however, a collection may also have content).

Done.

> #5 Section 2.2
> 
> Please replace "URI's" by "URIs" (several times) for consistency with
> RFC2396bis ([3]).

Done.
 
> #6 Section 2.3
> 
> "spechified"

Fixed.
 
> #7 Section 2.5, last paragraph
> 
> "Although [RFC2518] allows a MOVE on a collection to be a non-atomic
> operation, a MOVE implemented as an UNBIND MUST be atomic."
> 
> I think this should be "REBIND" rather than "UNBIND".

Fixed (thanks for noticing that!)
 
> #8 Section 2.6 "sameness of resource"
> 
> "Two resources might have identical contents and properties, but not be 
the
> same resource (e.g. an update to one resource does not affect the other
> resource)."
> 
> I think there's also the possibilty of multiple URIs identifying the 
same
> resource (as per the above definition), yet the multiple URIs not 
behaving
> like the BIND spec requires. For instance, consider an HTTP server that
> responds to multiple port numbers, yet serves the "same" URL namespaces,
> such as
> 
> http://foo/x/y and http://foo:81/x/y where /x/y is a resource that's
> persisted in the same backend. Both URIs identify the same resource, yet
> applying DELETE to one of them will affect the other one as well. I 
think
> the spec needs to say something about this situation.

In this case, http://foo/x and http://foo:81/x identify the same 
collection,
so of course a DELETE of a binding in http://foo/x will be reflected in 
all
other URIs that are mapped to that collection (e.g. in http://foo:81/x).
So this behavior is as predicted by the semantics of bindings.

> #9 Section 2.6, paragraph 4
> 
> "A COPY, since it creates a new resource at the Destination URI, must 
assign
> a new, unique value to its DAV:resource-id property."
> 
> (only if it's not a copy overwrite=t to an existing destination)

Good point!  Fixed.
 
> #10, Section 3
> 
> Shouldn't we adopt the DAV:allprop behaviour from RFC3253?

Done.
 
> #11, Section 6, Preconditions
> 
> Isn't DAV:protected-url-modification-allowed also required for UNBIND?

Currently, this is specified by DAV:locked-overwrite-allowed, but that is 
not
a good tag name.  I'll change this to be: 
DAV:protected-source-url-deletion-allowed.
 
> #12, Section 13, References
> 
> draft-rfc-editor-rfc2223bis-06 seems to prefer "Normative References"

Done.

> That's it!

Thanks for the careful review!  I'll send this off as a new internet 
draft.

Cheers,
Geoff

Received on Friday, 27 June 2003 12:05:33 UTC