Yaron.Redirect.NoWebDAV#1

The redirect spec requires the use of WebDAV in order to create and query
redirect resources as it makes use of the WebDAV property mechanism. However
I am having trouble finding a compelling reason to require WebDAV just to
implement redirect resources. A redirect resource is, in my opinion, just an
enhancement to HTTP/1.1.
HTTP/1.1 introduced the concept of a 302 response but did not concurrently
introduce the administrative tools necessary in order to specify when a 302
response should be returned.
The redirect draft helps to address this deficiency but unless there is a
compelling reason to do so, it should address this deficiency in the
simplest manner possible, preferably only using the tools provided by
HTTP/1.1.

The argument has been made that the tools introduced in the redirect draft
constitute the first step in a series of additional extensions that will be
made in the future. For example, the Delta-V group has certain ideas about
how to use MKRESOURCE. While HTTP has a rich tradition of enabling future
extensions it has always wisely chosen in the short term to limit itself to
immediate needs only while ensuring that future expansion is possible.

Hence the test for the redirect draft's success should be only how well it
addresses the immediate needs of redirect resources and not how well it
addresses the shifting needs of various future proposals.

The current functionality of the redirect resource is very simple, specify a
resource that, by default, will return a 302 (found) response to a specified
target resource.

There does not appear to be any compelling reason why the creation of a
redirect resource should require anything beyond a single header on the
creation request to specify the URI of the target resource. The use of a
body to create a redirect resource is clearly unnecessary. This is not to
say that it may not prove to be necessary in the future. However WebDAV, in
particular, has set a precedent for how to deal with this sort of situation
that I believe would well serve the redirect spec.

In the COPY/MOVE methods we use a single destination header, rather than a
body, to specify where the results of the method are to appear. One can
imagine a number of reasons why one would want to have a more powerful way
to specify the destination of the method. For example, one might want to
specify multiple destination URIs in order to use a single round trip to
cause multiple COPY/MOVE's. HTTP's header format is not well suited for this
sort of extension and WebDAV's definition of the destination header wisely
does not allow for it. Rather WebDAV specifies that a body MAY be included
in a COPY/MOVE method but is to be ignored if not understood. This provide
for a very powerful extension mechanism. For example, imagine one wanted to
issue the COPY/MOVE to multiple destinations but one wasn't sure if the
source supported this feature. Rather than wasting a round trip finding out
if the source supports the feature one could put a single destination in the
destination header and then use the body to specify the rest of the
destinations. If the resource supports the extension then all destinations
will be COPY/MOVE'd to. If the resource doesn't support the extension then
at least one copy will be issued and the client will realize that the rest
didn't occur (because the resource ignored the body) through the 207
response. If, on the other hand, one only wanted the COPY/MOVE to proceed if
the resource understood the multiple destination extension then the
COPY/MOVE could be issued without a destination header, just with a body.
Resources that didn't support the extension would fail the request due to
the absence of the destination header thus ensuring that only resources that
understood the extension will actually execute the method.

One could rightfully argue that this is an unnecessary complication. Why not
start with a body that allows extension in the first place? The counter
argument is that one should always start with as minimal functionality as
possibly and only expand, grudgingly, as required. A header is much easier
to process than a body and so clearly is the simplest mechanism available.
This line of reasoning is especially compelling in the context of redirect
resources. Given the obvious utility of redirect resources to all HTTP
systems, not just WebDAV, it is incumbent upon the redirect spec to cleave
as closely as possible to the base HTTP system and require as few extensions
from it as possible.

Therefore I believe that the current proposal, which requires the
introduction of a full XML processing system just to handle a simple
redirect resource is unsupportable. As such I move that whatever design is
chosen for creating a redirect resource it MUST NOT include the use of a
request body.