W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Minutes Delta-V breakout meeting 14-Dec-00

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 15 Dec 2000 16:03:50 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569B6.0058EDDE.00@d06mta07.portsmouth.uk.ibm.com>

Delta-V Design Group Meeting
IETF San Diego

9:00 am - 3:00 pm
Wednesday 14 December 2000

    Jim Amsden (IBM Raleigh)
    Geoff Clemm (Rational Software)
    Tim Ellison (IBM UK)
    Mark Hale (Interwoven)
    James Hunt (Universitšt Karlsruhe / FZI)
    Eric Sedlar (Oracle)

[Note: section references are based on draft-ietf-deltav-versioning-10.9]

Discussion of core behaviour of LOCKing an auto-versioned resource followed
by PUTs, PROPPATCHes and UNLOCK.  Agreed that the proposed behaviour of PUT
to a LOCKed auto-versioned resource should be to checkout the resource and
update its contents without checking it back in.  Subsequent PUTs and
PROPPATCHes would update the same (mutable) working resource.  Thw working
resource would be checked in when the resource was UNLOCKed.

Discussed ways of working with client side workspaces.
One model is that clients acquire locks across all resources that they want
to update, sends updates, then releases all the locks.  This is inherently
pessimistic, and isn't going to scale to updating large numbers of
Another model is to use GET and PROPFIND to copy resources over to the
client machine.  Clearly clients must be stateful to maintain the resources
and any subsequent changes to the resources made by the client.  (Clients
may check with the server to ensure that the changes are still
non-conflicting by considering the current server state.)  When time comes
to make changes on the server the client checks out the versions, issues
PUT and PROPPATCH to update the working resource on the server and CHECKIN
the working resource.  Note that working resources are required since there
is no single method for setting properties and content simultaneously.
Some servers may have a batch capability to atomically check in numerous
resources atomically.

In both models for client side workspaces, servers are required to provise
working resources, however, in server side workspaces clients simply use

It was noted that we now have multiple ways of checking out a resource,
LOCK+autoversion, CHECKOUT a version controlled resource, & CHECKOUT a

Mutable versions can be suppurted by allowing clients that have a lock on a
version resource to update the contents and properties in place.

Advantage of this LOCK/UNLOCK behaviour is that dav level two clients can
now create new versions without needing new methods (they still require a
versioning client to VERSION-CONTROL to resource initially) and without all
intermediate states of their PUTs and PROPPATCHes being recorded in version

Should clarify in the spec. that 'Overwrite : T' means update in place
(thereby ignoring the RFC2518 semantics that call for an initial DELETE of
the destination).  Remove the 'Overwrite: update' option.

Should require that the error response for new methods contains an XML body
as defined in the spec. (for advanced error reporting) unless it has been
otherwise negotiated (via header(s) to be defined).  For existing methods
we probably have to adopt the existing error conditions (and advanced error
reporting may have to opt-in).

Agenda item: should consider moving SET-TARGET out of core.

Discussion of versioned resource vs. a version controlled resource (vcr)
and why we need to distinguish between resources that can be modified and
resources that cannot be modified in a LOCK-PUT-UNLOCK sequence (excepting
mutable versions).  This is a candidate for the delta-v book of why.

Suggested that we specify that allprop requests do not return any delta-v
properties -- rejected since it does not solve the allprop problem.

Discussed checking out in the context of a baseline.
Create a baseline resource, can then checkout a resource specifying a
baseline in the CHECKOUT body (i.e., the baseline 'contains' a working
resource/collection).  All the members MUST be checked in before the
baseline can be checked in.  Add a DAV:checked-out property to return the
working resources in the baseline.

Consider introducing a DAV:sub-baseline property?

Geoff will write up the semantics of checkig out against a baseline and
post it to the list for general comments.

Discussed versionig whole respositories --  a single baseline is created
that represents the entire state of all resources.  The state of the
repository is captured in the baseline history.

Suggested that there be no branching in core, no labels in core, but that
there should be a version history available in core.

Should separate the 'label' option from the client managed workspace
option.  I becomes its own option.

How about a header to get the latest version in an activity?
Suggest a REPORT against a version history to ask for the latest verswion
in a given activity, the response includes a version URL (noted that you
can issue depth requests if the target is a collection).

Post conditions may be better expressed as (inverse) pre-conditions in some
cases.  In any case should add extended status error tags to postconditions
to allow the server to illustrate that the post condition could not be met.

6.1.1 Grammar href+ becomes href*

6.11 <DAV:activity-must-exist/> precondition should be added.

Discussion of labels and baselines.

Discussion of defining a DAV:is-branch property on an activity to advise a
client whether the activity represents a branch or change set.  The
property would have no impact on the server behaviour.  Alternative
suggestion was to define a DAV:is-change-set property that would require
the server to enfore there was only one version per history per activity.
Howevr, it was noted that this would require a means for setting the
property when the activity is created (defining a body to initialize
properties during MKACTIVITY?)

James H. agreed to write up his semantics differences between a chane set
and a branch (both being sets of resources) and why it would be useful for
servers to distinguish them.  James to post this to the list.

Should check through the protocol document and identify which live
properties should be protected by a write lock.

Set the agenda for the delta-v working group meeting.

Meeting closed at 3:00pm.
Received on Friday, 15 December 2000 11:12:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC