- From: Greg Stein <gstein@lyra.org>
- Date: Fri, 25 Feb 2000 18:43:38 -0800 (PST)
- To: w3c-dist-auth@w3.org
- cc: "'Slein, Judith A'" <JSlein@crt.xerox.com>, "'yaron@goland.org'" <yaron@goland.org>
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