RE: 'last call' comment on draft-ietf-webdav-protocol-07.txt-- resource:URL 1:1?

Independent of future work on advanced collections, which would include
the ability to set up equivalences and indirections and the like, what
I'm worried about is the basic operability of the core protocol and the
use of simple clients in the face of such (pre-existing) facilities.

It is false reasoning to assert "the base standard does not provide
any way of creating multiple-URL-per-resource, so therefore the base
standard need not be clear about what happens when authoring against
such a service", since the typical aliasing is _common_ in web servers.

To give the simple case:

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'?

What I'm worried about is that in the current protocol, the client has
to KNOW about the server's case folding rule (does "Ö" case fold to "ö"?)
in order to perform simple operations such as determining whether
deleting http://host/AÖ will delete http://aö/b. Under the paradigm that
'one URL, one resource', http://host/AB is a different resource than
http://host/ab, and has no official relationship with http://host/ab/c.


> ....I believe there is no way for an HTTP client to
> >tell the difference between the following cases:
> >
> >Assume: URL A and URL B both retrieve entity E on an HTTP GET:
> >A) Both A and B are identifiers for the same resource.
> >B) Both A and B are identifiers for different resources which happen to
> >return the same entity.
> >
> >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.

In practice, there are many other kinds of aliasing too, and one kind in
particular (aliasing long paths http://a/b/c/d/e to short ones
 http://a/collection-24).

Received on Tuesday, 1 September 1998 02:42:14 UTC