RE: Yaron.Redirect.NoWebDAV#1

See below

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wed, February 16, 2000 9:12 AM
> To: Yaron Goland; w3c-dist-auth@w3.org
> Subject: 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.
>  

Agreed.

> 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.
>  

Maybe I'm missing something but wouldn't the results for a PROPFIND on all
the redirect resources be a 300 and wouldn't that 300 contain the redirect
target? Isn't that the same information that would have been contained in
the DAV:reftarget element? Doesn't that therefore mean that there is no loss
of efficiency?

> 2. Can't search on DAV:reftarget to find all references to a 
> given resource.
>  

Actually, there is no reason why you can't define a DAV:reftarget token for
use with DASL. As I discuss in one of my points DASL can search on anything
with a name, what is being searched does NOT have to be something
retrievable through a PROPFIND.

> 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.
>  

I admit to not understanding this one. How does the use of relative or
absolute URIs in the protocol effect how information is stored at either the
client or the server? Perhaps an example would help.

> 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!
>  

Always a pleasure.

> --Judy
> 

			Yaron

> -----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 Thursday, 24 February 2000 00:48:59 UTC