2.1.16 Web Versioning and Configuration Management (deltav)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Jim Amsden <jamsden@us.ibm.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

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

Description of Working Group:

This 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:
* Naming and accessing resource versions and configurations
* Creating new revisions of a resource
* Placing a resource under version and configuration control
* Parallel development
* 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".
* HTTP server to server communication protocols
* Development process management, workflow, or change request management
* Versioning and configuration management via non-HTTP and WebDAV protocols.
* Implementation of functionality by non-origin proxies
The following documents are expected to form the final output of this working group.
1. A goals document, which describes the high-level functional requirements for remote versioning and configuration management, including rationale.
2. A model document, which describes the semantics of versioning, configuration management, and parallel development in a protocol independent fashion.
3. 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.
4. A traceability document, which describes the mapping between goals and protocol features.

Goals and Milestones:

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.



(Specification, Model, Traceability) Submit revised model document, and distributed versioning and configuration management protocol specification as Internet Drafts. Submit revised traceability document as an Internet Draft.

Mar 00


(Meeting, Specification, Model) Meet at Adelaide IETF and hold working group meeting to review the model document and

Apr 00


(Specification, Model, Traceability) Submit revised model document, distributed versioning and configuration management protocol specification, and traceability document as Internet Drafts. Hold working group last call for comments on all drafts.

May 00


(Specification, Model, Traceabiluty) Revise model document, distributed versioning and configuration management specification, and traceability document based on WG last call comments, and submit specification to the IESG for approval as a Proposed Standard RFC, and submit the model and traceability documents to IESG as Informational RFCs.

No Request For Comments

Current Meeting Report

DeltaV minutes from IETF-50

** Current status **

- Have held multiple WG last calls.
- Appears to be consensus on features, but not on packaging/grouping.
- Target one more draft before submission to AD.
- Have talked it over with ADs to see what kind of standard they need to meet before submitting draft to AD; Patrik said it's really down to whether the chair thinks there's consensus. If the AD doesn't find any omissions/flaws, then they'll issue the IESG Last Call.

** Yesterday's design meeting **

Propose deferring variants.

Propose packages.

Defined sets of functionality.

Protocol still reports "features" (a.k.a. options).

Labels separate.

Update separate -- plays against some advanced features.

Defer variants; if make it a separate milestone, with a separate design team, might be able to get a new set of people interested.

Packages wouldn't actually change the protocol; but it would say that sets of features go together; if you implement A, you MUST implement B and C. Reduces the combinatorial explosion, helps QA and interop testing. Four proposed packages: Base, File Versioning, Client CM, Server CM. Will have to be hashed out on the list, of course.

Issues: should that be "SHOULD implement B and C"; how does the server advertise which packages it support? Larry pointing out that, historically, one thing the IETF doesn't do well is protocols with a lot of independent options; packaging the options like this improves interop a lot.

Mark: that you don't need any of these packages to implement versioning; you could just do automatic versioning, which is in the core. Says we should have a package for the core, so that we could have simple, noninteractive clients.

Lisa: an autoversioning client could run against a Base server.

Mark: core is "sufficient to be deltav compliant", so it should be permitted.

Larry: the smaller subsets are interesting; leaning towards permitting a Core package.

Geoff: question is, is the cost of adding checkout and fork control, to be Base, is high enough to deter an implementor from going to Base.

JimW: probably not; it's probably under 1000 lines of code.

Geoff: right, because autoversioning has to do that checkout anyway, even if it doesn't expose it via deltav.

Larry: if all packages have checkout & fork control (proposed definitions do), then why not redefine core to include them, and drop the Base package?

Geoff: some people he knows want to expose "core" as a feature, which can advertised. Knows one server for whom it is very important to be core-only.

Larry: but is it useful to any client?

Geoff: that server does not want to allow non-automatic versioning.

Chris trying to get the sense of the room.

Larry: what kind of difference would this make to a client?

Lisa: not much; but it could well make a big difference for some servers.

[...] Geoff: bundling the base features into core gives us less flexibility later; we wouldn't be able to fix it later.

Eric: some clients will be perfectly happy to deal with core-level servers.

Larry: leaving them separate features is fine with him, but telling implementors it's OK to leave them out.

Separate thread: Update and Label are not in any of the packages; they're to be advertised separately.

Geoff: they're not really orthogonal, though; they'd harm Client CM and Server CM.

JimW: maybe {Client, Server} CM should imply "MUST NOT support Update, Label".

Eric: Label might be harmless, actually.

(Larry asking, and Geoff explaining, why Update is harmful.)

Eric: so, should File Versioning imply Update?

Chris: there are backends where File Versioning would be possible, but Update very difficult.

Larry: get rid of Update, maybe?

Geoff: let's take it to the list; its defenders aren't here.

Larry: so what was it for?

Geoff: well, it was needed back before we added some of the more advanced CM capabilities; it might not be needed any more.

Should we cut Label?

John Stracke: without Label, it's going to be pretty hard to build on top of CVS, which is important to a lot of people, esp. open-source projects. Discussion over what to do; we might be able to define a simpler degree of CM that CVS could do. One thing that makes Label complex is the Label: header (interacts with GET and PROPFIND; has to be internationalized specially); but maybe we could cut that. Discussion.

Sense of the room: remove the Label: header; possibly remove Update.

JimW: could the simplified Label be rolled into any of these?

Geoff: Certainly into {Client, Server} CM.

** Open Issues **

- Should COPY of collections delete destination elements not in source?

That's what 2518 says, but that's not what people expect, and not what filesystems actually implement (they merge into the existing collection). Define a header to request the merge behavior, or update 2518?

Larry: if we update 2518, it should be in a separate doc.

JimW: the header option is what an early WebDAV draft did, and it succumbed to optionitis. But there might be clients that depend on the current behavior. Action item: JimW will follow up on revving 2518.

- Should we declare that no versioning properties are returned by allprop?

JimW: why?

Geoff: so that servers can avoid the cost of computing them, particularly since most clients currently doing allprop are not version-aware and won't be able to use the versioning properties. (Side thread about deprecating allprop altogether. The natural issues.) Discussion: what level should this requirement be?

Chris: some servers will find it easier to send everything (for one reason or another), and they shouldn't be required to filter.

Larry: how is filtering going to be more expensive than generating & sending the XML?

...Chris recording: sense of room: SHOULD NOT, with explanation.

- Should the checkin on unlock create a new version if the resource has not been changed while it was locked?

Geoff: the spec for autoversioning says that checkout occurs on update, but not on lock.

Chris: let's make it optional, for stores that automatically check out on lock.

Geoff: but what if you do a depth lock, just to modify a single resource? It would be really inefficient. Also, clients need predictable behavior.

Chris recording: sense of the room: no, because the checkout doesn't occur until a modification is made.


JimW: just copy it to a non-version-controlled part of the namespace.

Chris: but this is something that'd be done in situ.

Lisa: this will destroy too much information.

JimW: do you really want to add this new feature right when we're trying to finish up?

Chris: somebody asked for it; we should address it.

Geoff: yes, we're addressing it; but its utility is so low that it's below the bar for now.

Larry: so what was the actual problem to be solved?

Lisa: I want a way to take a versioned resource and make it non-versioned.

Larry: what's wrong with copying it away and then moving it back?

Lisa: it's not in situ, so it doesn't get logged properly. But...it's a reasonable workaround; can we document it?

Chris recording: sense of the room: document the workaround.

- Should we get rid of DAV:version-set property of a version history resource?

Chris: why?

Lisa had pointed out that there were too many ways to get at the version history; thought this one was one we could get rid of; but maybe a different one would be better. Discussion; it comes out that there are only two ways to get the entire history: version-set and a report. Lisa had thought that the predecessor/successor properties had been "all predecessors/all successors".

Chris recording: sense of the room: clarify that pred/succ properties are immediate only, maybe add an implementation note for clients on the best way to get history, explain that the different methods are equiv.

- Should the DAV:version-controlled-configuration be on all members of a baseline-controlled collection?

Geoff explaining: version-controlled-configuration is the property of a baseline-controlled collection that lets you create new baselines. It's currently on the root; Greg Stein wanted to be able to use it on any member.

Chris: was there any dissent when it came upon the list?

Geoff: no.

Chris: any objection here? No.

Chris recording: sense of the room: no objections, but no strong support, either.

Should the URLs in the DAV:compare-baseline report be version URLs or URLs from the DAV:baseline-collections of the baselines being compared?

Geoff explaining.

Geoff: Pros and cons of the two approaches are obscure; current way (version URLs) is a little bit simpler, since there's only a single space of version URLs, which makes them easier to compare.

Chris: anybody here have an opinion?

JimW: better to return the more canonical URL (version URL).

Eric and ? agree; Chris recording that as sense of the room.

- Add a DAV:error node above the 403/409 XML elements?

Basically, it makes the DTD easier to write, by isolating all the places where there might be 500 possible errors to specify.

Sense of the room: no objections, some limited support, a request to unify with the advanced status reporting stuff.

- Should we create an appendix with all the DTDs? Maybe XML Schema?
It's being voted on now, and the vote should take about a month.

(JimW: and if Tim B-L vetoes it six months later?)

Sense of the room: wait for Schema; create an appendix with schemas; if Schema isn't approved in time, we make the appendix non-normative.

- Lisa bringing up a new issue on "version history resource": the introductory paragraph lists some things it can be used for, but doesn't explain how.

Geoff explaining; they'll put it in the draft. Also noting that the VHR is a good place to put global (cross-version) properties of a resource.


None received.