Anomaly in upcoming registry
randy_presuhn at mindspring.com
Mon Jul 13 02:12:36 CEST 2009
> From: "Doug Ewell" <doug at ewellic.org>
> To: <ietf-languages at iana.org>
> Sent: Sunday, July 12, 2009 11:46 AM
> Subject: Re: Anomaly in upcoming registry
> Peter Constable <petercon at microsoft dot com> wrote:
> > On the other hand, I'm not completely in agreement with your premise
> > that this is solely ISO 639's call and that we have no say. We could
> > choose to collapse these even if ISO 639 doesn't if we think that is
> > the right thing to do for consumers of the LST registry. If ISO 639
> > chose to collapse these, we could choose to leave them as is if we
> > think that is the right thing to do for consumers of the LST registry.
> I actually don't see anything in RFC 4646 or draft-4646bis that says we
> can do this. Can you point to some text? I may be overlooking
I think a proper rationale for handling such a *hypothetical* case
in this way (since it would be clearly wrong in the particular case
that is the subject of this thread) is addressed by the the qualifying
language already present in the approved I-D: "if the newly assigned
code's meaning is not represented by a subtag in the IANA registry".
It's clear that true duplicates are bugs, and that one should simply
refer to the other as a preferred value.
There's no way that I'd be willing to start another round of ltru
revsions to make the handling of such a hypothetical any clearer.
At some point folks need to realize that the BCP is not an algorithm
for execution by finite state automata. It gives guidelines to
humans who, one would hope, are capable of exercising a bit of
More information about the Ietf-languages