Re: Revision identifier and revisions label namespaces

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 6 Oct 1999 01:35:57 -0400 

Date: Wed, 6 Oct 1999 01:35:57 -0400
Message-Id: <9910060535.AA14515@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <001501bf0f97$3de724e0$0100007f@conclave> (infonuovo@email.com)
Subject: Re: Revision identifier and revisions label namespaces


   From: <infonuovo@email.com>

   <deh>
   I agree with this.
   It makes no sense to have an user-meaningful label and a system-assigned
   unique identifier have anything to do with each other.  One is for the
   internal integrity of the implementation and preservation of the model.  The
   other is for what people or clients agree to use.

<gmc/> Just to confirm, the position you agree with is that they should
be in separate namespaces?

   It is also valuable to have both notions, though I don't know how you
   propose to have interoperability of the user-meaningful one.
   </deh>

<gmc/> Interoperability between an arbitrary client and an arbitrary
server is probably straightforward (you define the legal set of
strings that can be used as "labels", and define ways to set and
retrieve them).  Making sure that one client creates labels in a way
that is usable by a different client is a separate issue, but not
really one of interoperability, since this issue arises even when you
only use the client and server of a single manufacturer.  Or did you
have some other interoperability issue in mind here?

Cheers,
Geoff


   -----Original Message-----
   From: ietf-dav-versioning-request@w3.org
   [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
   jamsden@us.ibm.com
   Subject: Re: Revision identifier and revisions label namespaces

   <gmc/> If we put labels and identifiers in the same namespace, how do
   we answer a client that complains that it has to know the server
   dependent conventions for generating revision-id's before it can
   safely chose a label?  What is the server benefit that would lead us
   to place such a burden on clients?

   <jra>
   If they're in separate namespaces, the client has the same burden. He still
   has
   to know which one is which and provide the proper indicator. The only way
   this
   can be avoided is if there are methods in which only one or the other (id or
   label) is valid. Then the client still has to know which to use. This was
   the
   reason for using one label namespace called revision names, and indicate
   there
   were two types: server generated and user generated. It shouldn't be too
   hard to
   keep these spaces separate, and collisions are easy to handle. The server
   will
   simply refuse to add the label to the revision and the user will pick
   something
   else. This is the same thing that would happen if the revision already had
   that
   label for any other reason. Nothing has to be remembered when the label is
   used
   in a target selector. All in all, I think this is easier for clients, not
   additional burden.
   </jra>