Re: [Ietf-languages] BCP47 violation in the recent extlang ajp change

[Doug Ewell <[e-mail]>]

There is a basic difference. -x- is a “reserved entity” defined by BCP 47. It is part of the definition of BCP 47 language tags; it is accounted for in the ABNF.

-t- and -u- are not reserved in BCP 47, but rather are registered in the Language Tag Extensions Registry:

https://www.iana.org/assignments/language-tag-extensions-registry

which is much less well-known than the Language Subtag Registry, but is equally a part of BCP 47. This would be like saying that the language subtag ‘en’ is a reserved entity in BCP 47.

A parser does not need to link to any RFC documents, but a fully compliant parser that supports extensions should link to both registries — the well-known LSR and the lesser-known LTER — as well as the data files used by the respective extensions, which in the case of -t- and -u- happen to be CLDR data files. Of course, someone building such a parser would need to refer to the separate RFCs in order to know this.

The existence of the LTER is what prevents the Open Language Advocacy Community from registering a singleton that collides with -t- and -u-. The RFC process for such an extension would hopefully attract review from someone who understands how BCP 47 works, and who would object to the collision. Perhaps this is the “database of singletons” you are referring to. It has existed since 2005, although for the first five years it was a stub, with no registered extensions until -u- came along.

--
Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org


From: Hugh Paterson III <[e-mail]> 
Sent: Tuesday, March 28, 2023 15:26
To: Doug Ewell <[e-mail]>
Cc: Martin J. Dürst <[e-mail]>; Christian Despres <[e-mail]>; [e-mail]
Subject: Re: [Ietf-languages] BCP47 violation in the recent extlang ajp change

If -t and -u are not to be included in BCP-47 (as reserved entities), because they ought to be independently manageable (which I assume is the purpose for a separate RFC), then should the -x extension be kicked out to its own RFC? Why should it be included in RFC5646? Wouldn't the same reasons for inclusion or exclusion exist for all singletons? (§2.2/3.7).

Without linking and registration of the various RFC documents defining singletons, doesn't it mean that the only singleton which a parser can depend on by implementing BCP-47 is -x-, as that is the only one acknowledged? Potentially then different communities could define their own singletons and create clashing singletons. For example, I could create an organization called the Open Language Advocacy Community, and define a set of singletons, some of which may clash with RFC6067 and RFC6497. Presumably nothing is stopping some of these other singletons from becoming registered as RFCs. This situation may create confusion for parsers who expect -t and -u to be related to RFC6067 and RFC6497. 

Maybe the more pertinent architectural approach is to have a database of singletons where registration is required like the IANA database. In my first read of §2.2 and §3.7, I read it as there was only a single universe of singletons possible. Am I more appropriately to understand the current architecture to be that there is infact a multiverse of infinite options with regards to the semantics of any singleton other than -x-? With the caveat that in each world of the multiverse that -x- will in fact have the same semantics.  

Kind Regards,
Hugh