- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 Sep 2005 20:18:19 +0200
- 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 <http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-latest.html#security.considerations>: 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