W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: DeltaV Draft

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 13 Jan 2001 20:59:05 -0500 (EST)
Message-Id: <200101140159.UAA13231@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

 > From: "Preston L. Bannister" <preston@home.com>

 > > We've already got a complex spec, so I try to leave out anything
 > > that doesn't directly contribute to interoperability.

 > The part about a complex spec is beginning to bother me :).

That is why the protocol identifies a simple "core versioning" 
subset.  If you are not a versioning expert, you should focus on
the core.  

 > Is there anything like a reference implementation?

The Versioning Protocol is intented to enter the standards track
at "Proposed Standard" level.  The point of a draft standard is
not to imply a particular implementation (reference or otherwise),
but rather is intended to allow the interoperation of very
different implementations.  In some ways, a "reference implementation"
is to be avoided, since it encourages clients to count on 
functionality provided by that implementation, rather than
restricting themselves to the functionality required by the
protocol specification.

In particular, here is the relevant section of RFC 2026:

 4.1.1  Proposed Standard

 A Proposed Standard specification is generally stable, has resolved
 known design choices, is believed to be well-understood, has received
 significant community review, and appears to enjoy enough community
 interest to be considered valuable.  However, further experience
 might result in a change or even retraction of the specification
 before it advances.

I believe this is an accurate characterization of the current state
of the versioning protocol.

 Usually, neither implementation nor operational experience is
 required for the designation of a specification as a Proposed
 Standard.  However, such experience is highly desirable, and will
 usually represent a strong argument in favor of a Proposed Standard
 designation.

My personal experience is that companies are reluctant to commit
resources to a versioning protocol until it has reached proposed
standard level.  A notable exception is the open source Subversion
effort, with Greg Stein's contribution to the DeltaV design (thanks,
Greg!).

 The IESG may require implementation and/or operational experience
 prior to granting Proposed Standard status to a specification that
 materially affects the core Internet protocols or that specifies
 behavior that may have significant operational impact on the
 Internet.

Since the versioning protocol operates at a level well above the core
Internet protocols, this section should not apply.

 A Proposed Standard should have no known technical omissions with
 respect to the requirements placed upon it.  However, the IESG may
 waive this requirement in order to allow a specification to advance
 to the Proposed Standard state when it is considered to be useful and
 necessary (and timely) even with known technical omissions.

There are no known technical omissions in the versioning protocol,
so this section should be satisfied.

 Implementors should treat Proposed Standards as immature
 specifications.  It is desirable to implement them in order to gain
 experience and to validate, test, and clarify the specification.
 However, since the content of Proposed Standards may be changed if
 problems are found or better solutions are identified, deploying
 implementations of such standards into a disruption-sensitive
 environment is not recommended.

This I believe is a correct characterization of the current
versioning protocol level.

 > The traffic in this list reminds me of any number of design
 > discussions in which I've been in the past.  Each participant
 > has an internal model of how the product (once built) may
 > function, and everyone's internal model is different.

That is intentional.  There are a variety of versioning models
out there (with implementations).  We are designing a protocol
which will allow a client to interoperate with a variety of
these models.

 > Once implementations exist you discover where your internal
 > models differ.  You also discover which bits are important, 
 > omitted, or downright boneheaded.

All of these models are implemented (many in large commercial
versioning repositories, some in open source format).  The
members of the design team are largely implementors of these
versioning systems.  The point of the protocol is to provide
a way for a client to interoperate with a variety of these
versioning systems, not to make up a new versioning model.
This avoids the downright boneheaded problem (those folks
either went out of business or their systems fell out of use).

 > I'm guessing there are people doing implementations, though
 > given the rate of change in the specification doubtless
 > no one is current with the spec. 
 > So where is the sanity check?

The sanity check is the existing versining repositories
(many of them with their own proprietary web access protocol).
The deltav protocol is a "unification" of that combined
experience.

Cheers,
Geoff
Received on Saturday, 13 January 2001 21:00:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT