2.6 WebDAV for Sharing Documents

So far, I've discussed how WebDAV can be useful for Web authoring tools. That's not the only way WebDAV is used, however. In addition to editing Web pages, WebDAV can be used to author any kind of electronic document, even one not ultimately intended for Web publishing. This usage is called Web-based file sharing or Internet file sharing. File sharing requires more restrictive permissions than the typical public Web page, because files are often shared among only a small set of people. Privacy becomes important.

To understand how good WebDAV is at wide-area file sharing, we need to compare it to the alternatives. Only two sets of protocols are commonly used for file sharing: the protocols used by networked file systems and the protocols used by email.

2.6.1 Networked File Systems

Networked file systems are very common today. They work very well within a corporate network. However, when wide-area file sharing is needed, companies increasingly look to WebDAV. This section explains why this is the case.

Networked file systems have existed for over 20 years. The most common today are Server Message Block (SMB), NFS, and Andrew File System (AFS, a successor to NFS). Although all of them can potentially be used over the Internet, each has drawbacks for Internet file sharing.

NFS

NFS is the Unix standard for networked file systems. It is a mature and open IETF standard [RFC3010]. The major stumbling block to wider adoption of NFS is lack of support by Microsoft client and application software. However, one could argue that there are good reasons that Microsoft does not support NFS the protocol relies on clients to enforce access control settings. Thus, it's impossible to make some files on a shared file system accessible to anonymous users without opening up all files to possible attackers.

SMB and Samba

SMB is the standard networked file system protocol for Microsoft file systems. The earliest publication describing SMB came from IBM in 1985. SMB is broadly deployed and even offers some cross-platform interoperability: Samba is a popular SMB server for Unix, and there are various Unix SMB clients as well.

SMB has more flexible security than NFS does. However, like NFS, SMB was designed before the Internet and was intended to run over intranet protocols (NetBEUI or NetBIOS) rather than TCP [Vidstrom03]. With SMB, the client software uses Remote Procedure Calls (RPC) to ask the file system to open remote files and edit them, just as if the client software were making local procedure calls to the local file system.

The Andrew File System

AFS is the successor to NFS. Security is vastly improved over NFS, offering powerful file-level permissions enforceable by the server. However, AFS was not designed for high-latency situations. The system is instead designed to have servers close to the end user and to replicate data to those servers. On the Internet, where file sharing is ad hoc rather than controlled, AFS can be difficult to deploy, because servers must be configured to trust each other.

Roundtrips in Networked File Systems

The networked file systems described here were all designed for low-latency or local networks. Further, they were consciously modeled after local file system access. This design history partly explains the "chattiness" of the protocols, or the number of requests and responses required to complete a simple operation. For example, in SMB:

1. negprot command to negotiate protocol version

2. sessetupX command to log in and start session

3. tcon command to select ("connect" to) a share or tree

4. open a file

5. read a file

Thus, what would be a single GET roundtrip in HTTP is as long as five roundtrips in SMB for a new share. When the network latency involves noticeable fractions of seconds, as it does over many wide-area networks or the Internet, there is a noticeable delay in SMB operation.

2.6.2 Collaborative Authoring via Email

When multiple authors collaborate on a document, they need to exchange copies of the document. If these authors don't have access to the same networked file system, email becomes the medium of choice.

Email is probably the most pervasive networked system in existence. Almost every end-user computer in every network has access to a mail server that can forward email to and from the Internet. Users don't even have to be online constantly to use email computers can connect to a network just long enough to download new mail and upload sent mail. Email clients all support MIME, handling any document type. For this reason, email has become a popular system for exchanging documents.

Email is so useful for exchanging documents that it will continue to be used no matter how good and widely deployed Web-based file sharing becomes. There is no expectation that WebDAV will replace email in any serious way. However, WebDAV can be used together with email to make file sharing more effective.

2.6.3 Email Attachment Semantics

Email applications typically send attachments by attaching the entire document. It is possible to send a link to a file rather than the entire file, but replacing attachments with links isn't trivial. First, there's no guarantee that users can put the file in a location where it will be readable by other users. Then, after that hurdle has been overcome (perhaps with a networked file system), there's the problem of accurately locating the file and of ensuring that all the recipients have the necessary software and permissions to access the shared file.

WebDAV is beginning to improve this situation. Users who have access to a WebDAV repository can upload files to a permanent shared location and then send the HTTP URL manually to a number of email recipients. There has been some work to extend email software to handle this process even more easily by automatically uploading the file and inserting links into email. One example using this technique is Xythos WebFile Client, which has extensions for some common email clients.

Why does it matter whether users send attachments by reference or by sending the entire file? There are a number of differences in behavior. One option isn't always the right one, so it seems reasonable to give users the choice. Some of the following considerations will affect users' choices:

Copy Proliferation

With email, a copy of the entire document is sent in every email to every recipient. Sometimes recipients save the document locally and keep a copy on their email server. If the document is mailed back with edits or later versions are mailed around again for comments, the number of copies becomes very large. Clearly, the first problem with this method is disk space, but there's a subtler problem with manageability of all these copies. For example, the author responsible for integrating changes can get confused by receiving and saving various copies with edits and comments from different people. It's hard to keep track of which is the official copy and which are copies generated from attachments returned by reviewers or co-authors. This is a clear win for sending links rather than attachments.

Visibility of Changes

When documents are sent via email, the entire document is usually included as an attachment. This is called sending by value, and it means that once the email is sent, the attachment cannot be changed. If the author decides to make a change, the document must be sent out again. Otherwise, users might review a version that isn't the latest version. In contrast, sending by reference means that all users will see the latest version of the file on the repository automatically. Sometimes that's a good thing, sometimes it's not.

Retrieval on Demand

Users want to be able to download according to their own choice. Email doesn't offer that option users must wait for the file to be emailed to them even if they don't want it, or they must ask for the file to be mailed because it hasn't been. However, sending the entire file via email guarantees that the end user will receive the file (there's no second download step that requires network connectivity and no chance of a permissions error).