2.1.12 Web Versioning and Configuration Management (deltav) bof

Current Meeting Report

Delta-V BOF
Oslo IETF 45
Wednesday, July 14, 1999

A birds-of-a-feather (BOF) meeting of persons interested in the topic of Web versioning and configuration management was held on Wednesday, July 14, 1999, from 15:30 to 17:30. Geoff Clemm chaired this meeting, with Rohit Khare acting as notetaker. Jim Amsden subsequently edited these raw meeting notes to produce the final minutes. John Klensin was present as IAB representative, and Keith Moore was present as Application Area Director representative.

Meeting Summary:

Geoff Clemm lead discussions on the DELTA-V charter and initial draft of the versioning protocol document. The group discussed the five functional categories of WebDAV versioning: Core, Activities, Merging, Configuration Management, and Versioned Collections. This was followed by discussion about the role of IETF in the development of distributed configuration management systems. In order to quantify the value IETF brings to this effort, and to gauge the level of interest, Keith More, the Area Director responsible for WebDAV would like to hear directly from people who would be interested in participating in the DELTA-V working group.

Meeting Details:

The charter was reviewed without discussion. No issues were raised.

The versioning design team has produced an initial draft of the versioning document, webdav-versioning-02.

Versioning extensions are divided into five categories: Core, Activity, Merging, Configuration, Versioned-collection.

There was a lot of discussion of the DELTA-V definitions of Revision Name and Revision identifier and Revision Label. Revision names are used to distinguish revisions of the same versioned resource. A revision name is either a revision identifier or a revision label. Revision identifiers are assigned by the server, and cannot be changed or reused. Revision labels are assigned by users and can be moved from one revision to another. Revisions of different resources can have the same revision label.

Under merging, DELTA-V maintains the merge predecessor and merge successor relationships. These relationships allow a revision to have multiple predecessors.

Servers can choose to allow or disallow modification of existing revisions. A revision cannot be modified without first checking it out.

Labels cannot be assigned to a working revision.

Revision name + Revision label is unique, as is each half; thus cut-n-paste is easier (copy some resources under A to B). (Editor's note: don't know what this means)

Larry Masinter: I want to discuss the relation of versioning objects, collections, and compound objects.

Why versioned collections, not just Versioned Resources? Versioned collections allow the resource namespace to be managed just like a revision of a resource. This allows an old version of a site to be recreated or reinstituted so that it can be used as the basis of further work.

Should we restrict Versioned Collections to only include Versioned Resources? What can be a Versioned Collection member? e.g., PUT to a checked-out versioned resource: creates a new versioned resource with an initial revision? (Editor's note: PUT to a checked-out revision (a working resource) updates the working resource with the request contents. It does not create a new versioned resource or new revision of a versioned resource.)

Versioning as applied to "dynamic HTML" (a question about content bodies). Versioning can only be applied to source documents, not dynamic content. For example, consider a Java servlet. The servlet run-time may not be versioning aware, and can only load one version of the servlet for all requests.

[bodies may not be out of scope, whereas in DAV we scrupulously ignored content]

Dynamic content was ruled out of scope for Delta-V all along.

Activities group several new version creations (compound action). Logical unit of change.

Clarification: each revision can appear in at most one activity. BUT, a back-trace could implicate many activities .

Push back from John as to "who does this complex stuff" and "my graph theory beanie hurts". Geoff defended the scope and scale of the people in the Working Group.

Keith More: you don't have a Working Group, and won't have one until you prove what value IETF adds. I'm asking you how large the community is for any given revision graph. And, how many policy authorities are there which can decide "this branch is dead"?

How many people are actively causing branching and how many people can prune.

Geoff Clemm: several hundred at a single site, several thousand in a multi-site organization. That's my user space.

At the other end of the scale, we want to support 3-4 people collaborating on a single document. Our goal was to span the range.

LM: yeah, there are large user communities.

GC: please, yes, it's a DELTA-V "design team" and the WebDAV "working group"

audience murmur: this makes DAV attractive to a much wider community (which is why we're arguing for a fresh Working Group, to increase review).

What are the new properties and methods? New methods: CHECKOUT, CHECKIN, UNCHECKOUT, MKRESOURCE, REPORT

Geoff: properties have various characteristics, but 3 of the key ones are: read-only/write-only; Immutable/mutable ; resources as properties. Simple live/dead dichotomy was less useful.

Looks like the RDF data model abstractly; it's more complete, but probably not simple enough. If we can plug-in-RDF here, that would be something to discuss.

??Created a variant of PROPFIND that composes the compound response (de-reference). "resourceification" of properties. Question: "a fancier PROPPATCH?" yes... an optional extended PROPATCH for "large" XML-ish properties. This is the "property resource" issue. A PROPFIND can return a textual report, a URL of a "property resource", or both.

EXAMPLES of properties that we were adding to arbitrary resources: DAV: author and DAV: comment

Issue: property resources (complexity of explanation).

The classic example of the genre is the history list itself.

Larry: the assumption that it's too expensive to make it a resource is odd; it's just a URI.

Property resources are for things that are logically collections, like the set of merge successors.

Keith Moore: this (the overall protocol) seems over-baked.
Answer: Remember, V is a large part of DAV, and reflects 18 months of past work.
Keith: I don't want to constrain a future WG to this alone. You'll have a hard time attracting people to the work until they make significant changes to it.

Rohit Khare: let's power through and do the charter

6 hands up -- but all were in WebDAV

John Klensin: I'm trying to avoid two overlapping WGs.

Keith: wait, I did tell Jim to wind down WebDAV and substitute this instead.
Larry: this HAS a broader scope than DAV does, but those people who might join this group are not in this room.

participant: And I don't think they'd come to the IETF, either.

Larry: e.g. distributed configuration management systems, beyond document authoring to software release management.


Keith: so are these people on the mailing list?

Geoff: in the beginning, lots of versioning people dropped out of DAV, and are now waiting to return.

Keith: what I want to see is support from new people; supposedly, we know who to contact, so let's get them into this room.

John: what he said is necessary but not sufficient. If this is REALLY an important problem, and there's no gain to IETF involvement, and it's a sufficiently interesting problem, but then found a VForum or something else. Is there significant value add to ALSO doing something at IETF.

JK: Technically, there are a host of interesting variations on the problem here. BUT, the model seems more complicated than necessary, but still not adequate for the worst cases. That's not a stable middle ground.

Keith: why IETF?

LM: I was at the DMA TC meeting, and there was some interest in aligning. The model in the current versioning draft had some mismatches with the DMA effort -- harmonization may mean backing away from our current design.

Geoff: in Orlando, there were a large number of hands raised. Look, even of all the design team, I'm the only one to make it (to Oslo). We haven't seen as much European contributors (and not active). 90% US.

Larry suggested that DAV was less interesting to the Eu DMA participants.

Rohit reaffirmed that people did NOT come to Oslo, by cost. AND that Jim has to quit.

Keith: all I need to see is that folks will take it on at the IETF.

Geoff: look, I spend 80% of my time on DAV because management sees this as the ONLY effort that promises interoperability. This is the ONLY way we're going to get a standard in this area. Losing it would be a disaster.

Keith: I'm concerned for diversity. If Europeans aren't here, I'm concerned.

Nick Shelness: CM people in the source area have been watching, waiting on the sidelines.

LM: there's not a good link from the goals document to the complexity of the result. Let's really scope out the constituencies we're trying to include. THEN create a model document, without resolving to the level of method and prop names. (Editor's Note: we have done this. There is a model document available from the WebDAV home page. Due to a number of technical reasons, this document has not been published to IETF.)

Geoff: wait, we emphasized goals 2 meetings ago, then model last time; so it's unfortunate that we didn't go back over that here.

Keith: at this point we need to find out new constituencies, but the prior art shouldn't restrict the new community.

People interested must send mail to the Area Directors once they've reviewed the charters.

ACTION item: put Patrik and Keith in contact with DMA, ensure that we're not stepping on toes.

Lisa Lippert: we need to see new voices, yes. I expect other communities to provide their own models.

Keith wants to see work promises as ADs. Mail to individuals. Must go directly to him.

Need to submit some form of the model document as an internet draft.

Geoff: "we've got bus loads of CM guys in our company :-)