Oslo WebDAV Versioning BOF
jamsden@us.ibm.com
Thu, 22 Jul 1999 12:04:35 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852567B6.00583930.00@d54mta03.raleigh.ibm.com>
Date: Thu, 22 Jul 1999 12:04:35 -0400
Subject: Oslo WebDAV Versioning BOF
The following are the Oslo DELTA-V BOF Meeting Notes. I (Jim Amsden,
jamsden@us.ibm.com) have made some attempt to make the notes more readable, and
to answer questions that were raised, but not addressed. If I have misunderstood
any of the questions of comments, let me know and I'll send out some updates.
July 14 1999
IAB rep: John Klensin present.
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: 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: 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.
RK: let's power through and do the charter
6 hands up -- but all were in WebDAV
JK: I'm trying to avoid two overlapping WGs. Keith: wait, I did tell Jim to wind
down WebDAV and substitute this instead.
LM: 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.
LM: e.g. distributed configuration management systems, beyond document authoring
to software release management.
5PM
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.
JK: 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.
RK 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: 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: 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 :-)