aliasing and other (primarily) editorial issues with -protocol-08

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