RE: Yaron.Redirect.NoWebDAV#1

The idea of trying to specify redirect references in such a way that they do
not depend on implementation of any other parts of WebDAV is very appealing.
As you point out in this and the following 2 comments, we would need to go
back to using MKREF (which doesn't have an XML body) instead of the more
generic MKRESOURCE and get rid of the DAV:reftarget property in order to
make this possible.
 
I would be willing to do both.
 
I just want to be sure that, even though it's not required for a redirect
reference to support any other parts of WebDAV, it's permissible for it to
do so.  If it's also a WebDAV class 1 resource, I would assume its
DAV:resourcetype property would have a value DAV:redirectref.  It would be
possible to set properties on the redirect reference and view properties on
the redirect reference using the Apply-To-Redirect-Ref header.
 
Also it is possible to create a redirect reference in a WebDAV-compliant
collection, as discussed in Section 7 of the spec.
 
What would we lose by getting rid of DAV:reftarget?
 
1. Efficiency in certain scenarios, where you are operating on a collection
populated with redirect references.  You would have to do 2 round trips for
each member of the collection instead of getting DAV:reftarget with PROPFIND
for all members and addressing requests to the target.
 
2. Can't search on DAV:reftarget to find all references to a given resource.
 
3. No relative URIs (the Location header always has absolute URI), so in an
environment where references are within a hierarchy that is likely to move,
redirects may get broken where they would survive in the current spec.
 
In my view these considerations are outweighed by the possibility of
creating and managing redirect references without implementing any other
parts of WebDAV.  So I'm with you here.  Thanks for the great suggestion!
 
--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Friday, February 11, 2000 2:44 AM
To: 'w3c-dist-auth@w3.org'
Subject: 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.

Received on Wednesday, 16 February 2000 12:14:39 UTC