M I N U T E S

IETF Delta-V BOF Meeting

IETF-45, Oslo, Norway
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 led 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.

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.

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.

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.

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.