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

Yaron Goland (
Fri, 22 Jan 1999 14:52:12 -0800

Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D86@RED-MSG-59>
From: Yaron Goland <>
To: "'David G. Durand'" <>,
Date: Fri, 22 Jan 1999 14:52:12 -0800
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

The purpose of my response was strictly to challenge James Amsden's post
(the one I was directly responding to) that consensus already exists on the
issue of support for mutable resources. My point is that consensus most
certainly does not exist because only the mailing list can be used to
measure consensus and the issues have not been presented to the mailing

I hope the authors don't get the wrong message. No one is angry at them or
urging them to hurry up. Real work only began last December. The progress
that has already been made is breath taking and I'm sure the group is happy
to wait an extra month or two until the authors are able to fully agree with
each and provide a unified proposal to the working group.

I don't believe the process is broken. I just want to make sure that the
authors fully understand how the process works.


> -----Original Message-----
> From: David G. Durand []
> Sent: Friday, January 22, 1999 6:25 AM
> To: Keith Moore (E-mail);; Jim Whitehead
> (E-mail)
> 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
> >
> >
> >   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      \
> Boston University Computer Science        \  Sr. Analyst
>   \  Dynamic Diagrams
> --------------------------------------------\  
> MAPA: mapping for the WWW                    
> \__________________________