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

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Sep 2005 10:19:40 +0200

Hi,

I just submitted a new revision of the WebDAV mount spec. From the abstract:

'This document specifies a mechanism and a document format that enables 
Web Distributed Authoring and Versioning (WebDAV) servers to send 
"mounting" information to a WebDAV client. The protocol is designed to 
work on any platform and with any combination of browser and WebDAV 
client, relying solely on the well-understood dispatch of documents 
through their MIME type.'

Since the first draft last month, this draft has been reviewed and 
implemented in two WebDAV clients (one of which is a reference 
implementation for the Microsoft Webfolder client, appearing as an 
appendix in the spec). It has also been implemented in the WebDAV stack 
of SAP Netweaver KM.

At this point I believe the spec is complete and I plan to submit it to 
the RFC Editor for publication as Informational RFC in three weeks. 
Feedback appreciated.

HTML version: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-latest.html>

Best regards, Julian

-------- Original Message --------
From: - Fri Sep 16 22:08:42 2005
helo=megatron.ietf.org)	by megatron.ietf.org with esmtp (Exim 4.32)	id 
1EGME5-00043F-7y; Fri, 16 Sep 2005 15:50:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)	by 
megatron.ietf.org with esmtp (Exim 4.32) id 1EGMDk-0003y6-Tr	for 
[email-masked]; Fri, 16 Sep 2005 15:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])	by ietf.org 
(8.9.1a/8.9.1a) with ESMTP id PAA08205	for <[email-masked]>; Fri, 
16 Sep 2005 15:50:01 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)	by 
ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGMIn-0007uY-3Z	for 
[email-masked]; Fri, 16 Sep 2005 15:55:17 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)	id 
1EGMDh-0002yE-T5	for [email-masked]; Fri, 16 Sep 2005 15:50:01 -0400
To: [email-masked]
From: [email-masked]
Date: Fri, 16 Sep 2005 15:50:01 -0400
Subject: I-D ACTION:draft-reschke-webdav-mount-01.txt
Reply-To: [email-masked]
<https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, 
<mailto:[email-masked]?subject=subscribe>
Sender: [email-masked]
Errors-To: [email-masked]
X-GMX-Antivirus: -1 (not scanned, may not use virus scanner)
X-GMX-Antispam: 0 (Mail was not recognized as spam)
X-GMX-UID: j0FZY1F8eSEkTvRadnQhaXN1IGRvbwDF

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Mounting WebDAV (Web Distributed Authoring and Versioning) servers
	Author(s)	: J. Reschke
	Filename	: draft-reschke-webdav-mount-01.txt
	Pages		: 14
	Date		: 2005-9-16
	
This document specifies a mechanism and a document format that
    enables Web Distributed Authoring and Versioning (WebDAV) servers to
    send "mounting" information to a WebDAV client.  The protocol is
    designed to work on any platform and with any combination of browser
    and WebDAV client, relying solely on the well-understood dispatch of
    documents through their MIME type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-webdav-mount-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-reschke-webdav-mount-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-reschke-webdav-mount-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Sep 2005 16:49:52 +0200

Hi,

I've got feedback from an implementor who pointed out two bugs, which I 
have fixed in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-latest.html>:

1) the example message wasn't using trailing slashes on collection names 
(which is recommended in RFC2518), and

2) the MS webfolder reference implementation wasn't handling absent 
<open> elements properly.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Sep 2005 10:02:10 -0700

This document looks grossly under specified. I don't even know what mounting
means. It seems to lack many of the things you would need to make it useful
for mounting and unmounting removable storage. I suspect I don't understand
what the document is about. I would be very against the IETF publishing a
document that someone in the WG could not understand what it did.

Cullen <not as chair>

On 9/17/05 1:19 AM, "Julian Reschke" <[email-masked]> wrote:

> X-Account-Key: account5
> X-UIDL: 7c8633b94a3df1ecdb877ce683ea0382
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 10000000
> Return-Path: <[email-masked]>
> X-Flags: 0000
> Delivered-To: GMX delivery to [email-masked]
> Received: (qmail invoked by alias); 16 Sep 2005 20:02:31 -0000
> Received: from megatron.ietf.org (EHLO megatron.ietf.org) [132.151.6.71]
>   by mx0.gmx.net (mx060) with SMTP; 16 Sep 2005 22:02:31 +0200
> Received: from localhost.localdomain ([127.0.0.1]
> Content-Type: Multipart/Mixed; Boundary="NextPart"
> Mime-Version: 1.0
> Message-Id: <[email-masked]>
> X-Spam-Score: 0.4 (/)
> X-Scan-Signature: 73734d43604d52d23b3eba644a169745
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: i-d-announce.ietf.org
> List-Unsubscribe:

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Sep 2005 19:14:46 +0200

> document that someone in the WG could not understand what it did.

Fair enough.

Several implementors had no trouble with it, but they knew beforehand 
what it was about. So it seems likely the introduction needs to be improved.

When the spec says "mounting", it means what the Intro says...:

"By definition, a WebDAV server ([RFC2518]) is an HTTP server as well 
([RFC2616]). Most WebDAV servers can be (at least partly) operated from 
an HTML-based user interface in a web browser. However, it is frequently 
desirable to be able to switch from an HTML-based view to a presentation 
provided by a native WebDAV client, directly supporting the authoring 
features defined in WebDAV and related specifications."

If it would go on saying that the in the context of this spec, 
"mounting" means exactly this ("switching to a presentation provided by 
a native WebDAV client"), would that make things clearer?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Sep 2005 19:30:40 +0200

> document that someone in the WG could not understand what it did.

Cullen,

when you say "it seems to lack many of the things you would need to make 
it useful for mounting and unmounting removable storage", could you 
please be a bit more specific?

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.

What may be looking like missing features was a deliberate decision to 
start with the simplest-possible format that solves the problem. That it 
*is* a problem IMHO shows that the market already has come up with a set 
of different approaches (see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-latest.html#alternative.approaches>), 
none of which is portable.

Additional information for specific clients (such as a proposed "mount 
point" for Unix FS clients) can then be added by extending the XML 
format (potentially using a different namespace). But right now I'd 
really like to stick with the subset that is relevant for every client.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 26 Sep 2005 10:38:12 -0700

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

* 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

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.

--------

Finally, Julian writes:

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

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Sep 2005 20:18:19 +0200

Jim Whitehead wrote:
> * 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 
> 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.

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

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

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

Best regards, Julian

---

From: Jim Luther <[email-masked]>
Date: Mon, 26 Sep 2005 11:26:12 -0700

Julian's document covers that in the Security Considerations section  
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount- 
latest.html#security.considerations>. Opening documents from a web  
page just by clicking on them is dangerous from a security standpoint  
-- displaying the contents of a collection is not dangerous.

- Jim

On Sep 26, 2005, at 10:38 AM, Jim Whitehead wrote:

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

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 26 Sep 2005 12:50:15 -0700

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

I dunno -- it doesn't seem reasonable that the default mapping of GET  
to an executable resource would be to execute a binary. For example,  
this isn't the case with Apache.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Sep 2005 22:01:45 +0200

Jim Whitehead wrote:
> I dunno -- it doesn't seem reasonable that the default mapping of GET to 
> an executable resource would be to execute a binary. For example, this 
> isn't the case with Apache. 

Well, there's no default mapping once the WebDAV resource is exposed 
through a file system API. Take the Xythos (Windows) client as an 
example: there's nothing it can do to prevent this; callers to the OS 
won't see anything except filename, a few flags and the binary content. 
What happens upon opening the document will completely depend on what 
the opening application (Explorer?) thinks it is.

I'm not saying that these concerns can't be adressed, but it will 
certainly be hard to specify properly.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Sep 2005 21:47:13 +0200

OK,

I have updated 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-latest.html>, 
shamelessly stealing text from JimW's suggestions.

The abstract now says:

Abstract

    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.

The introduction was expanded to say:

1.  Introduction

    By definition, a WebDAV server ([RFC2518]) is an HTTP server as well
    ([RFC2616]).  Most WebDAV servers can be (at least partly) operated
    from an HTML-based user interface in a web browser.  However, it is
    frequently desirable to be able to switch from an HTML-based view to
    a presentation provided by a native WebDAV client, directly
    supporting the authoring features defined in WebDAV and related
    specifications.

    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.

    For completeness, Appendix A lists other approaches that have been
    implemented in existing clients.

The description of dm:open now forward references the Security 
Considerations:

3.3  dm:open

    The optional <dm:open> element instructs the client to display the
    specified child collection; it's URL is computed by concatenating
    this element's value with the URL obtained from the <dm:url>
    (Section 3.2) element (see Section 7 for a discussion about why this
    element only supports displaying collections rather than opening
    arbitrary documents).

which in turn now say:

7.  Security Considerations

    All security considerations connected to HTTP/WebDAV and XML apply
    for this specification as well, namely [RFC2518] (Section 17) and
    [RFC3470] (Section 7).

    In addition, client implementers must be careful when implementing
    the <dm:open> element (see Section 3.3).  It MUST NOT be used to
    initiate any action beyond displaying the contents of a WebDAV
    collection (supporting "opening" documents could be abused to trick a
    user into letting the operating system's shell execute arbitrary
    content, possibly running it as an executable program).

Feedback appreciated,

Julian