Review of draft-ietf-webdav-bind-01.3

Hi,

I've done another review of the current draft ([1]) and found some minor
issues. Maybe we can submit a new draft as last call draft once they are
resolved.


#1 Section 1, Introduction

Maybe the last paragraph should contain references to the new sections about
BIND and REBIND (also, the HTML version has an unresolved reference here)


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


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


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


#5 Section 2.2

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


#6 Section 2.3

"spechified"


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


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


#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)


#10, Section 3

Shouldn't we adopt the DAV:allprop behaviour from RFC3253?


#11, Section 6, Preconditions

Isn't DAV:protected-url-modification-allowed also required for UNBIND?


#12, Section 13, References

draft-rfc-editor-rfc2223bis-06 seems to prefer "Normative References"




That's it!


Regards, Julian

[1] <http://www.webdav.org/bind/draft-ietf-webdav-bind-01.3.htm>
[2]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-09.htm
l#rfc.section.1.p.3>
[3]
<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.h
tml>

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

Received on Tuesday, 24 June 2003 11:11:12 UTC