RE: Submission: deltav subset

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 Monday, 22 October 2001 13:05:54 UTC