RE: Versioning TeleConf Agenda, 2/2/00 (Friday) 12-1pm EST

Larry,
Welcome back! Excellent questions. Let me take a crack at them too. I 
share your concern that changes to WebDAV that are unrelated to versioning 
should be done by submitting separate Internet Drafts to the WebDAV 
working group. That is why I brought this subject up at IETF '49 WebDAV 
working group meeting. The sense of that meeting was that there were no 
significant issues, and in the interest of expedience, we could continue 
coupling the small changes and clarifications in the Delta-V spec which of 
course ends up being extensions to WebDAV anyway. There didn't seem to be 
any strong desire to address the issues separately. In any case, the end 
result would likely be the same. We will however consider doing a couple 
of things to help. We can make the REPORT method a versioning option 
rather than a new WebDAV method and move it out of the appendix. We will 
also copy the remaining items in section appendix A to a separate post to 
the WebDAV mailing list to make sure everyone there has a chance to review 
them, even if they don't review the whole versioning spec.

We have struggled with how to handle core vs. advanced vs. options since 
the beginning of Delta-V. In fact, there is a recent thread on this 
subject that suggests splitting them into separate documents. The 
compromise we came up with was to have core contain the minimal, essential 
support for versioning semantics that we expected every server vendor 
would implement. That is, core represents the common functions provided by 
all versioning repository vendors while the extensions represent the 
variability. However, we don't expect any server to just implement core 
because by itself, core isn't that interesting. Even the document 
management vendors have expressed interest in a number of the extensions. 
We just couldn't get any agreement on common subsets. This has been the 
greatest source of controversy, not the semantics of the specific 
extensions themselves. 

I agree that some of the extensions have not received the same level of 
working group scrutiny as core, but the overall semantics of these 
extensions have been under consideration and stable for quite some time. 
There are also a  number of implementations in progress that have not 
raised significant issues. So although I share your concerns about 
splitting core and extensions into separate documents, there are also 
forces encouraging us to keep them together. Until specific controversies 
arise that require them to be split, I'm inclined to keep them together in 
order to encourage implementation of more options by more server vendors. 
This will lead to better interoperability and more function to clients 
sooner.






"Larry Masinter" <lmnet@attglobal.net>
Sent by: ietf-dav-versioning-request@w3.org
02/02/2001 10:26 AM

 
        To:     "Clemm, Geoff" <gclemm@rational.com>
        cc:     <ietf-dav-versioning@w3.org>
        Subject:        RE: Versioning TeleConf Agenda, 2/2/00 (Friday) 12-1pm EST

 


Geoff,

I have some comments on the DeltaV spec based on an
internal review that I haven't been able to send
in on time. The major issue, though, is the
structure of the document:

Changes to WebDAV should be processed as a separate
document which updates WebDAV, with or without versioning.
It is unreasonable to attempt to "clarify" WebDAV
in the same spec that introduces versioning. The
WebDAV updates need to be reviewed by the entire
WebDAV community, and not just those people who are
interested in versioning.

Core versioning should be split into a separate spec.
Everything outside of core versioning is much less
likely to progress along standards track at the same
rate as core versioning (more time to get independent
interoperable implementations of every feature); by
linking "core versioning" with "non-core" in the
initial spec, you're setting yourself up for having
to split the documents later. Much of non-core is
controversial.

I'd dropped out of the delta-V mailing list for a while,
but I've just re-joined.

I've been searching through the email archive and can't
see where these structural issues are addressed.