IETF Delta-V BOF Meeting

IETF-44, Minneapolis, Minnesota
Wednesday, March 17, 1999

The Web Versioning and Configuration Management (DELTA-V) BOF meeting was held on Wednesday, March 17, 1999, from 13:00 to 15:00. Jim Amsden chaired the meeting, with Jim Whitehead recording notes. Approximately 65 people were in attendance.

The meeting began with a presentation by Jim Amsden on the proposed charter for the DELTA-V working group (charters were handed out to all attendees before the start of the meeting). Jim Amsden noted that work has been going on within WebDAV, in a subgroup, and they have determined that the area is sufficiently complex to warrant the creation of a new working group, and are holding this BOF to judge the level of interest in the topic.

During the presentation, questions were asked about the item in the charter stating that development of a server-to-server protocol is out of scope. These questions asked whether not having a server to server protocol would make it impossible to support configurations which cross servers. The concern was that cross-server configurations would lead inevitably to a server-to-server protocol. Jim Amsden replied that the design group believes it's possible to handle this case without going down a slippery slope to a server-to-server protocol. But, he noted that it's a possibility, and the design team will be alert for this.

Another question concerned why a versioning and configuration management protocol was being built on top of HTTP, and why was HTTP being used for authoring. Jim Amsden replied that this work was extending WebDAV, which initially extended HTTP for authoring because HTTP, and other protocols such as FTP, are insufficient for collaborative authoring of Web resources.

Jacob Palme next put up a handwritten slide showing annotations on versioned resources, and asked whether DELTA-V was considering supporting this kind of capability. Jim Amsden stated that while DELTA-V was not planning on addressing annotation support, he felt that (other than the versioning aspects) this capability could be implemented using capabilities of the WebDAV Distributed Authoring Protocol (RFC 2518).

This was followed by a discussion of version histories which span multiple servers. Yaron Goland felt very strongly that a versioned resource must be able to start on one server and end on another server. He noted that the WebDAV Distributed Authoring Protocol tried very hard to make sure that if, in the future, there were federated servers, the protocol wouldn't make this impossible. After some discussion on this issue, it appeared that, while the initial Web versioning and configuration management protocol wouldn't allow for the creation and manipulation of cross-server version histories, there was some agreement to work hard to make sure it's possible to express cross-server version histories.

There was a brief discussion on whether properties are versioned. In the current design, properties are part of a resource, and are versioned with it. However, some properties are mutable (for example, access control properties), and can be modified without causing a new revision to be made.

Another question was asked: will all clients have to know about all the configuration management capabilities in order to perform simple versioning operations? The answer was no, there will be either 2 or 3 levels of versioning capability, with simple versioning being at level 1.

At the end of the discussion period, Jim Amsden asked for a show of hands for people who thought the IETF should have a working group in this area, and appx. 25-30 people raised their hands. When the attendees were asked to voice any objections they had to such a working gorup being formed, nobody made any comments.

Chris Kaler next gave a presentation on the concepts, data model, and goals for the Web versioning and configuration management protocol, as developed by the subgroup of WebDAV that has been actively working on this problem.

A question was raised on the levels of versioning and configuration management support. The questioner noted that the current design has a number of discrete states of versioning support, and posited that it is likely that some clients or some servers might not be at exactly one of those points. Chris Kaler agreed with this observation, and noted that each level can be viewed as a minimum set of capabilities supported by an application, and an application might support more capabilities than they are advertising.

A clarification question was asked: when you check-out a resource, is this a shared or exclusive checkout? Chris replied that in advanced versioning, a checkout can be shared.

Mark Day noted that in previous discussions on this topic within WebDAV, there had been an issue of whether revisions were mutable or immutable. Chris noted that if there are mutable properties, then a "immutable" revision might change if its mutable properties have been changed. There is also the document management style mutability, where a checked-in revision might possibly be changed.

There was some discussion on the topic of activities, which clarified the concept for attendees. One question asked whether an activity is a change package, to which Brad Sergeant replied that an activity is not a change package, or a change set for that matter. There was discussion on the definition of an activity, and some scenarios of use. An audience member noted that an activity makes sense for the semantics of a merge operation, and Jim Amsden replied that activities will definitely be needed for merging together parallel changes.

An attendee asked if a revision is a delta between two objects? Chris replied, stating that a revision is a specific state of an item, not a delta.

An attendee noted that a configuration is defined in terms of revisions, not in terms of URLs, and wondered if this was correct. Chris replied, "Yes and no. It is a collection of revisions, but each revision has a unique URL."

A clarification question was asked: the existence of workspaces implies that you can handle multiple lines of development. Chris stated that this was correct.

Another question asked, whether there was an assumption that there is a central database and there is a view of this? Chris replied that the design group is assuming that a server implementation would use a database.

An attendee asked, can I version my workspace to create a configuration? Jim Amsden replied that you don't version a workspace. Jim stated that a configuration is a versionable resource, although this assertion caused some dissention among the design team.

The question was raised, why should a workspace be a server-side item? Why shouldn't the client take care of this? Chris replied that a workspace needs to be on the server for URL management, as well as for interoperability. Plus, when workspaces are on the server, a person can start work with one client at the office, then go home and use a separate client and still get work done.

There was a brief discussion on the complexity of revision selection rules (RSRs). Yaron Goland noted that RSRs sound very complex, and could perhap lead to the development of a Turing complete scripting language. There was agreement on the existence of this "slippery slope", tempered by a belief among the design group that RSRs can be kept very simple, without the need for scripting facilities. There was a suggestion that the DASL query language could perhaps be used for RSR definition.

The question was raised, can a team share a workspace? Chris replied that the design group is viewing workspaces as belonging to individuals, not teams. But, you could create a master, then make multiple copies of the workspace. This was followed by some discussion over how to support shared team development within a workspace. It was noted that there can be multiple activities per workspace.

During the discussion of workspaces, it was noted that if you want to copy them, then share them, etc., workspaces are starting to sound like they should be versioned. Chris replied that it might be possible, but the design gorup wishes to avoid the circularity of having to use versioned resources to control operations on other versioned resources. An attendeed noted, however, "this doesn't sound so hard to me. I've used a system where a workspace is a versioned resource, and it works quite well." Chris stated that the design group should go consider this issue again.

Chris next presents scenarios for versioning, which do not elicit any quesions. He then proceeds to slides on the goals, and then non-goals slide, which has history across servers listed as a non-goal.

Yaron Goland stated that he is concerned that some operations on revision histories, such as moving a label, might cause problems for version histories which span servers. Jim Whitehead noted that there are approaches that can address this, such as making labels a pair of a human readable string plus a GUID. Chris Kaler noted that the design group definitely needs to give this some thought and support version histories that are in a distributed environment. Yaron stated that he would be happy with language that stated that this functionality won't be explicitly supported, but that distributed version graphs should be possible to express. Chris stated that the design group will consider this. Since supporting this goal may lead to design choices we don't want to make, I don't want to commit to supporting this right now. Jim Amsden noted that IBM researched cross-repository versioning for a long time, and the issue is very difficult.

There was a brief discussion, including some use scenarios, on configurations, trying to clarify the participant's understanding of configurations. This was followed by a similar discussion of merging.

The question was asked whether is it possible for configurations to reference other configurations? Chris noted that the design gorup has been talking about this feature, and returned the question: "what you you think the right answer is?" There were several voiecs among the attendees who agreed with the assertion that configurations should be able to refer to other configuration. This was supported by a brief scenario where the same objects are shared across organizational boundaries (a graphics department makes graphics, and parking department uses them) within an organization. Chris noted that the design group will need to consider this issue more in light of this feedback.

There was some discussion on merging. One participant noted that it might be very valuable to not have merging be a very strict operation, and allow people to perform a later merge operation. It might be too strict to force people to merge all resources right away, or all during a merge operation, before other activities can take place. This was followed by some discussion trying to refine the question, and some belief by the design team that this capability is already supported. There was a decision to take this dicsussion offline.

*** End of meeting ***