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

Yaron Goland (yarong@microsoft.com)
Thu, 21 Jan 1999 20:10:57 -0800


Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D79@RED-MSG-59>
From: Yaron Goland <yarong@microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org,
Cc: gclemm@tantalum.atria.com
Date: Thu, 21 Jan 1999 20:10:57 -0800
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

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.

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. 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.

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.

			Yaron

> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
> Sent: Thursday, January 21, 1999 8:07 AM
> To: Yaron Goland
> Cc: gclemm@tantalum.atria.com; ietf-dav-versioning@w3.org
> Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for
> consensus
> 
> 
> 
> 
>           1) Should mutable resource management be in-scope for
> WebDAV?
>           2) Are the mutable resource and versioning models similar
> enough to justify worrying about their interoperability?
> 
> Yaron,
> 
> There seems to be versioning WG consensus that 1) should be 
> in scope in
> order to provide sufficient for typical document management system
> semantics. A number members, including myself and Geoff Clemm 
> feel that
> mutable revisions  compromise versioning and configuration 
> management and
> should not be included in the protocol. However, we found 
> that in order to
> make progress, we had to yield and support the more flexible 
> DMS semantics.
> 
> On your second question, this was discussed at length in the 
> Portland WG
> meeting, and it was generally agreed that the DMS servers 
> didn't want to
> have a separate protocol, but wanted to share most of the 
> semantics of more
> formal versioning systems, but with the additional freedom to change
> revisions. Interoperability was a secondary goal, and as you 
> point out,
> clients from both camps could be confused by servers 
> supporting the other
> camp. This is an unfortunate result of having a lot of options.
> 
> This issue has consumed a lot of the versioning WG's 
> attention and effort,
> perhaps at the cost of reaching consensus in other important 
> areas. I think
> we should formulate use cases that motivate these various semantic
> alternatives, and look for common agreement. I also think we 
> need to focus
> on semantic coverage of versioning, parallel development, and 
> configuration
> management before we introduce semantic variants, options, and
> optimizations. Otherwise we run the risk of including some 
> feature only to
> discover it doesn't make sense in the context of other features.
> 
> For example, in systems that support parallel development, 
> when activities
> are merged, the system can generate the conflicts list, and 
> can maintain
> the list as they are resolved by the author. Having this 
> capability is of
> enormous importance because it helps make sure changes aren't lost. If
> revisions are allowed to change, then an author cannot rely on the
> conflicts list. New conflicts could be created at any time without any
> record. Similarly, changing revisions of resources in a 
> configuration used
> to deploy a web application compromises the ability to re-create a
> particular distribution. Sure, changing a spelling mistake in 
> a document
> might not have any significant effect on the configuration, 
> but what about
> changing an assignment in a script that is part of an HTML 
> page? Where does
> it stop? Is this something you want to leave up to any author 
> to decide?
> Authoring web resources is much more than authoring static 
> documents, and
> the versioning requirements are much stricter. The question 
> is, do document
> management systems have the same semantics? Should they? Do 
> they care about
> parallel development and configurations? How many options do we expect
> client applications to deal with? Are these issues we want to 
> resolve in
> the protocol, or are they client issues?
> 
> 
>