DAV Frequently Asked Questions

Oh, I think it depends on who you talk to. Officially, it is WebDAV, but I prefer the shorter "DAV" form. This may also be an artifact from when I worked at Microsoft, where the DAV term is used almost exclusively, rather than WebDAV.

The stated goal of the WebDAV working group is (from the charter) to "define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs", and in this respect DAV is completing the original vision of the Web as a writeable, collaborative medium.

But, people working on DAV have had goals which extend beyond simple web page authoring. Some view DAV as a network filesystem suitable for the Internet, one that works on entire files at a time, with good performance in high-latency environments. Others view DAV as a protocol for manipulating the contents of a document management system via the Web. An important goal of DAV is to support virtual enterprises, being the primary protocol supporting a wide range of collaborative applications. Importantly, a major goal is the support of remote software development teams. A final goal of DAV is to leverage the success of HTTP in being a standard access layer for a wide range of storage repositories -- HTTP gave them read access, while DAV gives them write access.

All of these goals are complementary, and are satisfied by the same network protocol.

WebDAV provides a network protocol for creating interoperable, collaborative applications. Major features of the protocol include:

• Locking (concurrency control): long-duration exclusive and shared write locks prevent the overwrite problem, where two or more collaborators write to the same resource without first merging changes. To achieve robust Internet-scale collaboration, where network connections may be disconnected arbitrarily, and for scalability, since each open connection consumes server resources, the duration of DAV locks is independent of any individual network connection.
• Properties: XML properties provide storage for arbitrary metadata, such as a list of authors on Web resources. These properties can be efficiently set, deleted, and retrieved using the DAV protocol. DASL, the DAV Searching and Locating protocol, provides searches based on property values to locate Web resources.
• Namespace manipulation: Since resources may need to be copied or moved as a Web site evolves, DAV supports copy and move operations. Collections, similar to file system directories, may be created and listed.

For more information on features, check out the article WebDAV: IETF Standard for Collaborative Authoring on the Web which appeared in IEEE Internet Computing, September/October, 1998.

HTTP Extensions for Distributed Authoring -- WEBDAV (text) has been released by the IETF as RFC 2518. This is the base DAV protocol, and includes features for:

• Locking
• Properties
• Namespace management

Bottom line: these features are complete, and are expected to be stable.

Several extensions to the base DAV protocol are currently under development in the IETF:

• Advanced Collections: this adds support for ordered collections, where the server maintains a single persistent ordering of the URLs in a collection. It also supports referential resources, resources which act like symbolic links in file systems, allowing a client to remotely create a redirect to another resource. This work is expected to be completed in mid-2000.
• Versioning and Configuration Mangement: versioning support, similar to that provided by RCS or SCCS, is the entry level of functionality. The versioning level will support opreations such as check-out, check-in, and retrieval of the history list. The ability to directly retrieve a previous version of a resource (allowing links directly to previous revisions) will also be supported. Built on top of the versioning layer is the configuration management layer, which provides support for workspaces and configurations, allowing versioned collections of versioned resources to be worked on. Both layers support parallel development. This work is taking place in the IETF DELTA-V working group, and is expected to be complete in late 2000.
• Access Control: the ability to set and clear access control lists. This functionality is crucial for allowing collaborators to remotely add and remove people from the list of collaborators on a single resource. At its most general this activity becomes access control not just for DAV, but for the entire Web.

DAV is a protocol. More specifically, it is an extension of the HTTP/1.1 protocol. DAV adds new HTTP methods and headers. In addition, DAV specifies how to use the new extensions, how to format request and response bodies, how existing HTTP behavior may change, etc.

Generally speaking, an API is related to how a programmer invokes functionality. Protocols specify what occurs "on the wire" between a client and a server. Basically, they specify data formats and algorithms so that the client and server can interoperate.

In terms of adoption, a protocol is better than an API, since an API carries with it embedded control and architecture assumptions which are not always appropriate for every use case. By having a well defined protocol, many different APIs in many different languages can be written which expose the functionality in the protocol. This has been the case with HTTP, where there are currently scores of HTTP APIs. Furthermore, if the protocol has well-defined syntax and semantics, developing an API is not usually an onerous task. Several APIs for WebDAV have been developed, and there were no "gotchas" in their development.

The most current drafts can always be found on the DeltaV Working Group pages. At the time of this writing, the relevent drafts are listed below.

The goals for the versioning and configuration management protocol can be read at this URL:

http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt

A UML-style model of the versioning and configuration management abstractions can be read at:

http://www.webdav.org/deltav/model/model990209/

The latest protocol draft can be found at:

http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-10.htm

There is also a scenarios document:

http://www.webdav.org/deltav/scenarios/scenarios-00-1.htm

Web sites typically gather together information from diverse sources, often from people who are geographically separated. Using a DAV server, the HTML pages, images, and other information that comprise a Web site can be directly authored by the primary sources of the information. Even sites which use a staging process, DAV provides significant benefit for the first stage, where information is first entered into the approval process. DAV can also be used by the tools which transfer pages from server to server along the approval workflow.

One of the key challenges in supporting a geographically disperse software development teams is making the software remotely accessible via the Internet. DAV provides a standard infrastructure for doing just that. Since the artifacts of software development, like requirements and design documents, as well as source code, are amenable to remote collaborative authoring, DAV can be used to support virtual development teams. While DAV has significant utility today to support remote software development, when the versioning protocol has been completed, DAV will have full versioning and configuration management support as well, an important collaboration technology for software development.

Definitely. Once DAV makes documents editable in-place on the Web, the separation between data on isolated local disk drive, and data on a local intranet will fade away since the Web-accessible data will be more valuable. This will provide incentive for work practices to coalesce around the local intranet. As more and more documents are edited using DAV, the accidental costs of collaboration are reduced dramatically. If you begin work on a single-author document which you edit using DAV, adding another collaborator is easy, requring just a change in permissions to allow access to the document. Then, send the URL of the document to your collaborator using email, or over the phone. Collaborating within an organization, or even across organization boundaries is simplified greatly by DAV.

No, since DAV is based on HTTP, which is an 8-bit clean protocol, WebDAV provides authoring support for Web resources of any media type, be they HTML, GIF, JPEG, or other. The versioning extensions also have a primary goal of supporting versioning of any media type, not just text-based objects.

One consequence of this is that diff and merge operations are not currently expected to be part of the protocol -- these operations are the responsibility of the client application, which has deep understanding of the media types it uses.

Nope. DAV is an underlying protocol. Imagine that DAV is a remote filesystem with extra properties. A document management system can then be built on top of that. Doc mgmt is an application, DAV is a protocol.

Now, it is fair to say that when DAV's specs for ACLs, searching, and versioning are completed, that a lot of basic functionality will be present for somebody to build one of these systems. I hope they do.

Yes, it is quite open. DAV is an IETF Proposed Standard (published as RFC 2518). As such, that means that it is an entirely open, published standard. IETF processes also attempt to guarantee an open, transparent process for the development of the standard -- anybody can participate by joining the mailing list (details on joining the core WebDAV or DELTA-V versioning and configuration management discussion lists can be found on the Working Group Home Page).

As a published standard, people can decide to adhere to it or not. If Microsoft chooses not to follow the standard, then so be it, but they cannot simply change it.

Regardless, I can personally state that Microsoft has been very willing and cooperative to ensure that their products interoperate with mod_dav. In fact, they've been quite helpful - I've fixed a number of bugs that were found with their help.

Now, with that said: it is possible for a company to state compliance with the DAV protocol. On top of that protocol, at the application level, they can do things that are special between their client and server. That is where application vendors will add value, and it is a standard part of doing business. If a server provides better application-level support, then you may end up tied to that particular server if you want that functionality. You are free to choose your DAV server, but recognize that you may lose functionality. Your choice, though.

The IETF WebDAV Working Group. The Group is chaired by Jim Whitehead and has its own set of web pages. Most of the actual job of creating the DAV specifications occurs within the Working Group on the DAV discussion lists.

All you need to do is join the discussion list. Anybody on the list is considered to be a member of the Working Group. Information for joining the discussion list is on the Working Group Home Page.

The W3C attempts to avoid protocols, leaving those to the IETF. Since DAV is a protocol, it is being handled as an IETF standard. DAV does use XML (a content standard, rather than a protocol), which is a W3C standard. Fun, huh?

A major feature of DAV is that it provides an upward migration path for existing non-collaborative applications which operate on entire files. WebDAV has been designed so that existing applications can easily add WebDAV support, since locks apply to entire resources, and the namespace operations support "File... Open" and "File... Save" user interfaces. DAV client APIs are lightweight, and hence do not add a significant development burden. The applications in Office 2000 are the first non-collaborative applications to be DAV-enabled, and others will surely follow.

As applications transition to adding DAV support, existing applications can be used on the local filesystem, and a program like sitecopy can upload changed files to a DAV server for you. Microsoft is also providing a feature called "Web folders" which makes a collection on a DAV server appear to be a directory in Windows. Non-DAV applications cannot work with these folders because the files/folders are only an appearance -- they are not mapped into a local filesystem. A Windows "redirector" could be written to make them appear as a local filesystem, but until that time, applications will need to be changed to work with a DAV-enabled server.

While the IETF expects that all participants are individual contributors, a lot can be learned by looking at the corporate affiliations of key participants. After all, if they're able to spend significant time developing DAV, they probably have the full support of their organization.

Participants from Microsoft, Netscape, Novell, and Xerox spent significant time developing the base DAV protocol, and there was significant interest by participants from document management vendors such as Filenet, Documentum and PC Docs as well. Jim Whitehead from U.C. Irvine chaired the effort, which is significant when you realize his officemate is Roy Fielding, a founder of the Apache Group. Combined, these organizations have the ability to make DAV a de-facto standard, with combined controlling marketshare on both the client and server side.

A team with world-class versioning and CM expertise is working to develop the versioning standard. Participants on the design team come from Rational (ClearCase), Microsoft (Visual SourceSafe), Intersolv (PVCS), Novell (GroupWise), and IBM (Envy), and there are academic participants from U.C. Irvine and Boston University. These people have the experience to develop a good standard, and come from organizations with sufficient market share to make this a de-facto standard. These organizations also have significant experience and marketshare in software development tools. However, it is important to know that the IETF process does not have a notion of membership, and there are no corporations -- only individual contributors (who sometimes happen to have the institutional backing of their corporation, a nice coincidence). There is no voting, only rough consensus on the mailing list. The result of this is that individual contributors (with or without corporate affiliation) can and do make a big difference, and are one of the primary reasons why IETF standards typically are of high technical quality.

The Projects and Software page lists some commercial products that contain support for DAV.

There are quite a few projects that are being developed. Here are four that are active:

1. mod_dav: a DAV module for Apache.
2. sitecopy: a tool for copying web sites from a local system up to a web server.
3. cadaver: similar to a command-line FTP tool, this tool provides for easy, direct interaction with a DAV server.
4. Goliath: a DAV client application and a DAV library for the MacOS operating system.

Quite easily, actually. Visit the mod_dav page for more information about it, and then sign up for the dav-dev mailing list.

The versioning group is writing the protocol specification as fast as they can, but the protocol may continue to change. If that doesn't bother you, then please feel free to start a project (let Greg know; he may be able to help and/or find other people to assist). You could also help develop the mod_dav extensions for Apache which contains some versioning support. Of course, you could also help by working on the protocol specification itself (see the DeltaV Working Group Home Page for details on how to get involved).

Since DAV works over HTTP, you get all the benefits of HTTP that FTP cannot provide. For example: strong authentication, encryption, proxy support, and caching. It is true that you can get some of this through SSH, but the HTTP infrastructure is much more widely deployed than SSH. Further, SSH does not have the wide complement of tools, development libraries, and applications that HTTP does.

DAV transfers (well, HTTP transfers) are also more efficient than FTP. You can pipeline multiple transfers through a single TCP connection, whereas FTP requires a new connection for each file transferred (plus the control connection).

For starters, there are several interesting ideas on how to integrate DAV and CVS on this page at cvshome.org.

The promise is that with DAV support, CVS will be able to interoperate with a wide variety of CM repositories, and will provide a much more compelling platform for project management, for as projects grow in scope, the CVS tools won't need to be abandoned if a project needs to migrate to a more full-featured repository. Also, if CVS is being used in a mixed shop where there are multiple CM repositories in use, WebDAV provides a valuable data integration layer which will allow CVS to interoperate against multiple repositories.

It certainly might at some point in the future. I believe what will happen is that the CVS front end will remain, so that you can continue to use the tools that you're familiar with. However, the backend will change. The wire protocol could switch to HTTP (picking up its benefits) and the CVS daemon would disappear in favor of a DAV server.

Not necessarily. The versioning specification is still in progress, but it does allow for multiple checkouts and merging. For now and for a while, CVS will still be your best bet; it is going to be a while before DAV's versioning capabilities match that of CVS.

This is an interesting question. DAV certainly has the posibility to do so. FTP is already being supplanted by HTTP. POP3? That could be a combination of DAV's PROPFIND method to get a list of new messages, a series of GETs to fetch them, followed by a number of DELETEs to clear them out. IMAP folder management? Just use DAV's MOVE and COPY methods to move messages around, or MKCOL to create new folders.

None of this will happen without clients, however. And that is a long ways off, if ever. It really depends on whether people want to stick to a single wire protocol (HTTP) with multiple application-level features, or whether people will prefer multiple wire protocols (FTP, POP3, IMAP, NTTP, etc). There is certainly an advantage to building a library for single wire protocol and then working on top of that. Since DAV uses HTTP, it adds a number of things that these other protocols don't have: authentication, encryption, proxying, and caching.

Rather than attempt to list it all here, I'd like to simply direct you to this site's home page.