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