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

RE: multiple parents

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 2 Sep 1998 17:42:46 -0700
To: w3c-dist-auth@w3.org
Message-ID: <001501bdd6d3$c4d85f80$d115c380@galileo.ics.uci.edu>

> The concern is that protocol-07, as written, doesn't allow interoperable
> implementation with a server that employs aliasing, and makes
> some requirements on servers that wind up being (false) assumptions that
> clients will make.

I don't think there were any changes between -07 and -08 which affect this
discussion, but just to make sure we're all talking about the same rev. of
the spec., the latest revision of the WebDAV Distributed Authoring Protocol
specification is -08. The Web page is a bit confusing, since it has a "click
here for changes from -07" link, but doesn't state that the current rev
is -08 quite as prominently -- I should change this.

> I think that it's simple to fix the protocol by adding a "parent"
> property, and removing the language that requires clients to munge
> 'the' URL for a resource in order to find the parent. With this fix,
> the 1-1 relationship between 'resource' and 'resource locator' wouldn't
> be mandated for all implementations (although it would be allowed).

Well, if performing string manipulations to discover a parent of a resource
is a "munge", then it is no worse a munge than those perpetrated by relative
URLs.
Section 3 of RFC 2396 ("Uniform Resource Identifiers (URI): Generic Syntax")
discusses hierarchical URI schemes, and explicitly notes that the slash
character is used to separate hierarchical components. In Section 5 of this
document, there is discussion of the meaning of ".." as it appears within a
relative URI.  So, there seems to be significant, Draft Standard precedent
for performing string manipulations on a URI to find its parent.

> With "case insensitivity", you might treat "http://host.dom/PATH/x" the
> same as "http://host.dom/Path/x" and "http://host.dom/PaTh/x".

True.  Although seems to me that if there is some interoperability problem
lurking here, HTTP/1.1 DELETE and PUT share it.  How was this issue resolved
during discussion of the semantics of these methods?  How is it that the
current definitions in HTTP/1.1 don't lead to interoperability problems?
(Lack of widespread use?)

> Let us suppose that I have a webdav that does 'case folding' and treats
> http://host/AB to be equivalent to http://host/ab. These are two
_different_
> URLs, but they are the 'same' resource.
>
> Jim, are you saying that these represent two different resources, which
happen
> to map to the same 'persistent chunk of state'?

Yes.  So, if I perform a DELETE on http://host/AB, then according to the
HTTP/1.1 specification, the server won't return a 2xx unless it intends to
either delete the resource or make it unavailable.  At this point, it is
server policy whether the operation on resource http://host/AB has side
effects for other resources.  In this example, it seems to make sense for
the server to have a policy to remove http://host/ab when it removes
http://host/AB.  But, it might be just as meaningful to have a delete on
http://host/AB have no effect on http://host/ab.  Specifying server policy
(i.e., standardizing one of Jim Davis' four cases) doesn't make sense for
these multiple-mapping cases.

> Notes that in the 1-many interpretation, it should be made clearer
> that properties are associated with resources rather than with their
> URLs (e.g., that a PROPPATCH on one URL associated with a resource
> will affect the PROPFIND returned by the other URL).

Note that PROPPATCH borrowed its language from the HTTP/1.1 specification,
stating in section 7.2 that, "The PROPPATCH method processes instructions
specified in the request body to set and/or remove properties defined on the
resource identified by the Request-URI."  So, here at least it's clear that
the properties are being set on the resource, not on the URI.  But, it's
left just an ambiguous as DELETE and PUT whether there is a many-to-1, or
1-to-1 relationship between URI and resource.

> >Since it is impossible for a client to tell the difference between these
two
> >cases, it makes sense to me that there is a 1-to-1 correspondence between
> >URI and resource.
>
> There is no way for a client to tell whether a server does case folding.

This suggests it might be difficult to falsify the 1-to-1, URI to resource
interpretation.

- Jim
Received on Wednesday, 2 September 1998 20:51:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT