RE: Yaron.Redirect.NoWebDAV#1

I'm not sure what the total outcome of the "NoWebDAV" posts are, but here
is my opinion on the matter...

* I agree with Yaron in that we should not require WebDAV to implement the
  redirects.

* if the redirect resources *are* WebDAV aware, then I want to see the
  information in a property. Therefore, the reftarget can be queried/set
  using PROPFIND and PROPPATCH (with the Apply-To-Redirect-Ref header
  present)

* I would expect that DAV:resourcetype is set appropriately (during a
  PROPFIND)

This implies that the Redirect spec should be written in terms of NOT
requiring anything more than HTTP/1.1 (i.e. does not require WebDAV).
BUT: it should also have a section specifying the behavior if the
resources are WebDAV aware.

Cheers,
-g

On Wed, 23 Feb 2000, Yaron Goland wrote:
> 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.
> > 
> 

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 25 February 2000 21:41:22 UTC