Re: Revision identifier and revisions label namespaces
jamsden@us.ibm.com
Tue, 5 Oct 1999 17:05:38 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256801.00741E7F.00@d54mta03.raleigh.ibm.com>
Date: Tue, 5 Oct 1999 17:05:38 -0400
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>