Subject: RE: New Last Call: 'Tags for Identifying Languages' to BCP

From: "Peter Constable" <[email-masked]>
Date: Wed, 15 Dec 2004 11:01:25 -0800

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] On Behalf Of Bruce Lilly

> > This is a situation we do not intend to repeat.
> 
> That is precisely what would be repeated, and the problem
> would remain.  "CS" currently means "Serbia and Montenegro",
> and its use in accordance with RFC 3066 has precisely that
> meaning.

And that is a significant problem we wish to remedy as there is some
unknown amount of data or implementations out there that use "CS" but
with a different meaning intended.

> > > > The usability flaw in treating ISO 639 and ISO 3166 as
> > human-readable is
> > > > evident in the confusion between ja and JP (or is it jp and
JA?),
> [...]
> > It is not uncommon for users to confuse "JA" and "JP".
> 
> Which clearly demonstrates why mere codes in the absence
> of definitions associated with the codes is a pointless
> proposition.

I believe you have confirmed my point, that codes are not meant to be
human readable.

As for your concern regarding definition, it has been clearly pointed
out that codes will not be lacking definitions -- the same definitions
they have today from the same sources (with references made to the same
sources) will still be available.

> > Again, not hypothetical at all.
> 
> Last time I checked, "US" didn't mean France, and "CN"
> didn't mean Canada -- I suggest that you might want to
> brush up on the definition of hypothetical...

The case is hypothetical, but the hypothetical case serves to illustrate
a general scenario, and the general scenario is not hypothetical.

> > You didn't use the term "display names", but it is clearly implied
by
> > your reference to bilingual implementations.
> 
> Your inference (which you incorrectly claim as my implication)
> is different from my claim. My claim is that under RFC 3066,
> the definitions...

You have failed to quote what you originally wrote which I claimed made
this implication: you spoke not of definitions but of bilingual
applications.

> > Definitions in multiple languages are not a requisite to
establishing
> > the denotation of a coded element.
> 
> True but irrelevant to the point.

Oh? Simply because you make this assertion?

> We now have definitions of
> specific types of elements (viz. country and language tags) in
> multiple languages, and the objection is to the unnecessary
> removal of that characteristic.

The definitions we have now will remain, they will continue to be
referenced and available. I do not see how you say they are being
removed?

Peter Constable
Microsoft Corporation

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Dec 2004 17:52:54 +0100

Peter Constable wrote:

> The definitions we have now will remain, they will continue
> to be referenced and available.

I've no idea where you found en-NH.  And what's the correct
form, pt-TP or pt-TL ?  And the fallback algorithm makes no
sense for cases like en-US-boont, de-CH-1996, or se-Latn-AX,
when en-boont, de-1996, or se-AX are available.  Bye, Frank