Re: Complexity and Core Considerations

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>

   > 1) Is the current form of the specification too complex?  Yes/No/Maybe.
   > Why?

   No.  Complexity is in the eye of the beholder -- this specification seems as
   complex as needed to specify the included functionality.  This specification
   is actually smaller than the *user's* manual for most CM systems.

I agree with Jim.  If someone has a specific, concrete suggestion for
how to make it simpler without damaging interoperability, we'd love to
hear it.  Over the last 2.5 years, we have proposed removing every
option that currently is defined (often trying more than once), and
only vocal and energetic support from multiple client or server
implementors for that option in its current form has kept any given
option alive.  In other words, these implementors are counting on
that option to serve as the basis for interoperation.

   > 2) Does there remain sufficient discussion going on surrounding
   > the OPTIONS that the draft should be split into two documents, CORE and
   > OPTIONS, so that we can move CORE forward?  Yes/No/Maybe.  Why?

   I'm in favor of splitting the document, since I think that will make it
   crystal clear exactly what constitutes core versioning.  Thus, I'm in favor
   of splitting, even if all the parts are submitted at once.  Document
   splitting doesn't imply lack of adoption -- we've seen messages on this list
   in the past few days from major vendors indicating they will implement broad
   swathes of the specification.

Jim makes an important distinction here.  One question is whether we
submit the versioning protocol as two documents or as one.  A follow-on
question is if we do split the document, do we submit them at the same
time, or do we submit versioning core first and then versioning options
at some indeterminate time in the future.

The first question is just an editorial question.  I would prefer to
keep the versioning protocol as one document -- after all, when the
first paragraph of the introductions says:

  "An implementor that is only interested in core versioning should read
   Section I (Introduction), Section II (Core Versioning), and Section
   15 (Report Option)."

is a reader really all that likely to be confused?  But here I'm happy
to do whatever (heck, I can cut'n'paste with the best of them :-), so
I'd like to just pass this decision over to Jim Amsden, our working
group chair (and he can pass it on to whoever he wants, just so it
isn't back to me :-).

But I am strongly opposed to delaying the submission of the versioning
options for "proposed standard" status, since after 2.5 years of work
by numerous members of this working group, with 12 internet drafts and
over 50 working drafts, we have reached significant consensus on the
suitability of the current versioning options for providing a basis
for interoperable implementations.

I have personal experience with the requirement of many implementers
(or at least, those implementers bosses :-) that the protocol reach
"proposed standard" status before significant implementation
commitments will be made, and it is my strongly held belief that we
have gotten as close as we are going to get by "talking about it", and
that the remaining interoperability issues will now only be uncovered
by those implementation efforts that currently are waiting for the
protocol reaching "proposed standard" status.

I believe it is virtually certain that there will be significant
changes to the protocol between "proposed standard" and "draft
standard", but I also strongly believe that these changes will only be
identified through attempts to achieve interoperability through a
stable (initial) version of the protocol.

Cheers,
Geoff

Received on Saturday, 3 February 2001 15:53:12 UTC