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

[Hugh Paterson III <[e-mail]>]

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


On Tue, Mar 28, 2023 at 1:55 PM Doug Ewell <[e-mail]> wrote:

> Hugh Paterson III wrote:
>
> > 1. Any larger BCP-47 effort for revision should likely include
> > incorporating the Unicode Extensions, RFC6067 and RFC6497:
> >
> > https://cldr.unicode.org/index/bcp47-extension
> > http://www.unicode.org/reports/tr35/#36-unicode-bcp-47-u-extension
>
> The T and U extensions are quite properly described in separate RFCs, as
> specified in Section 3.7 of RFC 5646. Folding them into an RFC 5646bis
> would place them on a different definitional level from any future
> extensions that might be created, which would be a Bad Thing™.
>
> I assume the purpose in doing so would be to call better attention to the
> extensions, since RFC 5646 itself predates them and so cannot refer to
> them. The Wikipedia page on BCP 47 already describes the extensions and
> links to the extension RFCs, as does my page; perhaps the maintainers of
> other sites that link to RFC 5646 could be persuaded to link to those
> documents as well (and also to RFC 4647).
>
> > 2. The issue with using Glottolog codes is specifically that ISO 639-3
> > is scoped at the language level, while the informatic model of the
> > Glottolog is specifically scoped to the document level, rather than
> > the language level. That is, Glottolog codes can span the classes of
> > macro-language, idiolect, dialect, or hypothetical reconstructed
> > language.  The two scopes are inconsistent with regard to purpose. If
> > the purpose of the positions of the constructed BCP-47 tags is to stay
> > consistent, I don't see how Glottolog codes become a possibility
> > except after -x- or some other yet-to-be defined identifier.
>
> I agree wholeheartedly, but one does occasionally hear suggestions to do
> this. It’s almost as if 8,000 language subtags, plus variants and the
> ability to register more, plus private-use sequences, weren’t enough.
>
> --
> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
>
>