- From: <jamsden@us.ibm.com>
- Date: Wed, 21 Jul 1999 15:41:21 -0400
- To: moore@cs.utk.edu, paf@swip.net
- cc: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
Keith and Patrik, I understand your concerns about the DELTA-V working group, and would like to take this opportunity to address them. First, some background. I started working with WebDAV about January of '98, and joined the versioning design team sometime around June of '98. Since that time, I have been building a WebDAV server architecture called DAV4J(http://www.alphaworks.ibm.com/tech/DAV4J) that supports multiple protocols and multiple repository managers. IBM is committed to standards, and is an active participant in many standards efforts including WebDAV. We currently have two members on the versioning design team. Now in reference to your specific concerns: Sufficient interest within IETF to justify a Working Group WebDAV is a strategic part of IBM's repository management strategy by providing a simple, open, standard, HTTP based protocol for controlled accessing and authoring of resources on the Web. Most of the repositories that we are interested in accessing through WebDAV are versioning repositories as controlled multi-user, multi-version, distributed repository managers are necessary for developing most of the enterprise Web applications we are interested in. This should be an indication of IBM's level of interest. Perhaps your observations at Oslo are an unfortunate consequence of the location, time of year, cost, and prior European exposure to WebDAV. What occurred there was certainly not consistent with our experience in Minneapolis. Hopefully the exposure at Oslo can act as the catalyst for developing further European interest. In the future, we can make it a priority to reach out to our global contacts to ensure they have an opportunity to contribute. The current design team does have a reasonably broad constituency. In fact, document management concerns have had a significant effect on the versioning semantics, moving them away from traditional source code control semantics to support a broader, more flexible community. Work completed outside the IETF process and mailing lists We did have an issue with this early on in the design team's work. We got a little caught up in the problem space and forgot the process. Jim Whitehead did a great job steering the group back to the IETF process, established the ietf-dav-versioning@w3.org mailing list, re-submitting old mail to the list, and hounding us to be sure we keep the process open and public. As a result, we have an active mailing list with a number of participants who are involved and contributing. It could be better, and hopefully will be if we establish a working group and start soliciting members. We have been reluctant to do this without approval of the charter. WebDAV needs participation by new members Most of the members of the design team are new to WebDAV. Only a couple of members, including Jim Whitehead were members of the original working group. We started with the initial work done by the original WebDAV design team, but most of that work has been redone and is reflected in the new goals, model, and protocol documents. The design team is extremely sensitive to reducing the complexity of the versioning semantics and protocol in order to be applicable to a broad user community, provide flexibility for client and server implementations, and to avoid alienation of particular repository manager products. This has been a significant challenge, and has consumed much of the design team's efforts. However we are making real progress and are looking forward to validating our work with a DELTA-V working group. Design team meetings are outside the IETF process I am new to IETF and am just getting familiar with its processes. It was our impression that we could schedule design team meetings without AD approval in order to provide meaningful work products for consideration by the working group members. Distributed authoring and versioning is a complex domain. A standard protocol for WebDAV versioning cannot be effectively developed in a couple of two hour meetings once a quarter with all other communication done through low bandwidth mechanisms such as email. WebDAV is also getting too complex for working group members to be able to pick up a spec, read it in a couple of hours, and provide meaningful feedback. The design team has tried to balance overwhelming potential working group members with these complexities by developing strawman documents that are intended to increase efficiency rather than subvert the public IETF processes. On the other hand, I sympathize with you, Keith, and somewhat agree this is not an Internet protocol issue, but an instance of a distributed business model that should focus on an API, not a communication protocol. However, the way we're designing DAV4J and WebDAV, we can have both resulting in compatibility with HTTP and convenient client access at the same time. The problem is that once you add namespace control, collections, properties, locking, versioning, configuration management, access control, links, ordered collections, and searching, you have a pretty complex system. The concepts on which HTTP was built, and what was good about it are a bit stressed by this much functionality. But we are making it work. The DELTA-V working group is required to push this effort to the next level. Summary Authoring on the web is an important contributor to successful communication on the web. We've gone so far with WebDAV already, and it would be a shame to stop now. Versioning is a key requirement to distributed, multi-user authoring of useful content that changes over its life-time. So I think we are compelled to finish adding the V WebDAV. IBM is committed to WebDAV, and versioning is a key requirement for our customers. We are happy to have the opportunity to contribute to this important work, and look forward to our continued participation in the a DELTA-V Working Group leveraging the IETF's broad influence on the Web and proven processes for achieving successful application protocols.
Received on Wednesday, 21 July 1999 15:42:23 UTC