Proposal to remove Preferred-Value field for region YU in LTRU
cewcathar at hotmail.com
Sat Feb 21 22:58:18 CET 2009
Hi, I feel that the comments field is absolutely needed!
> From: doug at ewellic.org
> Date: Sat, 21 Feb 2009 13:04:32 -0700
> For example, we currently have
> "i-hak" -> "zh-hakka" for Hakka. In RFC 4646bis, we will have the
> 639-3-based subtag "hak", meaning that the Preferred-Value chain will
> become "i-hak" -> "zh-hakka" -> "hak". We plan to change the
> Preferred-Value for "i-hak" to "hak" to eliminate this indirection.
> Our question has to do with applying this logic to a particular region
> subtag. Currently "YU" is deprecated with a Preferred-Value of "CS",
> and "CS" is deprecated with no Preferred-Value at all, since there is no
> single successor country. It might make more sense to remove the P-V
> from "YU" altogether, to prevent the user from following a chain which
> ultimately leads to a dead end. However, RFC 4646, Section 3.1 does not
> permit this group to remove a Preferred-Value, although the proposed
> 4646bis will allow this.
(This chain does provide a bit of history! )
> As part of the production of a replacement Registry in draft-4645bis, it
> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU
> change -- and optionally replace it with a Comments field such as
> "Comments: see BA, HR, ME, MK, RS, or SI". This might be considered
> analogous to the existing Comments field for "CS". It might also be
> preferred by those who feel that "CS" was not a suitable P-V for "YU" in
> the first place.
However, it makes sense to shorten the chain for users.
I feel that the Comments field is absolutely needed.
(Can we always add comments when a subtag is deprecated & there is no preferred value?
[but I do wonder what way the comments field influences how applications process language info, if it does?])
> It has been objected that this type of change needs to be made by
> ietf-languages and the Reviewer, once 4646bis is approved and published
> and allows it, and should not be made by LTRU in the replacement
I am unsure as to whether we should wait for RFC 4646 or not (need to research protocol), but note that doing so involves having Doug modify 4645 still another time.
--C. E. Whitehead
cewcathar at hotmail.com
> . . .
> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-languages