<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<BR><BR>Hi, I feel that the comments field is absolutely needed!<BR> <BR>
> From: doug@ewellic.org<BR>> Date: Sat, 21 Feb 2009 13:04:32 -0700<BR>> <BR><BR>> <BR>> For example, we currently have <BR>> "i-hak" -> "zh-hakka" for Hakka. In RFC 4646bis, we will have the <BR>> 639-3-based subtag "hak", meaning that the Preferred-Value chain will <BR>> become "i-hak" -> "zh-hakka" -> "hak". We plan to change the <BR>> Preferred-Value for "i-hak" to "hak" to eliminate this indirection.<BR>> <BR>> Our question has to do with applying this logic to a particular region <BR>> subtag. Currently "YU" is deprecated with a Preferred-Value of "CS", <BR>> and "CS" is deprecated with no Preferred-Value at all, since there is no <BR>> single successor country. It might make more sense to remove the P-V <BR>> from "YU" altogether, to prevent the user from following a chain which <BR>> ultimately leads to a dead end. However, RFC 4646, Section 3.1 does not <BR>> permit this group to remove a Preferred-Value, although the proposed <BR>> 4646bis will allow this.<BR><BR>
(This chain does provide a bit of history! )<BR>
<BR>> As part of the production of a replacement Registry in draft-4645bis, it <BR>> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU <BR>> change -- and optionally replace it with a Comments field such as <BR>> "Comments: see BA, HR, ME, MK, RS, or SI". This might be considered <BR>> analogous to the existing Comments field for "CS". It might also be <BR>> preferred by those who feel that "CS" was not a suitable P-V for "YU" in <BR>> the first place.<BR>> <BR>
However, it makes sense to shorten the chain for users.<BR>
I feel that the Comments field is absolutely needed.<BR>
(Can we always add comments when a subtag is deprecated & there is no preferred value? <BR>
[but I do wonder what way the comments field influences how applications process language info, if it does?])<BR>> It has been objected that this type of change needs to be made by <BR>> ietf-languages and the Reviewer, once 4646bis is approved and published <BR>> and allows it, and should not be made by LTRU in the replacement <BR>> Registry.<BR>> <BR>
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.<BR>--C. E. Whitehead<BR>
<A href="mailto:cewcathar@hotmail.com">cewcathar@hotmail.com</A><BR>
> . . .<BR>> <BR>> --<BR>> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14<BR>> <A href="http://www.ewellic.org">http://www.ewellic.org</A><BR><BR>
<BR> <BR></body>
</html>