Re: remaining redirect ref issues

In principle, I agree with Roy on this issue.

But a problem with the "authoring URI" approach occurs when you want to
apply a Depth operation (e.g. PROPFIND).  You can get all the authoring
URIs with a single Depth PROPFIND, but then how do you avoid having to
apply the operation separately to each of the authoring URIs?

In the case of PROPFIND, there is a solution provided by RFC-3253
(the DAV:expand-property REPORT), but that only works for PROPFIND,
not for other Depth methods like COPY.

Cheers,
Geoff 

Roy wrote on 11/12/2003 01:08:34 PM:

> I am certain I have said this before, though it was several years ago.
> The RESOURCE IS NOT A STORAGE ITEM ON THE SERVER!  Failure to get 
> straight
> on that one bit is what causes webdav to trip over HTTP whenever it
> tries to "author" anything other than a boring old file.
> 
> In this case, there must be two different URIs -- one for the resource
> and one for the configuration of that resource.  That configuration
> may be as simple as a URI, maybe a status code and a URI, or maybe even
> an XML document -- that is what must be defined by the redirect 
> protocol.
> The actual URI which responds to requests with a redirect should have a
> link to its configuration URI, such that an authoring tool can discover
> the authorable resource that causes this resource to redirect.  That is
> why webdav requires a source link in order to perform HTTP authoring.
> 
> The same principle holds for all dynamic content.
> 
> ....Roy
>