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

From: "Julian Reschke" <[email-masked]>
Date: Tue, 24 Jun 2003 17:11:05 +0200

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 27 Jun 2003 12:05:30 -0400

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

> BIND and REBIND

Done.

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

Fixed.
 
> definitions for pre/postconditions and for error response bodies from

Done.

> -> Is that on the RFC2518 issues list yet.

Jason says yes.

> and bindings (however, a collection may also have content).

Done.

> Please replace "URI's" by "URIs" (several times) for consistency with

Done.
 
> "spechified"

Fixed.
 
> I think this should be "REBIND" rather than "UNBIND".

Fixed (thanks for noticing that!)
 
> 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.

> (only if it's not a copy overwrite=t to an existing destination)

Good point!  Fixed.
 
> Shouldn't we adopt the DAV:allprop behaviour from RFC3253?

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