Delta-V Design Group Meeting
IETF San Diego

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

Attendees:
   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.  The 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 resources.  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 workspaces.

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

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 history.

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.


Set and agreed on agenda:
 1.   Review changes that have been made to the protocol document since the last submission.
 2.   Review items raised by Yaron Goland conveyed by Geoff.
 3.   Review changes raised by Greg Stein (working collections, checkout in a baseline).
 4.   Help define the criteria for setting levelling.
 5.   Discuss the use of XML and DTD's/XML schema.
 6.   Ordering of set properties (e.g., successors, ...)
 7.   Why are change sets and branching are both modelled by activities?
 8.   Use of labels vs. baselines for configurations.

The group went through the list of changes since the last Internet draft
(section 21)

"Moved version-controlled resource DAV:predecessor-set property to core.(Boris)"
Reviewed and agreed.

"Made label support optional. (Lisa)"
Debated why labels should not be in core -- primarily because it is not required by document management systems, and it is not viable in distributed disconnected implementations.  Agreed that it should not be in core.

"Removed Workspace header (Geoff)"
Discussed why the workspace header is problematic.  The problem is illustrated by the use of absolute URLs embedded in documents (i.e., links).  When resources are in workspaces it is usual that the absolute URL should be interpreted relative to the workspace.  The workspace header was proposed to provide a prefix for all URLs in the request.  However, not all URLs should be interpreted relative to the workspace.  For example, version URLs would not be interpreted relative to the workspace.  The server has no way of knowing when a URL is workspace relative, and when it is root relative.  It was proposed that the server should be able to recognise a URL as a server generated URL and thereby not interpret it workspace relative (not apply the workspace header),  however, it was agreed that we cannot dictate that the server allocate a fixed part of the namespace for version URLs.
It was recognised that this means that server side includes will not work.

"Added DAV:must-not-be-checked-out precondition for LABEL (John)"
Agreed.

"Only require Multi-Status if there was an error in a Depth operation (e.g. LABEL and SET-TARGET). (John)"  Briefly discussed using multi-status only if there was >1 error.  This idea was abandoned and the original update was agreed upon.

"Got rid of "parent workspace" for MKWORKSPACE (Tim/Geoff)"
Agreed.

"Added DAV:no-checkout argument to MERGE (Tim)"
Agreed.

"Fixed BASELINE-CONTROL so that baseline (not baseline history) is the argument (Tim)
Disallowed checkout of a baseline (only makes sense for a baseline-selector) (Tim)
Added CHECKIN behavior for a baseline-selector (Tim)
Added DAV:baseline-controlled-collection property for baseline-selectors (Geoff)"
The proceeding four updates are deferred to a later discussion on baselines in general.

"Changed "advanced" to "optional", since that is what it means (Geoff)" Some discussion that 'advanced' sounds sexier for marketing reasons, but that 'optional' was more accurate.  Agreed that we should adopt 'optional' but think of ways to entice people to implement it.

"Changed the DAV:repository-report into DAV:workspace-collection-set and DAV:activity-collection-set properties. (Ross)"  In as much as this represents splitting the repository report into separate queries for workspace collections and activity collections, this was agreed, but this is likely subsumed by a later suggestion for making this information available through OPTIONS.

"Marked the DAV:supported-xxx properties as "protected". (JimW)"
This is also in OPTIONS and subsumed by a later recommendation.

"Cleaned up bad ANY syntax for the DTD's. (Geoff)"
Agreed.

"Use strings in DAV:method elements to define DAV:supported-methods. (Juergen)"
Agreed.

"Removed DAV:if-unsupported (use If header when needed) (Yaron)."The protocol doesn't rely on this behaviour, however, it is considered to be useful (if people ever need it).

"Moved the DAV:workspace property from version-controlled resources to any resource, since resources other than version-controlled resources can be in a workspace (Tim)." Agreed.

"Changed the return status of VERSION-CONTROL on an existing resource to be 200 (Greg)." Agreed

"Added the impact of DELETE on properties that refer to the deleted resource (Greg)." Agreed that any references to the deleted resource should be removed from DAV properties.

It was pointed out that for all computed properties (e.g., 'successor set' defined as the list of resources who have this resource as a predecessor) the protocol document should mention that any method that affects the resources it is computed from affects the value of the property.

"Changed the DTD of all top level request and response nodes to be ANY (Yaron)."
Defer to a later XML discussion.

"Have version CHECKOUT example use version URL (Chuck)."
Agreed

"Renamed version selector to be version-controlled resource (Geoff)."
Agreed.

"Renamed Target-Selector header to be Label header (Geoff)."Agreed, and that there would be other headers created if required (i.e. baseline:, activity:...).

"Divided optional section into one section per option (Juergen)."
The group liked the idea of splitting the document, however, should the optional behaviour document duplicate the information contained in core (so that it is a stand-alone document) or should it reference the core document?  Agreed to ask the mailing list since there was no consensus reached.

Agreed that we need to add some model description, esp. illustrating the use of client-based vs. server-based workspaces.  Will add a section at the end of the document that brings the concepts together, with a forward reference to this section since some people may prefer to read this section before the terms etc. are introduced.

Various changes to the document were discussed:

2.1.4 Auto-versioning
It was noted that non-versioning clients may receive errors related to versioning operations, however, since we are not introducing new status codes, the clients will understand the status code as an error, but they won't understand the extended status XML body.

2.2 Common property values
Some of these are duplications of RFC2518 and some are new/modified definitions.
Agreed that this duplication was ok.

Discussed that fact that version controlled resources (VCRs) have different properties depending upon whether they are checked in / checked out.  Suggested having a DAV:is-checked-in (Boolean) property and reusing the DAV:target property.  Some people felt strongly that individual properties (e.g., DAV:target) should not have different meanings depending upon resource state.  Agreed to leave it alone.

Discussion of DAV:predecessor-set : why it cannot be used to denote the checked out version (e.g., by putting the checked out version URL as the first in the list).  Clients can modify the DAV:predecessor-set because it represents the logical successor not the checked out resource.  Clients may remove the checked out version URL from the predecessor set and add other URLs (from the same version history).  An example of where this is useful is a server that only supports linear history, and clients have branched by checking out the same version.  The second client to checkin can do a merge (with the first to checkin) and fix-up the predecessor set to maintain linear history.

2.4.3 predecessor set should have a DTD fragment to be consistent with other definitions.

DAV:version-name property is generally useful for clients, but is not used in the protocol.  It is envisaged that it would be used in a PROPFIND type request rather than used to 'directly' access the resource (such as with a VersionName: header).

The overwrite header description may need rewriting to improve its clarity -- Jim A. agreed to draft a rewrite.

The body of section 2.8 OPTIONS should explain what the request body is used for.  Correct "If a request body is included, it MUST be a DAV:options-response XML element." to read "if a response body ...".

2.8 supported live properties.  Would like to modify the XML to allow passing metadata about the property (e.g., type, whether protected, etc.) by adding another level of element <DAV:property-name> around the existing name data.  Agreed.

2.10 PROPPATCH semantics
It was recognised that a versioning aware client may set versioning properties on a non-versioning server, and the server would accept the properties (as dead properties).  It behoves clients to check the capabilities of a server (using OPTIONS).

DELETE vs. UNCHECKOUT
For a version controlled resource(VCR) DELETE means 'go away' whereas UNCHECKOUT means 'revert to checked-in (version) state'; for a working resource DELETE means 'go away' and there is no equivalent for revert to checked in state.

2.12 COPY semantics needs similar semantics description to PUT & PROPPATCH where the destination is a VCR.  (No such change to be made to 2.13).

2.14 REPORT method -- why not just use POST?  REPORT is defined to have read-only semantics and so is more likely to be acceptable to proxies/servers who have security concerns.  In addition it does not require extending/redefining the semantics of POST.

2.16 postconditions of CHECKOUT does not describe the effect on the checked out set (this is another example of a 'inverse property' that is defined as a function of other properties) the effect should be called out explicitly.  Editorial change: now that the document is split there is no need to say "If a version-controlled resource was checked out ...".

2.18 UNCHECKOUT also requires the effect on the checkout-set.

2.20 version tree report also should remove "If the report is applied to a checked-in version-controlled resource ..."

XML DTD -- we will create a valid DTD for delta-v, and we will strive to get rid of the ANYs (retaining them in places where extensibility is explicitly predicted).  We need to allow servers to add proprietary extensions to the XML.  Recognised that a DTD is a poor-man's solution, and that an XML schema would be more meaningful and extendable and would allow clients and servers to validate messages.  Could be added to an appendix, but we won't hold up the progress of the document waiting for this.

Ordering of successor list / version tree report
Agreed that there is no need for the server to assure any ordering or repeatability of ordering across subsequent request/responses; it is left to the client to applying any temporal ordering if this is required.

Brief discussion of activities.  They are used for branching and change sets by clients, and are indistinguishable as resource on the server.  Activities can be used to model either--interoperably.

Meeting closed at 3:00pm.