Proposal to remove Preferred-Value field for region YU in LTRU
textexin at xencraft.com
Fri Feb 27 21:26:17 CET 2009
I agree with your comments.
Note however, that this guidance doesn't address the question of preferred
values being deprecated and whether that is motivation to change existing
preferred value relationships.
From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Randy Presuhn
Sent: Friday, February 27, 2009 12:13 PM
To: ietf-languages at iana.org
Subject: Re: Proposal to remove Preferred-Value field for region YU in LTRU
> From: "Tex Texin" <textexin at xencraft.com>
> To: "'Randy Presuhn'" <randy_presuhn at mindspring.com>;
<ietf-languages at iana.org>
> Sent: Friday, February 27, 2009 2:04 AM
> Subject: RE: Proposal to remove Preferred-Value field for region YU in
> Can someone explain to me what the stability policy is for codes with
> respect to preferred values?
> Historically, it was a concern that codes might change.
> If I use the registry to choose the preferred value for a region, and that
> preferred value can change, then isn't it tantamount to the code changing?
This was discussed at some length on ltru at ietf.org.
There are differening viewpoints. Some (including me) place a higher
value of stability and predictability. Others place a higher value on
reflecting the latest and greatest. There is merit to both approaches.
The current text in RFC 4646bis prefers stability in cases where ISO
has merely changed the code for a region:
D. For ISO 3166-1 codes, if the newly assigned code's meaning
is associated with the same UN M.49 code as another 'region'
subtag, then the existing region subtag remains as the
preferred value for that region and no new entry is created.
A comment MAY be added to the existing region subtag
indicating the relationship to the new ISO 3166-1 code.
> If I had data that would be represented by YU/CS and after the preferred
> value is removed it should instead be YU, that seems like a problem.
> Especially since the relationship between CS and YU becomes lost.
> Also, it may not be clear which CS records should be restored to YU.
Two things to keep in mind: "deprecated" does not mean "illegal", and
whenever we have a geopolitical split or merger, things will necessarily
get messy. But language tagging doesn't (or at least shouldn't) happen
in a vacuum. Someone (or something) with enough knowledge of the
language to be distinguishing, say, Serbian as spoken in Bosnia from
Serbian as spoken in Montenegro will be in a better position
to choose how to identify the variant, and to determine whether a region
subtag is even the right thing to use for such a variant. I don't think
something we can second-guess here.
Ietf-languages mailing list
Ietf-languages at alvestrand.no
More information about the Ietf-languages