W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2005

Re: last calling WebDAV mounting spec, was I-D ACTION:draft-reschke-webdav-mount-01.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 26 Sep 2005 20:18:19 +0200
Message-ID: <43383B6B.1020603@gmx.de>
To: Jim Whitehead <ejw@soe.ucsc.edu>
CC: WebDav <w3c-dist-auth@w3.org>

Jim Whitehead wrote:
> I somewhat agree with Cullen here, in that the meaning of "mount" is 
> somewhat ambiguous.
> Some thoughts on how to improve the introduction:
> * Add a discussion of the problem this specification is aiming to solve. 
> Something like:
> "In current Web browsers, there is no uniform way to specify that a user 
> clicking on a link will be presented with an editable view of a WebDAV 
> server. For example, it is frequently desirable to be able to click on a 
> link, and have this link open a window that can handle drag and drop 
> interaction with the resources of a WebDAV server."

Noted. I'll try to incorporate that.

> * It might also be useful to give one or more concrete scenarios of use 
> of this protocol. Something like, "For example, many educational 
> institutions use WebDAV servers as a mechanism for sharing documents 
> among students. Each student owns a separate collection structure on a 
> WebDAV server, often called their "locker". Ideally, when a user clicks 
> on a link in an HTML page provided by the university (perhaps by their 
> university Web portal), an editable view of their locker will appear."
> --------
> In its current form, the document seems to focus too much on something 
> like Web Folders as the intended client. However, it could be very 
> powerful to have an "edit this page" button that either:
> - launches a WebDAV-enabled HTML editor (such as GoLive, Dreamweaver, or 
> Contribute) on the exact page to be edited
> - mounts the WebDAV location (e.g., using the mounting mechanism on the 
> Mac, the drive mapping on the PC, etc.) and then fire up a text editor 
> or HTML editor on a specific file

Funny enough, supporting the Webfolder client actually was an 
afterthought, and both other current client implementations fall into 
the filesystem category.

And, as a matter of fact, both implementors asked for the ability to 
also <open> files, so that they can be directly edited.

The problem here is a security risk, mentioned in 
if a client just maps the WebDAV server to a filesystem, and translates 
<open> requests into whatever the system's shell does on double-click, 
this introduces a huge security hole: a malevolent could simply send a 
<open> request for an executable file, and the client would then 
potentially open (= execute) it without any additional confirmation by 
the user.

I'm not saying that this issue can't be dealt with, but at this stage I 
preferred to err on the side of security. If people feel the spec should 
allow <open> on non-collection, please try to come up with a spec text 
that can address this concern.

> Supporting these scenarios would require a bit more mechanism in the 
> protocol than is currently present. For example, dm:open is specified as 
> a collection -- there is no way to specify the exact resource URL to be 
> opened for editing.

Yep, on purpose.

> --------
> Finally, Julian writes:
>> WebDAV clients come in many flavors, such as
>> - filesystem drives (Xythos, Microsoft XP-Redirector, Unix/Linux fs 
>> drives such as the one in MacOSX)
>> - shell extensions (like Microsoft's Webfolder client)
>> - browser extensions (I think KDE#s webdav "URI" support falls into 
>> this category)
>> The aim of this document was to have a platform- and client-agnostic 
>> way for a server to let the client's system know that a specific 
>> WebDAV URL should be accessed, and that collection itself (or a 
>> descendant of it) should be displayed.
> It would be nice if the document itself said this.

I thought the combination of Abstract and Introduction already do that, 
but I'll try to improve them.

Best regards, Julian
Received on Monday, 26 September 2005 18:23:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC