W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

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

From: CJ Holmes <cholmes@4d.com>
Date: Fri, 1 Mar 2002 13:37:26 -0800
Message-Id: <a05101406b8a5a26e86eb@[10.196.0.11]>
To: w3c-dist-auth@w3.org
>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?

cjh



-- 
Received on Friday, 1 March 2002 16:37:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT