Subject: Yaron.Redirect.S7P1

From: Yaron Goland <[email-masked]>
Date: Thu, 10 Feb 2000 23:50:21 -0800

The first sentence of the first paragraph of section 7 reads: "A URI of a
redirect reference resource can be an internal member URI of a collection
just as the URI of a non-reference resource can. "
Given the previous comments it would seem that this sentence needs to be
rewritten to specify that all the resources involved must be WebDAV
compliant. It is not enough that the parent of a redirect resource is a
WebDAV compliant collection. The redirect resource itself needs to be WebDAV
compliant.
However, specifying all this would only reproduce the namespace requirements
stated in RFC 2518, requirements that apply to all WebDAV compliant
resources regardless of their type. Hence a reasonable reader is likely to
draw the conclusion, based on this sentence, that RFC 2518 is wrong and that
there do potentially exist WebDAV compliant resources that are the children
of WebDAV compliant collections that may not be internal members of that
collection. After all, were this not so, it would not be necessary to
explicitly state that redirect resources can be the child of a WebDAV
collection.
As this sentence seems to clarify something that does not require clarifying
and as it does it in a manner likely to produce confusion. I move that it be
deleted.

The last sentence of the first paragraph of section 7 reads: " The methods
that can accept a Depth header are PROPFIND, COPY, MOVE, DELETE, and LOCK."
As a general rule of thumb it is a bad idea to give lists in standards for
features that can and will change. A reader seeing this sentence would come
to the conclusion that the Depth header can only be used with the listed
methods. This is, of course, false. The Depth header may be used with any
number of methods that have yet to be defined. While I suppose we could
qualify this sentence to say that this is the list of methods that use Depth
known at the time the standard was written I can find no utility for such a
statement. As such I propose that this sentence be removed from the spec.