Yaron.Redirect.NoWebDAV#3

The third related design issue facing the group is how to retrieve the
target of a redirect resource. The current proposal specifies the use of
WebDAV property. As argued in Yaron.Redirect.NoWebDAV#1 this is an
unnecessary complication. It is much simpler to allow people to issue a
method, such as HEAD, to the resource and allow the resource to respond to
that method with a 302. This provides a fully efficient but very simple
mechanism for discovering a redirect resource's target. Alternatively, one
could issue the method used to create the redirect resource in the first
place without a target header and allow the redirect resource to respond
with its target resource's URI. There are any number of mechanisms available
and none require the use and complexity of a WebDAV property. Therefore I
move that there MUST NOT be a requirement in the redirect draft for the
support of a WebDAV property in order to discover the target location.

It is possible, of course, to argue that one should have a WebDAV property
to discover the target resource, even if it is not mandatory. The utility of
such a property includes the ability to use PROPFIND to collect various bits
of data about a resource in a single request as well as the ability to
search on the data. However, under closer scrutiny, neither of these
arguments holds up. 

The use of pipelining means that one can use several separate status request
messages to a resource without incurring any latency costs. Furthermore,
while there is relatively little benefit to overloading properties, there is
a very definite cost. As discussed in the WebDAV book of why and for
reasoning that is essentially identical to that given in
Yaron.Redirect.NoWebDAV#2, the requirement to provide resource state
information through properties presents a clear threat to the extensibility
of the WebDAV protocol suite. It centralizes control over new functionality
into a single point and so inhibits the ability to experiment and extend
HTTP resources.

The search confusion has been around for a while, which is surprising given
that even the DASL group has long disowned the issue. The essence of the
problem is the mistaken belief the DASL is only able to query WebDAV
properties. In fact, DASL is able to query any value associated with a
resource that has a unique name, i.e. a URI name. There is no requirement
that this value be settable or retrievable through the WebDAV property
mechanism.

Therefore I move that the bind spec MUST NOT specify much less require the
use of WebDAV properties for any purpose related to the creation/state
query/maintenance of redirect resources.