Notes on the 3/8/99 Dav-Versioning Conference Call

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 9 Mar 1999 10:14:31 -0500 

Date: Tue, 9 Mar 1999 10:14:31 -0500
Message-Id: <9903091514.AA11819@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: Notes on the 3/8/99 Dav-Versioning Conference Call


Participating:
Jim Amsden,Geoff Clemm,David Durand,Chris Kaler,Bradley Sergeant

Topic: Administrivia about Minneapolis versioning presentations
  <no notes taken>

Topic: URN's for versioned resources

Jim and Geoff presented a few key use cases were presented that
required the use of "locatable URN's".  In particular:

   - Reliable Configurations

   A configuration is an immutable snapshot of a subtree of a website.
   The concept of a configuration must co-exist with the need to allow
   clients to modify the binding of a "user URL" to a new resource via
   a MOVE.

   This could be achieved by requiring that the server assign a
   "locatable URN" to each versioned resource, independent
   of the "user URL" that is subject to a MOVE.
   A configuration would be defined in terms of a set of "locatable URN"s,

   - Merging Configurations

   In order to reliably merge configurations, it is essential to know
   whether two different revisions of the "same" versioned resource
   appear in the two configurations, since this implies a "merge" of
   those revisions is needed.  The "user URL"s of the two revisions are
   not sufficient, because one or more MOVE's could have renamed the
   revisions.  This could be achieved by providing a "VR-URN" property of
   a revision, containing the "locatable URN" for that revision's versioned
   resource.  The versioned resource must be "locatable" because the
   revision history must be accessible in order to support the merge
   process (e.g. finding the nearest common ancestor revision).

   - Non-local Workspaces

   Many versioning systems maintain a workspace on a host separate from
   where the versioning resources are stored (e.g. on the client or on a
   different web-server).  To support this, a server must provide some way
   of reliably referencing a particular versioned-resource.  A locatable
   URN would support this requirement.

Dave pointed out that a "locatable URN" is currently at best a
"work-in-progress".

Brad pointed out that a URN wrt some identified "repository" resource
is feasible, and is what is actually supported today by versioning and
document management systems.

Geoff agreed with both of these points, and volunteered to write up
a proposal that addresses these use cases with a "repository resource"
instead of a "locatable URN".