Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

David G. Durand (dgd@cs.bu.edu)
Fri, 22 Jan 1999 09:24:48 -0500


Message-Id: <v04011703b2ce346409e3@[24.0.249.126]>
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D79@RED-MSG-59>
Date: Fri, 22 Jan 1999 09:24:48 -0500
To: "Keith Moore (E-mail)" <moore@cs.utk.edu>, ietf-dav-versioning@w3.org,
        "Jim Whitehead (E-mail)" <ejw@ics.uci.edu>
From: "David G. Durand" <dgd@cs.bu.edu>
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

At 11:10 PM -0500 1/21/99, Yaron Goland wrote:
>There has been a general thread through the posts of the versioning authors
>which lead me to believe that the authors may not be familiar with how
>consensus is reached in an IETF WG. Especially the WebDAV WG which has a
>long established tradition in this area. To quote from section 3.2 of
>ftp://ftp.isi.edu/in-notes/rfc2418.txt:
>
>   Decisions reached during a face-to-face meeting about
>   topics or issues which have not been discussed on the mailing list,
>   or are significantly different from previously arrived mailing list
>   consensus MUST be reviewed on the mailing list.
>
>I know how frustrating this rule can be. You go to a meeting, you argue for
>days on end, your throat goes raw and finally you get consensus amongst the
>attendees. Then you have to go do it all over again on the mailing list.
>However that is the nature of the beast.

Some of us are quite aware of this. However, when the documents are
incomplete, and the proposals are still unclear, there's a limit to how
enlightening such a discussion can be. I fully believe that the current
procedure is intended to allow convergence within a small group before
opening up a free-for-all.

As in the previous DAV standard, this is somewhat less-open than a
traditional IETF process, since one proposal has a full team creating and
supporting it, and the others probably will not.

I was not happy during the first DAV process because of these very factors,
but in the end the standard is pretty good. You may now be understanding
some of the frustration that others expressed to you the first time around.

In both cases, there is no intention to _ram something through_ the Working
group, simply to deal effectively with what has proven to be an
exceptionally complex design space. I am also convinced that there's a good
cross-section of the entire community in the authoring team, so that there
are not any obvious "blind spots."

In any case, all drafts will go through the normal working group process,
so that your claims of process problems are premature. The quote says that
decisions must be reviewed on the mailing list, not _made on it_. (though
that is also possible.

My memory of the discussions (I dropped out only when it was clear that
versioning was not going to go into the first rev), was not one of clear
consensus. At that time I was on the other side. It was also at least two
years ago, and little substantive discussion on these topics has taken
place until very recently. In other words, the argument that we're
reversing a clear consensus seems weak to me, even though I also think that
it's preamture to
worry about the question at all.

In other words, I think the objection is irrelevant first (because the
process is not being violated) and wrong anyway (because clear consensus is
not established).

>A quick review of the mailing list archives (both of the versioning list and
>the main list) did not turn up any explicit discussion of the inclusion of
>mutable resources in WebDAV.

Right. you're seeing it now (in imperfect form) and you'll see it again,
but probably in the form of reaction to actualt proposals.

> Given that this issue requires the group to
>address matters wholly irrelevant to traditional versioning and thus make
>the protocol more complex and the time to standardization longer I believe
>that a rough consensus should be arrived at before we continue down this
>course.

 While I'm sympathetic to your comment about "traditional versioning," I've
found that there are a lot of traditions out there, and that each must be
examined carefully for its virtues and drawbacks (and the relevance of its
community).

>Given that one can produce an extremely useful standard which does not have
>any support for mutable resources I think there is a strong argument to be
>made for punting mutable resources to a separate spec to be written after
>the versioning spec is finished.

One of the things that became very clear in discussions with the
office-document management people is that without mutable versions they
probably will not find DAV versioning useful enough to implement. A Web
versioning standard that doesn't work with an important class of authoring
applications will be _much_ less useful than one that does.

One of the things that is exciting about Geoff's proposal is that it
actually unifies these two views of the world without adding protocol
complexity, or doing violence to the semantic expectations of either kind
of client or server.

It is _not_ easy to get the first time. It took me a few hours to actually
believe that it works, partly because it makes a non-obvious equivalence
between linear lines of descent (as implemented by almost every
configuration management system), and mutable versions (as used by office
document management products). It also removes behavior options, since the
same exact operations are available at the basic versioning _and_ the
advanced versioning levels -- but of course advanced versioning
(configuration management) has a bunch of extra stuff that it can do as
well...

If we were talking about _extra_ complexity for an unimportant class of
flient and server, I'd be with you, but it's actually a a very important
class of applications, and it's _simpler_ than the competing proposals.

 -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________