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: Friday, March 01, 2002 10:37 PM
> To: w3c-dist-auth@w3.org
> Subject: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> >The problem with having multiple ways of doing things
> >is that it harms interoperability, when one server does one thing
> >(maintain the DAV:src property) and another server does another
> >(a GETSRC method or a Translate header).  Servers are always going
> >to have proprietary extensions, and widely distributed servers
> >(e.g. IIS) are going to have clients coded against those proprietary
> >extensions, but the goal of the standard protocol is to produce an
> >interoperable protocol, which means not providing different alternative
> >ways to produce the same result.
>
> Ok, let's try a different tack.
>
> Let's keep the model that says source and display URIs are different,
> and keep/fix DAV:source, and leave all that the way it is.
>
> Let's just require that DAV clients add a special field to the
> request so that servers know they are talking to a client that is
> likely to send MKCOL, PROPFIND, and other DAV-specific methods.
>
> That way the URI model stays the same, and servers can tell when a
> GET request was generated by a DAV client.  Servers that only want to
> provide DAV access to source URIs may do so without creating new URI
> spaces.
>
> Call it DAV-Enabled.  The value must be present but is ignored.  (If
> someone got ambitious it could be used by the client to indicate its
> capabilities.  But one problem at a time, OK?)
>
> How's that for a solution?

It doesn't change the issue that you'd be using the same URI for different
resources. That's a very basic problem, and no amount of syntactic sugar
makes it go away.

Received on Friday, 1 March 2002 19:48:47 UTC