webdav-collection-protocol-00: minor stuff

This is the fifth (and, for today at least, final) message on the ID for
advanced collection functions.  It deals only with minor issues such as
choice of names, editorial remarks, and mere typos in the ID.

section 2, paragraph 3: perhaps change first occurence of "many" to
"multiple".

Why do some headers have names beginning with "Referential-" and others
just "Ref-".  I prefer the longer form

3.2 Here's one way to state the justification you need.

The protocol extensions defined here use the extension mechanism specified
in [Nielsen et al., 1998] "Mandatory Extensions in HTTP".  Such an
extension mechanism is needed because this draft defines additional headers
for the HTTP PUT and WebDAV COPY and MOVE methods.  Without such a
mechanism, a client might invoke one of these methods on a server that does
not understand the headers.  Although RFC 2068 is silent on the point, it
is common for servers to ignore headers they do not understand.  In such a
case, the method would appear to succeed, yet not have the intended effect.
 The Mandatory Extensions mechanism ensures that a server will fail on any
message with headers that it does not understand.
 
section 3.2 paragraph five.  "refmember" should be "DAV:refmember"

You should state (in 3.2) the name of the URI that defines the extention
set you are defining.  You use DAV:Coll-headers" in the example in 3.2 but
examples should be illustrative not normative.

section 3.3 typo: "has no affect" should be "effect"

section 3.4  para 2 says: "If Depth = infinity in the PROPFIND request, the
server SHOULD NOT follow references ..."  I think, per requirement 3.1.4,
that this should be MUST NOT, should SHOULD NOT

section 3.5 para 1, 'refsource' should be 'DAV:refsource'

section 4 , para 1.  suggest adding to the sentence:

Multiple orderings of the same resources can be achieved by creating 
multiple collections referencing those resources 
                                                ^
                                     as referential members

section 6.  Should document that all these properties (except perhaps
ordering) are readonly, and that ordering is live, even if not read only.

Received on Tuesday, 9 June 1998 18:03:05 UTC