- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 8 Sep 1998 23:58:11 PDT
- To: "Webdav" <w3c-dist-auth@w3.org>
I've owed it to the group to submit an analysis of -protocol-08 over the issue of URL aliases; I apologize for the delay. As you may recall, the issue I raised was one of whether the webdav draft required that a DAV-compliant resource had one, and only one, URI. I pointed out the various situations of aliasing, of which 'case sensitive URI' is only one instance, but other kinds of aliasing might also be possible. A collection is a resource whose state consists of at least a list of internal members and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member resource MUST have a URI that is immediately relative to the base URI of the collection. That is, the internal member's URI is equal to the parent collection's URI plus an additional segment where segment is defined in section 3.2.1 of RFC 2068 [Fielding et al., 1996]. In this paragraph, it isn't clear whether "MUST have a URI that is ..." means "MUST have only one URI; that URI is ..." or "MUST have at least one URI which is ..." that is, is the requirement of the member resource be that it has no aliases anywhere, or just that aliases are out of scope, or is it just that the requirement on member resources be that there is at least one way of accessing it. Now, if it is allowed that referent of "the internal member's URI" is "the URI that fits the description above", i.e., an internal member might also have other URIs too. Any given internal member MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Perhaps you mean "e.g." instead of "i.e." here; that is, the example of 'the same URI' is one way of having 'the same resource' in a collection; but it is probably intended that it be illegal to have "Ford" and "FORD" as elements of the "Cars" collection, if the server is case insensitive, even though their URIs aren't 'the same'. I will note the curious phrase under 'locking': Some servers automatically replicate resources across multiple URLs. In such a circumstance the server MUST only accept a lock on one of the URLs if the server can guarantee that the lock will be honored across all the URLs. and note that this might be considered a kind of aliasing, but seems to also allow for other operations ("replication"). In any case, these are, as far as I can tell, the only places in the entire WebDAV protocol document anything that hint at requirement that a resource have only one URI. Adding that requirement in order to be WebDAV compliant would seem to eliminate popular features of web servers; eliminating the confusion and clarifying that a resource might have multiple URIs would improve the spec. Having done so, there seems to be no good reason to require that the multiple URIs for a resource have the same parentage property. In some ways, this just means that clients cannot easily be interoperable if they have some need to perform a (currently unsupported) DAV operation of "going up the parent tree". However, it's not clear, at this point, whether "going up the parent tree" is a necessary operation, so my original call for adding it may be moot. Mainly all we need is to remove the presumption that one can "go up the parent tree" merely by manipulating the URI used to originally access the resource. ----------------------------------- A few minor (editorial) issues that occurred to me as I was looking for areas that might affect this: Throughout the document, the phrases "DAV compliant server" and "DAV complaint resource" are used. But what is the scope of a DAV compliant server? Is it required that all resources served by a DAV compliant server be DAV compliant resources? In the middle of the document, there is the phrase "DAV compliant proxy". However, section 14, DAV Compliance Classes, only describes the compliance classes for DAV resources, and not for servers or proxies. Is a "Dav compliant resource" one that is served by a DAV compliant server, then? Or are some resources served by DAV-compliant servers themselves not DAV-compliant? What are the new requirements for "DAV compliant proxy" that are not requirements for HTTP/1.1 proxies? (That there would be any is curious for a protocol whose T-shirt proclaims it to be Firewall Friendly.) WebDAV servers MUST treat HTTP URL namespaces as collections, regardless of whether they were created with the MKCOL method described in section 7.3. So presumably all http: URLs served by a WebDAV (compliant) server, when the URL is a "namespace" (which, although not defined, I assume means "terminated with "/") are supposed to also function as DAV (compliant?) collections.
Received on Wednesday, 9 September 1998 03:01:49 UTC