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?

cjh



--

Received on Friday, 1 March 2002 16:37:38 UTC