Proposal to remove Preferred-Value field for region YU in LTRU

[CE Whitehead]

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 
> Registry.
> 

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
> http://www.ewellic.org



 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090221/3df06625/attachment.htm