Re: [Interop] quick poll on the Translate field]

> One very common mechanism for doing Web-based access control
> is to base the access control on the URL (i.e. what you can do
> to a resource depends on what the URL is).

An access control based entirely on the URL ? hum. so it would give the same
access for a GET and DELETE command ?
Even these systems need to extract other info from the HTTP request, like
the method name in the first place. So checking a new HTTP field should not
be a big deal (it's not in our implementation).

> When you do a COPY, should it go against the raw form or
> the processed form of the resource?  Probably need the Translate
> header for that then too.  Similarly for any other method that
> could reasonably be applied to both the raw and the processed form.

Do a COPY, MOVE, DELETE on the processed version makes no sense, isnt'it ?
At least for all the existing Clients that I know of right now.

For PROPFIND and PROPPATCH, it's not as obvious, though using the raw file
is probably what we want in 99% of the cases.


> So all that is needed is for the server to be able to dummy up
> some URL that means "the raw form of this resource" to avoid all
> these issues. 

I am not a big fan of having several URLs for the same resource in different
status. Seems more like a workaround than anything else.

To be honest I didn't really want to start discussing the specs when I asked
to the interop list who was supporting the 'Translate' field. too late ;-)

In my perspective if all clients were sending the 'Translate: f' with all
their outgoing requests AND if the servers were always targetting the raw
resource (considering the user has the right priviledges of course) then we
would not have this discussion today.

and my main concern is that, whatever solution is chosen, it is widely
supported asap by most Clients and Servers (another point for the translate
field). Unfortunately it does not seem to be the case, and it could be a
hurdle for the big WebDAV breakthrough we all want to happen. Sincerely,

   Matthieu.

Received on Monday, 5 November 2001 17:42:47 UTC