The Label header, and other issues raised since draft-14

I believe it is fair to say that based on activity in the mailing
list, there appears to be strong support for the Label header within
the working group.

As for the issues raised concerning the Label header:

- Internationalizable display of labels:

This actually has little to do with the label header, since you don't
use the label header to create labels, but rather use the body of the
LABEL method.  In the body of LABEL method, you can annotate the label
with as many internationalization attributes as it wishes, and you
query for labels with PROPFIND, which will give you all those
attributes back.

- Label matching

Here is the area where the Label header does come into play, because
it is the way several methods will pass in the label to be "matched".
My impression is that most of the members of the working group that
care about labels find a simple byte string matching of the label to
be sufficient for their needs.  It is OK for an Englishman to label a
version "gross", and then have this version be selected by a German
that asks for the "large" version (i.e.  "gross" in German, put please
don't get too concerned about the details of this example :-).

This is no more likely to happen than for some other client to use the
word "gross" in English to mean something other than what the second
client had in mind.  In fact, it is probably much *more* likely for
the two different English uses of a string to collide, than it is for
an English use to collide with a German use.

Clients that really care about his issue will just use baselines
instead of labels, since a baseline selection of a version can never
"collide" with another baseline (which is why I think we should just
get rid of the label feature altogether, but that's just me :-).

So if we accept all that, the only thing left to do is to decide which
packages (if any) will contain the label header.  After staring at
our current packages (core, basic/advanced client workspaces, and
basic/advanced servers workspaces), I believe it makes sense to bundle
labels into the "client workspace" packages.

My reasoning is as follows: I believe most client-workspace servers do
in fact support labels, and Greg (who is known to be producing an
advanced-client-workspace server) was one of the vocal supporters of
labels.  This makes sense, because although a server-workspace server
can just allocate a "workspace" when it wants to expose a set of
related versions, a basic client workspace server cannot, and labels
give it a simple way to do so.

So, I propose that we define the label feature as being part of the
basic-client-workspace package.  Any objections?

This means that the proposed resolution of the issues raised since 
draft 14 are:

The Variant-Control Feature:
   Defer it to another spec. focused on variants.

The Fork-Control Feature:
   Merge it into the checkout feature.

The Update Feature:
   Keep it, and make it part of the basic-client-workspace package
   (needed so that a new version created by checking in a working
   resource can be made the "checked-in" version of its version
   controlled resource).

The Label Feature:
   Keep it as is (i.e. with the Label header), and make it part of the
   basic-client-workspace package (so that a client can define a
   lightweight configuration of versions on the server).

The "checked-out version-controlled configuration" issue:
   Add a "checkout-on-update-and-keep-checked-out" variant to the
   auto-versioning mechanism.  Also, simplify DAV:auto-version
   by replacing it with DAV:auto-checkout and DAV:auto-checkin.

Packages:
   Define 5 packages: core-versioning, basic/advanced-client-workspace,
   and basic/advanced-server-workspace.

In other words, the mailing list accepted 3 of the proposals from
the Minneapolis meeting, rejected 2 of the proposals from the
Minneapolis meeting, and accept the latest variant of the one 
issue that originated on the mailing list (auto-checkout of a VCC).

Does anyone disagree/object to the resolutions described here?
If not, I'll write this up as draft-15, and submit it to the IETF
so that JimA can officially submit it to Ned for the next step
of the process.

Cheers,
Geoff

Received on Tuesday, 17 April 2001 00:07:55 UTC