DELTA-V: IETF-44 BOF Minutes

Jim Whitehead (ejw@ics.uci.edu)
Fri, 26 Mar 1999 17:33:36 -0800


From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 26 Mar 1999 17:33:36 -0800
Message-ID: <000c01be77f1$d6030b60$d115c380@ics.uci.edu>
Subject: DELTA-V: IETF-44 BOF Minutes

Below is the first draft of minutes for the DELTA-V BOF held at the
Minneapolis IETF.  If you have any comments or clarifications on these
minutes, please send email to Jim Whitehead <ejw@ics.uci.edu>.

- Jim

Meeting Minutes
DELTA-V BOF
Minneapolis IETF
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 ***