After thinking about this problem some more, and having a discussion with Geoff, I think we may have a real problem here. Labels were introduced to provide a Human meaningful way to distinguish one version of a versioned resource from another. Its the meaningful part that's troubling. In your example, we have two "words" that in some languages mean the same thing. We can easily ignore this issue and just say you have to pick one for the label and use it, or even label the version with both. Its when a single word has entirely different meanings in different languages that creates a problem. Say you have a label encoded in UTF. Certainly the server can match a label given in a label header that is also UTF encoded with the label on the resource. We're not trying to sort by labels, translate labels, or anything else, just exact match. But is this meaningful to two different Humans? If the encoded string represents a word that can have! ! different meanings in different languages, then it might be quite misleading. I'm not saying this is a common problem, or something that doesn't already exist in HTTP URLs. But maybe its something we don't want to have to deal with if we can avoid it.

Perhaps we could get some clarification from the Application area directors if this is something we need to address or not?  I'd prefer to leave the label header in the spec as it semms that selecting a version by label is simple and reasonable functionality that is common practice, and has been in the spec for quite some time. However if it leads down unnecessary rat-holes, I could be convinced to delete it. Ned? Patrik?



                  "
Take the word 'schon' in German, which can also be spelled
'schoen'.  There is a convention that specifies that umlauts can
be replaced by a following "e" and still be the same word.  It is
not the case that binary comparisons can be done even for equality
for natural language strings.

However, your point is still valid--I thought the reasons to get
rid of the Label header were:

* make label just a property and remove an option, simplifying
 the client testing problem
* shorten the spec
* nobody at the working group cared that much about the header
* avoid the language pain in the a** with respect to internationalizing
                the header

The language issue isn't sufficient by itself.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Greg Stein
> Sent: Tuesday, April 10, 2001 4:20 AM
> To: 'ietf-dav-versioning@w3.org'
> Subject: label header (was: Re: Versioning TeleConf Agenda, 4/6/01
> (Friday) 12-1pm EST)
>
>
> On Sun, Apr 08, 2001 at 12:04:06AM -0400, Clemm, Geoff wrote:
> >...
> >    - defer label header, but keep LABEL method
> >
> > Example of reason why you don't want human meaningful strings in a
> > header:  The Label value needs to be matched against values stored
> > on the server.  For some languages, the encoding is not enough to
> > decide whether or not there is a match ... you need something like
> > a language attribute.  With labels in XML, that's no problem ... you
> > add the language information as an optional element or attribute.
> > With a header, there is no good way to provide this info.
> >
> > Consensus of con-call: Label header can be removed.
>
> I was talking about this with somebody yesterday. I don't see the argument
> at all. Please give an example where a Label needs a language to resolve
> properly.
>
> As I see it, we compare the (character) encoded string against
> those on the
> server. "le" and "le" are exactly the same whether the language
> is French or
> English.
>
> By suggesting that there is some language component in there, you are then
> stating that the comparison function on the server must account for
> language. That just doesn't seem right. The logical mechanism is
> to convert
> the Label: header value into Unicode and compare that to all the labels
> stored on the server (which are also stored as Unicode).
>
> Unless/until somebody can come up with an example of a string that is
> encoded the same, but interpreted differently based on language,
> *and* argue
> the expectation that the server should treat that string/language pair
> differently... then I might agree to dropping the Label header.
>
> But until then, let's keep the Label header. Tossing it means we must
> replace our PROPFINDs with some silly new report and an extra round trip.
> Where is the benefit!?!
>
> Finally... even if you can show a similarly-encoded string which needs to
> also account for the language, then the Label header can simply look like:
>
>   Label: my-label; language="en-us"
>
> If we want to be anal about it:
>
>   Label: my-label; language="en-us"; charset="iso-8859-1"
>
> But the whole language thing seems like a red herring.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>