Putting it another way

[Mark Davis]

I had indeed worked out a syntax, presented and discussed weeks ago.
Currently the generative syntax in RFC 3066
(http://www.ietf.org/rfc/rfc3066.txt):

A. iso_639_code ("-" iso_3166_code)?

Because the script codes are 4 letters, and the others are either 2 or
three, there are two possible easy extensions of this, both consistent
with the 9 registrations:

B. iso_639_code ("-" iso_15942_code)? ("-" iso_3166_code)?
or
C. iso_639_code ("-" iso_3166_code)? ("-" iso_15942_code)?

Either one of these is a reasonable extension of the format that takes
important differences in written language into account. I myself favor
(B), since it is in big-endian format, but that does not have to be
decided now. This could be generalized to

B'. primary_code ("-" iso_15942_code)? ("-" iso_3166_code)?
or
C'. primary_code ("-" iso_3166_code)? ("-" iso_15942_code)?

where primary_code is either an iso_639 code, or a registered code on
<http://www.iana.org/assignments/language-tags>. Thus if it were
necessary to have a tag to match Hakka documents, in simplified
script, using the Singapore style, then following (B'), it would be
zh-hakka-hans-cn. Following (C'), it would be zh-hakka-cn-hans. (Of
course, it would be even nicer if ISO 639 stepped up to the plate and
added a three-letter code for Hakka, but I am not holding my breath.)

The most important feature is that neither (B) nor (C) have to be
decided on before these 9 registrations go through.

Mark
__________________________________
http://www.macchiato.com
►  “Eppur si muove” ◄

----- Original Message ----- 
From: "Michael Everson" <everson at evertype.com>
To: <ietf-languages at iana.org>
Sent: Tuesday, May 27, 2003 17:47
Subject: Putting it another way


> Mark, if, as is obvious from the forcefulness with which you are
> pressing the issue, the registration of these specific codes is so
> important to you, it would be worth your while to put your effort
> into working out a syntax that is acceptable and workable to
evaluate
> other applications for language tag registration. Otherwise I, as
> language tag reviewer, will be put in the position of opening a
> Pandora's box of registrations that will render RFC 3066 irrelevant
> to any meaningful resolution of language/script identification,
> something which will not do you, me or others who are interested in
a
> durable resolution to this problem, any favours.
> -- 
> Michael Everson * * Everson Typography *  * http://www.evertype.com
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>