Subject: Re: [Ltru] preferred value of zh-hakka in Draft-4645bis

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Feb 2008 07:51:18 -0800

>> 3. Others:
>>
>> Preferred-Value: zh-hakka

I'm not sure what is being proposed here.  If the proposal is to change 
the Preferred-Value of "i-hak" from "zh-hakka" to "hak" (thus avoiding 
the chain of Preferred-Values), then we cannot do this. Section 3.1 of 
RFC 4646 and Section 3.1.6 of draft-4646bis both say, "The field 
'Preferred-Value' MUST NOT be modified once created in the registry."

I'm not opposed in principle to this change and the similar one 
apparently proposed for "zh-guoyu", but we have to follow our own rules, 
and we need to determine why we made that particular rule before 
revoking it to suit these cases.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Feb 2008 07:54:27 -0800

>> 4. It would be nice if we could get to the point where we have 
>> replacements for all the grandfathered items (except perhaps 
>> i-default -- although even for that 'und' could probably serve). As 
>> far as I can tell from a visual scan of the file, those are just the 
>> following (does that match what you think, Doug?).
>>
>> %%
>> Type: grandfathered
>> Tag: cel-gaulish
>> Description: Gaulish
>> Added: 2001-05-25
>> %%
>>
>> %%
>> Type: grandfathered
>> Tag: en-GB-oed
>> Description: English, Oxford English Dictionary spelling
>> Added: 2003-07-09
>> %%
>>
>> %%
>> Type: grandfathered
>> Tag: i-enochian
>> Description: Enochian
>> Added: 2002-07-03
>> %%
>>
>> %%
>> Type: grandfathered
>> Tag: i-mingo
>> Description: Mingo
>> Added: 1997-09-19
>> %%

I don't see what action it would be possible for us to take on these. 
Registering language subtags is the job of ietf-languages.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Feb 2008 07:51:25 -0800

> ...
>> Preferred-Value: zh-cmn

the Preferred-Value of "zh-guoyu" from "zh-cmn" to "cmn" (thus avoiding

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 Feb 2008 07:57:55 -0800

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> Type: grandfathered
>> Tag: zh-min
>> Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese
>> Added: 1999-12-18
>> Deprecated: 2029-09-09
>> %%
>>
>> This should have the Preferred-Value: min
> ...
>
> As I read the thread the rough consensus is to *not* make
> the proposed change.

Not only that, there is a paragraph in Section 2.5 of draft-4645bis that 
specifically describes this case and why it is the way it is.  Please 
close this.

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Feb 2008 08:50:47 -0800

I understand that. The question I'm raising is whether there are any 639-3
codes that correspond to these, so that we can remove them. If there aren't
any, that's fine. But if there is some way to express, say, gaulish, it'd be
good to get it out of the way like the others we've been able to handle.

Mark

-- 
Mark

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Feb 2008 08:52:10 -0800

My mistake on these. However, I think they will be confusing.

What I suggest doing is adding a comment for the Preferred-Values that are
themselves recursively eliminated.

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Feb 2008 11:55:00 -0500

Mark Davis scripsit:
> any, that's fine. 

There aren't any.  For particulars, see my earlier post.

-- 
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           [email-masked]
        --Quentin Crisp                         http://www.ccil.org/~cowan
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Feb 2008 11:55:22 -0500

> themselves recursively eliminated.

+1

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       [email-masked]
you'd get cooks very confused.          --RMS
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Feb 2008 09:00:28 -0800

Ok, thanks.

On Feb 13, 2008 8:55 AM, John Cowan <[email-masked]> wrote:

>        --Quentin Crisp                         http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>
>

---

From: Shawn Steele <[email-masked]>
Date: Wed, 13 Feb 2008 10:41:28 -0800

> 'Preferred-Value' MUST NOT be modified once created in the registry."

IMO saying the "preferred-value" MUST NOT change, would also mean that its end result MUST NOT change.  Ie: The chain can't change.

If you're willing to change the chain, then changing the actual value has no practical difference, since the end result (cmn) is the same.

- Shawn

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 13 Feb 2008 20:11:45 +0100

> 'Preferred-Value' MUST NOT be modified once created in the registry."

It seem illogical to me to allow a "preferred-value" to be a
deprecated value. Especially if the newly deprecated value
has a preferred value.

So if a preferred value becomes deprecated, all Preferred-value
references to it should be changed to the new preferred value of
the ex-target, if any. If there is no new (non-deprecated)
preferred value, maybe the reference could be kept.

(If you want me to draft changes, I can do so, but I will
wait a little while for others to comment on this.)

	/kent k

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Feb 2008 12:30:33 -0800

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, February 13, 2008 7:57 AM
> Subject: Re: [Ltru] preferred value zh-min
>
...

Uh, what more than a co-chair making a determination of rough consensus
do you want?  It sounds like I really will have to drag out the RT
bug tracker.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Feb 2008 12:36:37 -0800

Hi -

As co-chair, based on the discussion on this thread, I'm declaring
a rough consensus to *not* make this proposed change.

Randy