Proposal to remove Preferred-Value field for region YU in LTRU
doug at ewellic.org
Fri Feb 27 14:20:49 CET 2009
Tex Texin <textexin at xencraft dot com> wrote:
> 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
This would have been a good question for the LTRU group back when the
decision was made to allow Preferred-Value to change. I'm guessing this
was about a year ago, but I would have to look it up.
> 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
I guess I'm not sure what you mean by "YU/CS" in this context. A
language tag contains at most one region subtag, of course.
> Especially since the relationship between CS and YU becomes lost.
Speaking to this particular case and not to the general principle of
allowing P-V to change...
It has been argued frequently on LTRU that the relationship between CS
and YU is not what it appears, because the country identified as YU
changed its nature dramatically between 1991 and 2003, in a way that was
pertinent to language identification, by shrinking from the original
"Yugoslavia" to just Serbia and Montenegro. This viewpoint holds that
data tagged as "something-YU" is already ambiguous as to "which YU" is
intended. This is really just a special case of the problem that
country codes as language modifiers are less than perfectly precise.
> Also, it may not be clear which CS records should be restored to YU.
There is never any presumption that someone will go through and retag
data. Section 3.1 says, "In particular, the 'Preferred-Value' field
does not imply retagging content that uses the affected subtag." To me
this implies that a change or deletion of P-V doesn't imply retagging
> I don't see that the fact that the target preferred value of YU is
> also deprecated is a good reason to break the relationship at this
> point. We still end up with deprecated codes with no preferred value
> to go to, so why introduce an unnecessary change?
So that users will not have to follow a chain of arbitrary length to
determine the best subtag -- or in this case, to reach a dead end.
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
More information about the Ietf-languages