Subject: [Ltru] Re: RFC 4646 production "grandfathered" considered harmful

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Sep 2006 23:18:38 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> Unfortunately deprecating the complete zoo won't fly, i-default is too 
> important.  And the opposite proposal "no individually registered 
> language subtags, register i-anything for temporary workarounds" was 
> rejected.  Are you still sure that that's as it should be ?

The grammar really has nothing to do with what's deprecated and what's 
not.  Deprecated tags and subtags are still valid, and still have to 
appear in the ABNF somehow.  Our idea of "deprecated" isn't nearly as 
strong as in some other standards, such as ISO 3166 ("stop using ASAP").

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14

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

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Sep 2006 23:30:11 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> That limits potential "coincidences" to the Preferred-Value of 
> redundant or grandfathered.  Because the grandfathered zoo is frozen 
> you'll find that i-hak with Preferred-Value zh-hakka is the only case.
>
> It's highly unlikely (and no mere coincidence) that i-default, 
> i-enochian, or i-mingo get a Preferred-Value pointing into the 
> grandfathered tags.  I daresay impossible.  Also for all other "not 
> yet" (state 4645bis-00pre) deprecated grandfathered tags.
>
> And I also don't see any remaining redundant tags getting a new 
> Preferred-Value pointing into the grandfathered tags.  Based on that 
> the hakka-"coincidence" turns out to be a singularity.

I really don't understand what the big deal is concerning "zh-hakka". 
The only reason it is different in any way from "zh-guoyu", or for that 
matter "zh-xiang", is that there was a prior registration under RFC 1766 
for the same language ("i-hak").

    January 1999: "i-hak" is registered.

    December 1999: "zh-hakka" is registered.

    January 2000: "i-hak" is deprecated in favor of "zh-hakka".

    January 2001: RFC 3066 is published, replacing RFC 1766.

Under RFC 1766 and 3066 there was nothing unusual about the idea of one 
registered tag being deprecated in favor of another registered tag. 
Nobody has proposed that *more* tags should be deprecated in favor of 
grandfathered tags -- that could not happen in the RFC 4646 era by 
definition.

The situation with Hakka, plain and simple, is that "i-hak" was 
deprecated in favor of "zh-hakka" almost seven years ago, and now both 
tags are grandfathered into 4646, and "zh-hakka" is about to be 
deprecated in favor of an ISO 639-3-based language/extlang combination. 
It would be preposterous to register a variant "hakka" just to satisfy a 
4646 grammar rule that never existed.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Sep 2006 21:18:34 +0900

At 15:30 06/09/19, Doug Ewell wrote:

>The situation with Hakka, plain and simple, is that "i-hak" was deprecated in favor of "zh-hakka" almost seven years ago, and now both tags are grandfathered into 4646, and "zh-hakka" is about to be deprecated in favor of an ISO 639-3-based language/extlang combination. It would be preposterous to register a variant "hakka" just to satisfy a 4646 grammar rule that never existed.

Somewhat unrelated:

My understanding is that currently 'preferred' value pointers are
as follows:

i-hak -> zh-hakka
zh-hakka -> zh-hak

I think the following would be preferable:

i-hak -> zh-hak
zh-hakka -> zh-hak

This would avoid the need for repetition when calculating the
preferred value.

Regards,     Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 19 Sep 2006 06:33:49 -0700

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> My understanding is that currently 'preferred' value pointers are as 
> follows:
>
> i-hak -> zh-hakka
> zh-hakka -> zh-hak
>

Preferred-Values aren't allowed to change once they are assigned.  There 
was a stability reason for this.  I think Mark can probably address 
that.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Sep 2006 15:32:40 +0200

> zh-hakka -> zh-hak

Yes.   It would also eliminate the only pointer containing a
"non-variant".  We discussed this in the last round, I don't
recall the arguments against it.  Maybe the more convoluted
4646 pointers were inspired by UnicodeData.txt (?)

> This would avoid the need for repetition when calculating
> the preferred value.

It also simplifies pointer checks, there's never a danger of
A -> B -> C -> A, if A *_must_* point to something that has
no further pointer.

Frank

---

From: Addison Phillips <[email-masked]>
Date: Tue, 19 Sep 2006 07:59:36 -0700

> 4646 pointers were inspired by UnicodeData.txt (?)

I don't understand. Why is it important that a pointer contain a variant?

> A -> B -> C -> A, if A *_must_* point to something that has

But we don't want to enshrine that in the rules, do we? I don't think it 
is necessary to require that pointers have only a depth of 1 in the 
registry.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.