- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 23 Oct 2001 10:11:13 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>, "Jim Amsden" <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
I think the definition of this deltav subset is very much needed and that Lisa has made a very good start with it. To be more specific: - Our server falls (from deltav point of view) into the same group as sharemation does: linear versioning on resources, no versioning on collections. There is definitly a need for such servers. - DeltaV is so rich (and for good reasons) that as an implementor you have to make quite a lot of choices. The definition of a subset would give guidance in this process and ensure interoperability. Without such a definition, I see interworking between deltav servers and clients as a much longer and more painful process than it needs to be. //Stefan > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault > > I'll explain some of the background to this message, since I started the > thread below its cc' list was expanded. Initially, I asked Jim > Amsden if he > wanted a new deltav-related internet-draft to be a working group > draft or an > individual submission. This explains the history and reasons > behind the new > internet-draft... > > I've talked to various people in the last few months, both those involved > directly in the DeltaV WG and those mostly involved in WebDAV but > keeping an > eye on DeltaV. A common theme has been some uncertainty what features > should be implemented for simple versioning, in software not intended for > source control but just for web authoring or document management. The > existing packages defined in DeltaV are a good start, but there's > still lot > of possible variation in how to implement a DeltaV server or client even > once a package has been chosen. > > Thus, I've been working on a document to make it easier for simple WebDAV > authoring clients to implement DeltaV, by selecting a number of > features and > a number of simplifications that a server can make. If a server > advertises > these simplifications, then the client's job is much easier (the client > won't have to worry about forking, multiple checkouts, older versions > getting checked out, or older versions being targetted). Both the server > and the client can still be DeltaV compatible. > > I've posted the initial draft on > http://www.sharemation.com/~milele/public/dav, and it should soon be > available on the IETF site as well. I'm very much interested in hearing > comments, suggestions, etc. Much thanks to Peter Raymond, Alan Kent and > Mark Hale for their initial comments. > > Lisa > > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden > Sent: October 18, 2001 4:35 PM > To: ietf-dav-versioning@w3.org > Subject: RE: Submission: deltav subset > > > > I'm inclined to declare victory on our DeltaV charter and let some servers > get built on what we have before we start making a lot of > immediate changes. > Of course I would welcome any BOF to determine level of interest in > extensions, new packages, etc. DeltaV is now firmly on the > standards track. > The next step is to get some implementation and determine interoperability > issues. If the community fragments immediately on different packages that > aren't interoperable in meaningful ways, then certainly that's good > information for the standards process that would need to be > addressed. But I > think the community would benefit from attempting to implement the spec as > written so we encourage interoperability. > > As for shutting down DeltaV, we're only at proposed standard. We could > consider updating the charter to move to the next stage in the > lifecycle. I > would be happy to entertain suggestions as to the content of such > a charter, > and if there's sufficient interest, we can propose the next set of work > items to the AD's as either continuation of DeltaV (with a new > charter), or > other working groups focused on more specific tasks. > > > > "Jim Whitehead" <ejw@cse.ucsc.edu> > 10/18/2001 06:36 PM > > To: "Clemm, Geoff" <gclemm@rational.com>, "'Lisa > Dusseault'" > <lisa@xythos.com>, "Jim Amsden" <jamsden@us.ibm.com> > cc: > Subject: RE: Submission: deltav subset > > > > > > Geoff Clemm writes: > > I think it is more appropriate to keep it as an > > individual submission until the working group has had > > a chance to review/iterate on it. > > This may be true, but IETF policy does say that it is the Chair's > discretion > on whether a document is a WG draft or an individual submission. > > I was just pointing out that Jim may cause friction with the ADs if, by > making a new WG draft, he extends the life of DeltaV when they think it's > close to being shut down. I imagine they are keen to avoid another WebDAV > :-) > > But, even if Jim does decide that it should not be a new draft, > it would be > well within Lisa's rights to hold a BOF at the next IETF with an > eye towards > creating a new WG, "SDV" (simple Delta V), say. > > - Jim > > >
Received on Tuesday, 23 October 2001 04:10:11 UTC