Proposed charter for versioning WG

Jim Whitehead (ejw@ics.uci.edu)
Tue, 9 Feb 1999 13:45:49 -0800


From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Cc: Versioning <ietf-dav-versioning@w3.org>
Date: Tue, 9 Feb 1999 13:45:49 -0800
Message-ID: <001401be5475$8ed3bae0$d115c380@galileo.ics.uci.edu>
Subject: Proposed charter for versioning WG


One characteristic of the IETF which distinguishes it from other standards
development organizations is the IETF requires its working groups to have
finite lifespans, and to close after its work has been complete.  This is
motivated by a desire not to have working groups keep expanding their
mission to self-perpetuate, and to ensure that the working group doesn't get
"stale" with the same cast of characters rehashing the same issues.

Now, I don't think the WebDAV working group has fallen into any of these
traps yet -- we continue to make good progress on the versioning protocol,
and the advanced collections protocol.  We haven't strayed from our original
charter.  Now that the WebDAV Distriubted Authoring protocol has been
approved, we're starting to see lots of public announcements by companies of
their WebDAV product plans (see http://www.webdav.org/projects/).  There is
also increasing interest in open source development of WebDAV applications,
significantly helped by Greg Stein's webdav.org site.  All these are signs
of robust health.

So, you might ask, if it ain't broke, why fix it?  Well, one good reason is
that Keith Moore, our Applications Area advisor thinks the time is right.
But, more generally, I look at it as a case of preventative medicine.  By
creating a separate versioning working group, with its own separate charter,
several positive goals are accomplished:

 * It sends a signal that new people can become involved and participate.

   While it's always the case that new people can get involved in an
   IETF effort, it's often difficult to know when you can get involved
   without annoying people who have been working on the topic for awhile.
   For example, Mark Anderson's comments on draft-ietf-webdav-protocol-09
   last fall were well intentioned, but had terrible timing.

 * It provides the opportunity to refresh the agreement over what work is
being done.

   Most people on the mailing list today didn't have a chance to discuss the
   original WebDAV charter.  Even if there is common agreement that the
charter
   of the versioning working group should continue in the same vein as
current
   efforts, it still is worthwhile to make sure that *current* list members
   agree with the goals.

 * It forces people to explicitly subscribe to a new mailing list.

   Though it may seem funny to list this as a positive, working group
mailing
   lists tend to attract a lot of lurkers over time, people who want to
track an
   effort rather than being an active participant.  You might be surprised
to
   know that the WebDAV mailing list now has appx. 350 people on it!
Obviously
   you're not all active participants :-) (Although I very much appreciate
   having such a large pool of people to call on for volunteers for various
   activities). By causing people to reaffirm their interest by joining a
new
   list, it tends to "refresh" the membership.

 * It allows the burden of work to be more evenly shared.

   This one is more of a personal motivation, but it does impact the
   working group as a whole.  The motivation and ability to participate
   of the hardest working people in a working group is hard to sustain
   over several years, and it's good to have some rotation of duties.
   If too much is asked of the same people for too long, the working
   group suffers immensely when they, inevitably, are no longer able to
   participate any longer.

Many of you know that I have been working towards my Ph.D. degree while
being chair of WebDAV.  And, truth be told, my participation has definitely
delayed my graduation.  I have no regrets -- this has been an excellent
experience, the kind of activity I wanted to be able to work on during grad.
school.  Plus, interacting with members of the working group has been very
rewarding, both professionally and personally.  Still, I'm at least a year
away from graduation if I have complete focus on my degree, and I need to
get more of WebDAV off my plate to do this.

So, while I still intend to continue on as chair of the WebDAV working
group, working to finish up advanced collections, and work on issues from
the issues list, and resolve any interoperability problems that may arise, I
intend that the efforts on versioning and advanced collections will form new
working groups.  I will not chair those new groups, though I will help form
them, and make sure they get a good start.  My goal is to create continuity
from the current WebDAV working group into the new working groups, to make
sure none of the momentum we have is lost.

There is successful precedent for this in the DASL working group, which has
been making steady progress towards defining a searching protocol for DAV
resources (http://www.ics.uci.edu/pub/ietf/dasl/).  DASL shows the strength
of creating a new working group -- it has a different set of people working
on it than who developed the base WebDAV protocol, people who have deep
searching experience.  Their mailing list collected people who had interest
in the searching problem, helping ensure that their discussions are focused,
and not lost in other topics on the main DAV list.  DASL is the right model
for what the working groups on versioning and access control can accomplish.

At the bottom of this message is a proposed charter for the versioning
working group, which I have tentatively named "DELTA-V" (you know, to
emphasize they're creating extensions to DAV -- "delta" -- and are working
on the "V" part of DAV. :-)  I'd appreciate any comments you have on the
charter -- send them to the main WebDAV list.  You can also expect to see
another charter in the near future to develop an access control working
group, but I don't have this one done yet.

I look forward to working with you to develop these new working groups, and
to setting the stage for the completion of the original WebDAV goals,
creating a writeable, versioned collaborative Web.

- Jim

---------------------------------------


Web Versioning and Configuration Management (DELTA-V)

Chair(s):

TBD (Though Jim Whitehead emphatically declines to be chair)

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

TBD, probably Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion: ietf-dav-versioning@w3.org
To Subscribe: ietf-dav-versioning-request@w3.org
Subject: subscribe
Archive: http://lists.w3.org/Archives/Public/ietf-dav-versioning/

Description of Working Group:

xThis working group will define extensions to HTTP and the WebDAV
Distributed Authoring Protocol necessary to enable distributed Web
authoring tools to perform, in an interoperable manner, versioning and
configuration management of Web resources.

Versioning, parallel development, and configuration management are
important features for remote authoring of Web content.  Version
management is concerned with tracking and accessing the history of
important states of a single Web resource, such as a standalone Web
page.  Parallel development provides additional resource availability
in multi-user, distributed environments, letting authors make changes
on the same resource at the same time, later merging together those
changes. Configuration management addresses the problems of tracking
and accessing multiple interrelated resources over time as sets of
resources, not simply individual resources.  Traditionally, artifacts
of software development, including code, design, test cases,
requirements, help files, and more have been a focus of configuration
management. Web sites, comprised of multiple inter-linked resources
(HTML, graphics, sound, CGI, and others), are an important class of
complex information artifacts that benefit from the application of
configuration management.

The WebDAV working group originally focused on defining version
management capabilities for remote authoring applications. However, it
has become clear that while versioning functionality alone is useful
for a range of content authoring scenarios involving one, or a small
set of resources, versioning alone is insufficient for managing larger
sets of content. Protocol support for parallel development and simple
remote configuration management of Web resources provides
functionality for managing larger sets of interrelated content
developed by multiple users at different locations.

A sub-group of the WebDAV working group has developed functional
requirements for versioning and configuration management of Web
content. These requirements encompass the following capabilities,
which shall be considered by this working group:

IN-SCOPE:

* Naming and accessing resource versions and configurations
* Creating new revisions of a resource
* Placing a resource under version and configuration control
* History retrieval
* Differencing
* Merging of revisions and configurations
* Operations on configurations
* Mapping resource versions and configurations to the URL namespace
* Versioning support for downlevel HTTP and WebDAV clients

Further information on these objectives can be found in the document,
"Goals for Web Versioning".

NOT IN SCOPE:

* HTTP server to server communication protocols
* Versioning and configuration management via non-HTTP and WebDAV protocols.
* Implementation of functionality by non-origin proxies

Deliverables

The final output of this working group is expected to be two documents:

1. A goals document, which describes the high-level functional
   requirements for remote versioning and configuration management,
   including rationale. Jim Amsden, IBM, is editor of this document.

2. A model document, which describes the semantics of versioning,
   configuration management, and parallel development in a
   protocol independent fashion.  Editor: TBD

2. A protocol specification, which describes new HTTP methods,
   headers, request bodies, response bodies, and WebDAV properties to
   implement the remote versioning and configuration management
   goals. Chris Kaler, Microsoft, is editor of this document.

Goals and Milestones:

Since significant work on remote versioning and configuration
management has already taken place within the WebDAV working group,
the following schedule is a reasonable estimate of the remaining
effort, despite the scope of the working group.

Jun 99 (Specification, Goals, Model) Produce drafts of distributed
       versioning and configuration management protocol specification,
       as well as the goals and requirements documents. Submit as
       Internet Draft.

Jul 99 (Meeting, Specification, Goals, Model) Meet at Oslo IETF and
       hold working group meeting to review the protocol specification,
       goals, and model document.

Oct 99 (Goals) Create final version of distributed versioning and
       configuration management goals document. Submit for approval as
       Informational RFC.

Oct 99 (Specification, Model) Produce revised model document, and
       distributed versioning and configuration management protocol
       specification. Submit both as Internet Drafts.

Nov 99 (Meeting, Specification, Model) Meet at Washington, DC IETF and
       hold working group meeting to review the model document and the
       distributed versioning and configuration management protocol
       specification.

Feb 00 (Specification, Model) Submit revised model document, and
       distributed versioning and configuration management
       specification as Internet Drafts.

Mar 00 (Meeting, Specification, Model) Meet at Adelaide IETF and hold
       working group meeting to review the model document and
       distributed versioning and configuration management protocol
       specification.

Apr 00 (Specification, Model) Submit revised model document and
       distributed versioning and configuration management
       specification as Internet Draft.  Hold working group last call
       for comments on both drafts.

May 00 (Specification, Model) Revise model document and distributed
       versioning and configuration management specification based on
       working group last call comments, and submit both documents to
       the IESG for approval as a Proposed Standard RFC.