- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 12 Nov 1998 14:53:48 -0800
- To: ejw@ics.uci.edu
- cc: w3c-dist-auth@w3.org
>Roy Fielding agreed: >> I'll agree with Larry here -- I've been staying out of the debate >> largely because I don't understand the need for the requirement at all. > >The only problem is that I don't understand what constraint they're talking >about! Is this a discussion of case sensitivity, or namespace consistency? My comment was regarding the requirement that DAV capable resources be within a DAV collection. There is no need for that requirement and it is the root of many terminology issues. Any individual resource is capable of being or not being DAVable, as determined by either the capabilities described by an OPTIONS response or by the error response received when attempting to do a WebDAV operation on a non-DAV resource. "Save as..." dialogs are cool, but not necessary, for authoring. Eliminating the unnecessary requirement also removes any need to talk about how many different URI reference the same resource, or what might be the canonical preferred URI for a given resource. It just doesn't matter if the definition is based on the request semantics instead of a paricular idealized model of the URI namespace. Instead, just define what a collection contains (its own namespace) and how to get a representation of that collection. This was also the meat of the primary (aside from locking) objection raised in Mark Anderson's critique of section 5 within <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0099.html>. In fact, I'd recommend replacing much of the existing section 5 with the text he articulated, or at least merge it in so that it is clear what motivates the discussion and explain why the "source resource" reference is actually the most significant bit that DAV adds to HTTP. Because it is, and I'm getting a tired of explaining what a server is supposed to do when a client tries to PUT to a derived resource. ....Roy
Received on Thursday, 12 November 1998 18:07:28 UTC