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

>> At the working group meeting, there seemed to be some disagreement
>> about this point; Jim seemed to think (emphatically) that it was
>> required that the mapping between 'resource' and 'URL' was 1-1,
>> but others seemed to assert that it might be 1-many.
>
>I don't believe the rest of this discussion can be addressed until this
>point is cleared up.  The reason I hold that the mapping between resource
>and URL is 1-to-1 is that 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.  However, I can certainly see that an underlying
>repository might map the same "chunk of persistent state" to one or more
>URI/resource pairs.  So, while I hold that there is a 1-to-1 correspondence
>between URI and resource, I also accept that there can be a many-to-one
>correspondence between URI/resource pairs and "chunks of persistent state".

I wasn't sure I understood both sides of this, so I tried to read the
webdav and the HTTP/1.1 spec to see if they used the same sense for the
word "resource".

I'm still not sure if the two specs are in alignment. But both specs do
talk about methods that modify data on the server, and discuss
considerations involved, and this is where the details seem to matter.

A pair of URL/URIs that return the same entity byte-for-byte on an
otherwise identical GET request, may or may not stay in sync when one does
a PUT or a DELETE.

It seems like you couldn't predict the outcome in advance with an HTTP/1.1
client.

One of the things I have in the back of my mind is the idea of resources as
"files", but of course, the HTTP spec is meant to apply to servers that may
not be based on a file system. Your "chunks of persistent state" may be the
closest analog we have in the general case to "files". And the webdav spec
talks at one point about "source resources" and "output resources" (in
section 4.4)

I got the impression Larry was talking about the sort of thing I'd think of
as resources aliased to different "directories" in the URI space. But I've
been also thinking about stuff like the varients of a resource associated
with the various Accept-* headers, or the example from the HTTP spec of a
URI that referes to the "current article" among a list on news articles.

When Accept-* headers are involved on a GET, a single URI seems to refer to
an equivalance class of related varient resources, rather than a single
entity body.

If I'm talking about a server that is serving up English and Japanese
varients of the same text, it seems likely (though not inevitable) that the
two varients really come from distinct files, and deleting one will not
affect the other.

If I'm talking about a server that offers varients in Unicode, EUC, JIS,
and Shift-JIS encodings, it's quite possible (though not inevitable), that
these varients are being generated on the fly from a single, and deleting
that one will delete them all.

It looks to me like the webdav advanced collections document is intended to
provide an enumeration of all the possible items that are allowed to exist
on a webdav server, so that a client could, in principle, discover if two
URIs, that return the same body would both be removed by a single delete.

(I'm not sure if that's an explicitly stated or desired goal.)

But if we accept that it _is_ a goal, then it might imply that a webdav
server couldn't create aliases or dependencies between the resources
returned by distinct URIs that could not be discovered in the webdav
framework.

(By tracing "references" and/or "DAV:source" properties)

Maybe general "dependencies" are a topic for versioning, but aliases
between URIs that return byte-for-byte identical entities for requests with
the same headers seems central to webdav advanced collections, and the
definition of direct references.

This reminds me: I think someone suggested at the meeting that an alias, in
the sense of the Apache web server, behaved like a "weak direct reference"
in the sense of the webdav definitions.


---
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Tuesday, 1 September 1998 01:18:27 UTC