RE: a critique of webdav-protocol

Mark,

Obviously it is going to take some time to respond to your massive set of
comments.  However, given that this WG last call was made so that WG members
could examine the changes made going from the -08 to -09 revision, and since
many, many of your "objection" comments are criticisms of design choices
made long ago (in some case over a year ago), or ask that design decisions
be explained in the text, please don't be surprised if you get many answers
along the lines of "thank you for your comment, the spec. stands as-is."

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Mark D. Anderson
> Sent: Friday, October 30, 1998 7:41 PM
> To: WEBDAV WG
> Subject: a critique of webdav-protocol
>
>
> This is a long response to the draft-ietf-webdav-protocol-09.txt.
> I realize it borders on ranting; I apologize in advance for
> any toes I step on. I regret I haven't gotten to this sooner.

In fact, for the type of comments you're making, the last call for comments
was January-March, 1998.  We held two 3.5 week long WG last calls, and then
held another 2 week IETF-wide last call.  This spec. wasn't a secret, and we
went out of our way to solicit comments.

> The upshot is that I think the draft is irretrievably flawed in
> conception and execution, and should not advance in the standards
> process in anything approaching the form it is in now.

The rough consensus of a working group of ~300 people begs to differ.

> I realize most WG members will disagree with this conclusion;
> those who might agree probably abandoned the group long ago.
> Perhaps some of my comments will inspire minor improvements
> in the likely event that you decide to advance it.

This is why your comments will be examined.

> To summarize:
> - The property framework needs to be pulled out of this, and
> either abandoned in favor of another or proposed on its own.
> - Locking needs to be deferred to a full proposal for ACL
> (and possibly versioning), and may not need to be specially
> handled at all.
> - That leaves a proposal for COPY, MOVE, and MKCOL --
> one which is both imprecise and ill-conceived.

Nevertheless, empirically this specification has formed the basis for
interoperability between client-server pairs implemented to it.

*sniiiiiiiiiiiip*

- Jim

Received on Saturday, 31 October 1998 02:54:43 UTC