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

Jim,

Please stop using HTML for your emails. Heck, use a better email package
(your emails have looked wonky for a long time).

See below for the problem with using HTML. There is *NO* separator between
your message and the message you quoted. There isn't anything that says the
quoted email was from Geoff. Quite impossible to read/parse/whatever.

I believe netiquette generally says to use plain text for mailing lists. Not
everybody out there has HTML-capable readers.

Cheers,
-g

On Tue, Apr 17, 2001 at 07:48:13AM -0400, Jim Amsden wrote:
> 
>    OK with me.
>    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

-- 
Greg Stein, http://www.lyra.org/

Received on Tuesday, 17 April 2001 19:21:26 UTC