W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1998

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

From: Judith Slein <slein@wrc.xerox.com>
Date: Wed, 10 Jun 1998 07:49:34 PDT
Message-Id: <>
To: Jim Davis <jdavis@parc.xerox.com>
Cc: slein@wrc.xerox.com, w3c-dist-auth@w3.org
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
>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC