New Last Call: 'Tags for Identifying Languages' to BCP
petercon at microsoft.com
Wed Dec 15 20:01:25 CET 2004
> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] 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
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
> > 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
I believe you have confirmed my point, that codes are not meant to be
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
> > 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
> > Definitions in multiple languages are not a requisite to
> > 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
More information about the Ietf-languages