The Delta-V Working Group held its first meeting November 9, 1999 at the
Washington, DC IETF. The meeting covered the proposed extensions to WebDAV
to support versioning, activities and parallel development, and
configuration management. The following are the notes from the meeting.

Chair: Jim Amsden
Notetakers: Jim Whitehead, Pete Carlson

Meeting begins with a review by Jim Amsden of the meeting agenda, including
some scoping of the desired discussion for today's session. The approach
taken was to walk through the protocol by showing how the scenarios from
the goals document would be communicated to a WebDAV versioning server. The
purpose was to review the goals and semantics through the scenarios, sketch
how the scenarios are supported by the protocol, and raise any issues. We
intentionally did not cover
- clients that maintain their own workspace
- local and disconnected modes (master mode only)
- dynamic resources
- locking pending resolution of locking semantics on unversioned resources
- leveling or optional features. This will come later after we have a
complete understanding of the full versioning semantics.

First item is a versioning scenario. (The notes from the overheads are
included below). In the scenario, want to:

- create a resource
- update it
- make it a versioned resource
- track its history while making some revisions

Geoff Clemm then presented how the protocol would address this scenario:

- create a resource

PUT /a/x.html
  "some text"

PUT /a/x.html
  "some more text"

{Creates the resource, then updates it once, but it currently isn't under
version control.}

At this point in time, there is:

resource: /a/x.html
  creation date: 11/9/1999  1:25PM
  "some more text"

VERSION /a/x.html
This puts the resource under version control

PROPFIND /a/x.html

resource now has a new property (versioned-resource):

resource: /a/x.html
  creation date: 11/9/1999  1:25PM
  versioned-resource: {some URL "zz157"}  <-- the URL where you can
retrieve the entire versioned resource
  "some more text"

Need to create a workspace to isolate your changes from those of other
collaborators.

MKRESOURCE /workspaces/geoff_dev
  current-label: geoff_dev_lbl
  revision selection rule:
              <label>geoff_dev_lbl
              </label>

This creates a new workspace, where items are assigned the label
"geoff_dev_lbl" and the revision selection rule always picks out the
revision where the label is "geoff_dev_lbl".

--> /workspaces/ was previously created, and established as the place
people store their workspaces.

CHECKOUT /a/x.html
Target-selector: workspace /workspace/geoff_dev

Chris Kaler noted that this checkout will fail, because as of this point,
no label has been set on /a/x.html (wasn't done by VERSION, or by GET).
This leads to some discussion on how to resolve the problem. Two choices,
either have VERSION set a initial label, or can change the revision
selection rule.  Geoff proposed to modify the revision selection rule.
Kevin Wiggen noted that the MKRESOURCE didn't specify that it's creating a
workspace resource.  So, MKRESOURCE now looks like:

MKRESOURCE /workspaces/geoff_dev
  resource-type: workspace
  current-label: geoff_dev_lbl
  revision selection rule:
              <label>geoff_dev_lbl
              </label>
              <latest/> <or/>

What does "zz157" (the URL of the versioned resource) look like?

/zz157:
  resource-type: versioned-resource
  revisions: /zz157/revisions

Issue: what is inside the "revisions" tag.  Is it a collection, or a
report?  This has not yet been resolved. (Note: this issue was discussed
and resolved in the breakout session the following day. See the meeting
notes for details.)

Working on the assumption it is a collection:

  /zz157/revisions

Further assuming the server names its revisions as "r{version id}", then
the versioned resource now has:

 /zz157/revisions/r1  <-- this is the stable, reliable name of the
revision.  A GET on this returns revision 1 of /a/x.html

There is also a collection for labeled revisions:

 /zz157/labeled_revisions/

At present, since no label has been assigned, this is empty.  Return back
to editing.

So, do a PUT to write into the currently checked-out working resource at
/a/x.html.  The working resource is part of the workspace, that is, it
lives in /workspaces/geoff_dev/...

PUT /a/x.html
   "final text"
  Target-selector: workspace /workspace/geoff_dev

Then, check it in:

CHECKIN /a/x.html
  Target-selector: workspace /workspace/geoff_dev

The act of checking in the resource sets the label on that revision
(revision 2).  Going back to zz157, there are now the following resources
in /zz157/revisions:

/zz157/revisions/r1
  "some more text"

/zz157/revisions/r2
  "final text"

Also, in  /zz157/labeled_revisions/, there is:

 /zz157/labeled_revisions/geoff_dev_lbl

This is the same resource as /zz157/revisions/r2.

A question was raised about the use of labels.  Are they used to track each
user?  Chris Kaler: no, it's more tracking a line of work.  Q: So, your
exploiting a side effect of labels here. GC: yes.

Some back and forth on how labels are used, and their role, especially in
keeping clients separate.

Question about what a label really is.  Geoff answered by giving details on
exactly how the label is expressed:

labels: <label>geoff_dev</label>
            <label>stable</label>

Geoff emphasized that you can have multiple labels set on a resource.  More
discussion on uses of labels. Labels are not particularly good for audits.

Q: Can the same label be used across multiple resources? A: yes,
definitely.

This ends the first scenario.  Now, move on to a scenario involving
parallel development.  Build on the end state of the first scenario:

User Jim checks out a revision of /a/x.html with label geoff_dev_lbl

User Geoff checks out a revision of /a/x.html with label geoff_dev_lbl

Need a new workspace for Jim:

MKRESOURCE /workspaces/jim_dev
  resource-type: workspace
  current-label: jim_dev_lbl
  revision-selection-rule: <label>jim_dev_lbl</label>
                                          <label>geoff_dev_lbl</label>
<or/>
                                          <latest/> </or>

CHECKOUT /a/x.html
 Target-selector: workspace /workspaces/jim_dev

But, immediately after this, the server sees:

CHECKOUT /a/x.html
 Target-selector: workspace /workspaces/geoff_dev

After both checkouts,  /zz157/revisions/r2 looks like:

/zz157/revisions/r2
  "final text"

labels <label>geoff_dev_lbl</label>
           <label>stable</label>

workspaces: /workspaces/jim_dev/
                      /workspaces/geoff_dev/

As each person checks in, the items in workspaces go away, and revisions
are added to the successors list:

successors: /zz157/revisions/r3
                 /zz157/revisions/r4

Now, we want to:
- retrieve the history listing (list predecessors and successors)
- add/remove labels

At present, to make a history listing, need to go to the versioned resource
and retrieve the URL of its revision collection, and then do a PROPFIND
with Depth to retrieve the predecessor and successor relationships off each
individual resource. Could potentially have an optimization to PROPFIND to
handle the first two retrievals.  Also have the option to do a REPORT
method invocation (handles actions that require a lot of computation on the
server), with one report being a history listing.  Could also have a
property on the versioned resource that contains the history listing.

Setting a label:

One option is to go into the labeled revisions collection:

/zz157/labeled-revisions/

to add a label called "default":

BIND /zz157/revision/r2
Destination: /zz157/labeled-revisions/default

to change it:

BIND /zz157/revision/r4
Destination: /zz157/labeled-revisions/default

Alternately, could use a "LABEL" method:

LABEL /a/x.html
Label-name: default

Lisa Lippert: For simple clients, needing to understand BIND functionality
may be too much, and labels may be too complex.

GC: Could be quite simple, a client could just think of the BIND as a
"recipe" that they just execute.

LL: If it's so simple, why can't they just do a PROPPATCH?

GC: Could use PROPPATCH {explained a scenario of how to do this}.  One
drawback of this approach is if there are a large number of labels on a
revision, then doing a PROPFIND to retrieve this large set of properties,
followed by a PROPPATCH after making a minor modification, could be
inefficient.

JH: Every time you have a list of items that needs to be changed, you run
into the lost update problem where a modification could be made between
PROPFIND and PROPPATCH.

A (many): Yes, this is the case.

Lisa Lippert: Multi-valued properties, in many cases, would be useful if
you could add or remove elements from the list.  This will be very useful
in ACLs, since it'll be useful to add/remove access items, especially if
you can't read the items.  I'd be happy to work with other people on this.

GC: I'd like to see this too, I certainly like this much better than having
a separate method to add/remove list items for each type of list.

Jim W: Is the BIND side-effect to create a label the only reason why labels
are exposed through the namespace?

GC: No, the main reason is to have a stable URL for "label X of revision R"
to avoid having to create a (revision, label) pair syntax.

Jim Amsden: To finish up, let's request from the WG members their
perceptions of the protocol.

Lisa Lippert: I'm concerned about the complexity of the protocol for simple
authoring clients.  Checkin/checkout, and retrieving a history list have to
be really simple.

Yaron Goland: Need to have a document that explains choices, paths not
taken, etc. Design rationale.

GC: Agreed -- weren't you going to write this?

Q: Need to list required metadata fields in the specification.

*** Meeting Adjourned ***


Scenario1:

- create a resource
- update it
- make it a versioned resource
- make some revisions

PUT /a/x.html
"some text"

PUT /a/x.html
"some more text"

VERSION /a/x.html

GET /a/x.html
=>
"some more text"

MKRESOURCE /workspaces/geoff_dev
  resource_type: workspace-resource-type
  current-label: geoff_dev_lbl
  revision-selection-rule:
   <or> <label> geoff_dev_lbl </label>
        <rsr-latest/>
   </or>

CHECKOUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev

PUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
"final text"

CHECKIN /a/x.html
Target-Selector workspace /workspaces/geoff_dev


Scenario 2:

Jim checks out and updates /a/x.html
Geoff checks out and updates /a/x.html
Geoff checks in /a/x.html
Jim checks in /a/x.html

MKRESOURCE /workspaces/jim_dev
  resource_type: workspace-resource-type
  current-label: jim_dev_lbl
  revision-selection-rule:
   <or> <label> jim_dev_lbl </label>
        <rsr-latest/>
   </or>

CHECKOUT /a/x.html
Target-Selector workspace /workspaces/jim_dev

PUT /a/x.html
Target-Selector workspace /workspaces/jim_dev
"Jim's text"

CHECKOUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev

PUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
"Jim's text"

CHECKIN /a/x.html
Target-Selector workspace /workspaces/geoff_dev

CHECKIN /a/x.html
Target-Selector workspace /workspaces/jim_dev


Scenario 3:

List revisions of /a/x.html
List labeled revisions for /a/x.html
Label revision r1 as "default"
Look at revision r1

PROPFIND /a/x.html
  versioned-resource
=>
versioned-resource: /zz157

PROPFIND /zz157
  revisions
  labeled-revions
=>
revisions: /zz157/revisions
labeled-revisions: /zz157/labeled-revisions

PROPFIND /zz157/revisions
Depth: Infinity
=>
<href> /zz157/revisions/r1 </href>
<href> /zz157/revisions/r2 </href>
<href> /zz157/revisions/r3 </href>

PROPFIND /zz157/labeled-revisions
Depth: Infinity
=>
<href> /zz157/revisions/geoff_dev_lbl </href>
<href> /zz157/revisions/jim_dev_lbl </href>

BIND /zz157/revisions/r1
Destination /zz157/labeled-revisions/default

GET /zz157/revisions/r1
=>
"final text"

PROPFIND /zz157/revisions/r1
  labels
  successors
=>
<labels> <label> default </default> </labels>
<successors> <href> /zz157/revisions/r2 </href>
             <href> /zz157/revisions/r3 </href> </successors>