Re: webdav-collection-protocol-00: minor stuff

Thanks.  All good suggestions that I will follow.  Actually, rfc 2068 does
explicitly say that servers should ignore headers that they do not understand.

At 03:02 PM 6/9/98 PDT, Jim Davis wrote:
>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.
>
>
>
>
Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm

Received on Wednesday, 10 June 1998 11:11:03 UTC