Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:
Last but not least it would eliminate the "hakka" reference in a Preferred-Value, where "hakka" is the only "non-subtag" in any reference.
You are presuming a rule where none exists. A grandfathered tag may have another grandfathered tag as its Preferred-Value. There is no restriction against this , no reason it should not be possible, and the fact there is only one such situation -- because two people independently happened to register tags for Hakka under RFC 1766 -- does not change any of that.
there is no "collision" between 5- to 8-letter language subtags (if any existed) and 5- to 8-letter variant subtags, any more than there is a collision between "ar" for Arabic and "AR" for Argentina.Of course there is for naive implementations, the theory of the 4646 structure is that you can decompose a tag into subtags, and still tell what's what based alone on its length.
The theory is "length plus position" where position is relative to other subtags.
3 digits => UN number 3 alpha => language (for 4646) 4 alpha at begin => language (reserved) 4 alpha later => script 4 alnum starting with a digit => variant 2 alpha at begin => language 2 alpha later => region 5..8 alpha at begin => language 5..8 alnum later => variant
You have created a slightly simplified, almost 100% accurate version of the real rules, described in RFC 4646 Section 2.2 ff. It is not 100% accurate, though.
In my old 4646 validator I've implemented this by adding a dummy hyphen for anything that's not "at begin", and after that it was as you said obvious that "AR" (case insensitive) is not "-AR".For 4646bis that isn't good enough anymore, because language and extlang share the same namespace, as soon as there is a language "ang" there can't be an extlang "-ang".
You don't need to do this. If you are truly "validating," as opposed to checking well-formedness, you have to be using the Registry -- so you can simply look there to see whether a language "ang" exists and whether an extlang "ang" exists.
In my validator I used the real rules, and everything works just as well for 4646bis as for 4646.
-- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.