Re: Version issues

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Mon, 26 Apr 1999 08:57:28 -0400 

Date: Mon, 26 Apr 1999 08:57:28 -0400
Message-Id: <9904261257.AA02884@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: dbarrell@opentext.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <01BE8FDE.E80D25C0.dbarrell@opentext.com> (message from Dylan
Subject: Re: Version issues

   From: Dylan Barrell <dbarrell@opentext.com>

   On Saturday, April 24, 1999 2:24 PM, Sankar Virdhagriswaran 
   [SMTP:sv@crystaliz.com] wrote:
   > While on the face of it your proposal looks reasonable, I would like to
   > submit to you an alternative view. Jim W has already brought the
   > combinatorial explosion and hence I won't repeat it.

But I will ... (:-)

   I don't think we should ONLY support "simple versioning", but rather that 
   not all versioning functionality is necessary for the majority of servers 
   and therefore we need different levels of support. Failure to do this will 
   result in many vendors having to provide functionality they do not actually 
   need to provide in order to be WebDAV versioning compliant.

Your points about the benefits of several versioning levels in various
aspects of versioning support are valid.  These benefits must be
weighed against the cost of the combinatorial explosion in complexity
that this induces in the specification and in an interoperable client.
Two versioning levels is actually three, since "no versioning support"
is one of the alternatives.  This means that there are eight
combinations that the specification and vendors must be concerned with:

level-0 client -- level-1 server
level-0 client -- level-2 server
level-1 client -- level-0 server
level-1 client -- level-1 server
level-1 client -- level-2 server
level-2 client -- level-0 server
level-2 client -- level-1 server
level-2 client -- level-2 server

I encourage you to enumerate all the combinations resulting from a particular
set of levels and variants you propose, and an effective way for the
protocol writers, server vendors, and client vendors, to deal with them.

It is also important to note that two levels of versioning support actually
provides a significant degree of flexibility to a vendor that is providing
both a client and a server.  In particular, if the vendor provides at least
level-1 support in their server, then they can add any subset of level-2
support to their server, and design their client around that subset.  The
following interoperability will then be guaranteed:

vendor client  -- vendor server
level-1 client -- vendor server
vendor client  -- level-2 server

In order to maximize the choices available to such a vendor, the design team
is working hard to ensure that level-2 functionality is divided into
logical pieces of functionality that are as orthogonal to each other as
possible, so that a variety of vendor choices between level-1 and level-2
are feasible.

Cheers,
Geoff