Re: Revision identifier and revisions label namespaces

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 6 Oct 1999 08:47:51 -0400 

Date: Wed, 6 Oct 1999 08:47:51 -0400
Message-Id: <9910061247.AA14705@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <002d01bf0fc3$2975f960$0100007f@conclave> (infonuovo@email.com)
Subject: Re: Revision identifier and revisions label namespaces

   Sender: "Dennis E. Hamilton" <orcmid@email.msn.com>

   2. A user-meaningful revision-label is valuable for carrying
   application-relevant, human-useful labels that fit someone's notion of
   revision identification.

   With regard to interoperability, (2) requires additional agreement if a
   revision-creating client is to honor the scheme expected by other users of
   the server.  Rather than leave the revision-label underspecified, it might
   be prudent not to specify it, so there is no presumption of interoperability
   or a priori agreement when there is none.

   [I may be using a different sense of interoperability than <gmc>.  I haven't
   considered products being from the same vendor as providing any assurance of
   interoperability in live application settings.  I'm willing to look for a
   better term for what I have in mind, namely multiple parties being able to
   achieve a valid cooperative result without being in communication.]

This is a very important aspect of the protocol, but I'd prefer to use
some other term, like "collaboration support" for it, since we've
been using the term "interoperability" to refer to support for multiple
clients from different vendors being able to work with multiple servers
from different vendors.

WRT to labels, I agree that they are rather weak in their support for
collaboration, because of the likelihood of name collisions between
different clients.  Clients concerned with collaboration should use
configurations and deep revisions rather than labeling a set of
revisions, since you can create a configuration containing those
revisions with no risk of name collisions.

Cheers,
Geoff