Subject: RE: [[email-masked]: Re: [Interop] quick poll on the Translate field]

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 5 Nov 2001 16:25:48 -0500

My standard response to everyone who suggests that it is
too complicated for a client to make sense of multiple source
fields is: adopt the convention that the first link is the
most important one, and just show that one.

Some of the points made in the WebDAV thread against using
headers to control what GET does:

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).  Using any header
(such as the Translate header) breaks any scheme like this.

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.

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.  That does not seem like an unreasonable burden on
the server implementor.  Similarly, I don't think it is an unreasonable
burden on a client writer to do one extra roundtrip to retrieve a
tree of source images (i.e. one Depth:infinity PROPFIND to retrieve
all the links for a tree).

Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:[email-masked]]
Sent: Monday, November 05, 2001 2:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [[email-masked]: Re: [Interop] quick poll on
the Translate field]

Mathias sent this directly to me. I believe it was intended to go back to
the list. I've CC'd the main DAV list since this is turning from a quick
poll about interop into a discussion of approaches.

Cheers,
-g

----- Forwarded message from [email-masked] -----

From: [email-masked]
Subject: Re: [Interop] quick poll on the Translate field
To: [email-masked]
Date: Mon, 5 Nov 2001 12:12:15 +0100 (CET)

SimpleCMS does support it, as well as the source/link way of doing it.

On  3 Nov, Greg Stein wrote:
> On Fri, Nov 02, 2001 at 05:33:17PM -0800, Matthieu Chevrier wrote:
>>...
>> --> which WebDAV Servers and Clients support (or will very soon) the
>> 'Translate' field ? (besides IE on PC)
> 
> mod_dav does not implement it, and it never will.
> 
> 
> IMO, it is the wrong approach to solving the problem. The source/link
> stuff and multiple resources is the right way. You didn't ask for a

No, it isn't. translate and source/link solve different problems. WebDAV
emulates a file system layer. So my clients expect _one_ source file.
Everthing else is nice-to-have, and may be very powerfull for some uses,
but is obviously wrong for a simple: give me _this_ resource,
untranslated.

As for SimpleCMS, we could well use the both approaches for different
reasons (we do not right now).

Situation: every page is transformed on-the-fly, using a menu-module,
and possible background, logo etc. resources. 

So, where should the source link(s) point to? The complete solution: 
- a raw version of the url in question
and probably
- a menu vonfig page, where the current menu style is choosen (or the
  menu program module??)
- the background gif
- the logo, if used
- any sub-dir logos, if used
- possible many more resources.
- if it's a database generated pag: possible pointers to the raw table
  data, too.

Very powerfull, potentially very usefull, but tell me: how should a
network redirector like WebIFS show this mess to the user??

Instead, the translate header would just say: give me _this_ url,
untranslated. No questions what this means. One resource. No choice (no
power, too :). Easy to realize, consistent with the file system model,
and easy to explain to the user.

So: source link are nice and powerfull and may be used for advanced
purposes, but are simply not the same as translate. 

Use both.

Just my two cents

Cheers, Mathias

> "why?" (which is good: that belongs on w3c-dist-auth), but I figured
> people would want to at least hear a bit more reason why mod_dav is
> taking a stance against it.
> 
> Cheers,
> -g
> 

-- 
                            virtual earth
 Mathias Picker
 Geschäftsführer      Gesellschaft für Wissens re/prä sentation mbH

                            [email-masked] 
			    Fon +49 89  / 540 7425-1
                            Fax +49 89  / 540 7425-9

----- End forwarded message -----

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 5 Nov 2001 22:45:03 +0100

Our server currently supports the Translate header (because it's supported
by Microsoft). However, experience shows that the way it's defined (or not
defined, lacking any official documentation) I really problematic.

For instance, PROPFIND currently will behave differently depending on the
Translate header -- in the default case, the server will (try to) report the
properties of the dynamic content (and in many case will fail to do so, for
instance for the content length). This basically means that we're forcing
clients to supply a proprietary and under-specified header to get at the
'real'  (static) information.

It seems that having different URLs for different things is the way to go,
however, the DAV:source property should

a) have better documentation,

b) be easier to act upon by a user client (see proposal in [1])

Julian

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html>

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Monday, November 05, 2001 10:26 PM
> To: [email-masked]
> Subject: RE: [[email-masked]: Re: [Interop] quick poll
> on the Translate field]
>
>
> _______________________________________________
> Interop mailing list
> [email-masked]
> http://mailman.webdav.org/mailman/listinfo/interop
>
>

---

From: Matthieu Chevrier <[email-masked]>
Date: Thu, 15 Nov 2001 14:42:58 -0800

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

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

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 5 Nov 2001 23:50:16 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Matthieu Chevrier
> Sent: Thursday, November 15, 2001 11:43 PM
> To: [email-masked]
> Subject: Re: [Interop] quick poll on the Translate field]
>
>
>

I think you missed the WebDAV ACL spec :-)

> is probably what we want in 99% of the cases.

Really. So PROPFIND/getcontentlength will say "application/ecma-script", but
GET returns HTML content?

> would not have this discussion today.

So what should IE do upon GET?