RE: DAV-Enabled field (was RE: A case for GETSRC)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Monday, March 04, 2002 11:45 PM
> To: DAV
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> >GET doesn't dump "the content" of a resource. GET returns an
> entity which is
> >one of many possible representations of the resource, which may depend on
> >non-URL based information in the headers (in which case these
> headers should
> >be listed in the "Vary" header).
>
> You mean like a "DAV-Enabled" header field?  In which case
> "DAV-Enabled" would appear in the Vary field of the response?

CJ,

first of all: What is the *meaning* of "DAV-Enabled"? As you are proposing
this header, you should define what it means. Is an HTML editor that uses
PROPFIND/GET/PUT/LOCK to author HTML files "DAV-Enabled"? If yes, what do
you do if it has a test function that needs to access the output resource
rather than the source resource?

I think "Translate" is much clearer than "DAV-Enabled" because it at least
it says what you want.

And yes, if you *do* take the position that the source and it's output are
different representations of the same resource, then the "Translate" header
*does* make sense (and you should list in in the "Vary" header when
responsing).

As I've said numerous times: make up your mind whether the source and it's
output are the same resource or not. If they are, you can use "Translate".
If they aren't, they will have different URLs.

HTTP takes the position that they are different resources (see introduction
to "GET"), and I don't see how a different working group could change this
view.

> A "resource" is a rather malleable concept, and as you've stated here
> there may be many representations of that resource.  I don't see that
> it would be so horrible to allow the idea that one of the
> representations of a resource could be its raw source.  What

The most horrible thing being that the source resource doesn't have it's own
URL and thus cannot be properly referred to using just a URL. Could you
please explain why you think this particular problem *isn't* relevant?

> representation you receive is a matter of server policy.  And some
> way of identifying that the server is talking to a DAV client would
> help with managing that policy.

No, "DAV-Enabled" vs. "Translate" is the completely wrong approach.
Following your proposal, a "DAV enabled" client never would want to GET the
output resource. This is obviously a wrong assumption.

Received on Monday, 4 March 2002 18:15:38 UTC