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

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

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 1 Sep 1998 13:37:14 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D087924CF@RED-MSG-59>
To: "'Larry Masinter'" <masinter@parc.xerox.com>, Albert Lunde <Albert-Lunde@nwu.edu>, w3c-dist-auth@w3.org
DELETE, as specified by HTTP/1.1 deletes a resource.
Therefore if http://a/b and http://c are the same resource then deleting one
MUST delete the other. If it does not, then they are not the same resource.
DAV does not provide a mechanism to discover this connection.
Given that we can create useful clients without it (witness the file
explorer in Windows) and that it can be added later, there is no need to
modify the DAV standard to provide this functionality.


> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Monday, August 31, 1998 11:42 PM
> To: Albert Lunde; w3c-dist-auth@w3.org
> Subject: 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 16:36:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC