RE: Splitting the document

Right.  If actual implementations are going to use the "options" outside the
"core" then splitting the document seems of little benefit.  Perhaps the
combined document will take longer to be processed, but will it take longer
than a core document followed by an options documents?   The time might not
be very different.

... given also that splitting the document will take yet another round of
discussion ...

Enough chatter.  Time to cut to the chase scene :).

  -----Original Message-----
  From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
  Sent: Thursday, February 08, 2001 8:08 AM
  To: ietf-dav-versioning@w3.org
  Subject: Splitting the document



  It is extremely important that we define the versioning protocol in such a
way that interoperability is achieved between many client applications, and
many repository implementations. This is what defines the WebDAV value
proposition. Accomplishing this requires compromise between the needs of
many different existing and emerging client and repository implementations.
The Delta-V design team(s) and working group have spent many long hours
wrestling with this issue that resulted in many different proposals and
permutations of levels, core, extensions, etc. It was very clear early on in
our design sessions that starting out defining these different levels and/or
options was getting us nowhere. So our overall design strategy was to
iterate between defining a consistent set of semantics that provided the
functionality we all through would be useful in a distributed authoring and
versioning environment and logical subsets that met existing needs. ! ! !
Hopefully the result would be subsets consistent with the versioning
semantics as a whole. This would limit the possibility of having different
ways to do the same thing in different levels, and would ensure servers with
more options would be compatible with clients expecting less options.
However, coming up with the levels, even after having a pretty good idea of
the complete semantics, also proved extremely difficult. It seemed to that
whenever something got included, someone else would want it excluded and
include something else. We just couldn't decide.

  The lesson to be learned from this is that there is no one answer that is
going to meet everyone's needs. To me this is the key reason for keeping
versioning in one document. It allows server implementers to make their
implementation choices based on the options the want to support. Core
versioning represents the absolute minimum subset of the versioning
semantics that any client should expect from any versioning server. It
represents the subset of the versioning semantics that was common across
most of the repositories represented by the working group members. But
commonality does not imply semantic completeness, it just defines what's
common. Some WebDAV servers will certainly implement just core versioning,
and these will be useful. However, there are many server implementations
that either are, or will implement many of the options.

  I think we've already had our opportunity to "split the document" when the
"V" was removed from RFC2518. To support the server implementations that are
already underway, we need to move both core and the extensions through the
standards process. Otherwise interoperability will certainly suffer as the
needs of these sever implementations are not met by core. I realize this
will result in some challenges, but I think we need to face these challenges
with solutions rather than deferring them again. I also think Geoff has done
an exceptional job addressing the concerns of the working group by clearly
separating core versioning from each of the options, as well as making each
option as independent from all others as possible. The result still isn't
ideal in that there are a lot of options which will certainly introduce
complexity, especially for client writers. But it seems like an effective
compromise that we should take forwa! ! ! rd and let the process take its
course. Core versioning in a separate document would probably proceed
through the standards process faster and result in less controversy. It
might also result in more interoperable core-only server implementations.
But it wouldn't meet the needs of a number of WebDAV servers that are
already under development. Also, the time required to get an RFC number will
not necessarily inhibit development of interoperable servers. Many of us
were more than willing to implement WebDAV servers long before RFC2518 was
accepted. Participation in the working groups and understanding the
stability of the specification semantics are what's really important.

  So I think we should use the IETF process to help us uncover and address
controversial options. We should present the complete versioning semantics
in a single document so that 1) we ensure the semantics as a whole get
reviewed and issues are resolved, and 2) server implementers have the
specifications for the options they need to implement now, not at some later
date. Splitting the document up and allowing them to progress on separate
tracks will not meet the server implementers' needs, and as a consequence,
may result in less interoperable versioning server implementations.