Subject: [Ltru] Re: Abolishing registered language subtags

From: "Doug Ewell" <[email-masked]>
Date: Tue, 25 Sep 2007 22:43:21 -0700

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

>> A 5-letter language subtag that is the same as a 5-letter variant 
>> subtag is not an error and is not a problem
>
> Well, I've just shown that it in fact *IS* a problem for some 
> implementors if they look at subtags in isolation:
>
> For most cases it works:
> - 3DIGIT is always an UN M.49 region (if registered)
> - 4DIGIT is always a variant if registered
> - 4ALPHA is always a script in 4646 and 4646bis,
>  4ALPHA as a language isn't used in 4646(bis).
> - 5*8alphanum is _in practice_ always a variant.
> - 3ALPHA is always a language in 4646, starting
>  with 4646bis it can be also an extlang.

It's not *supposed* to be enough to look at subtags in isolation. 
Section 2.1 says, "Usually, each type of subtag is distinguished by 
length, position in the tag, and content: subtags can be recognized 
solely by these features."  ("Content" refers to the presence of letters 
vs. digits.)

"Position" is an important factor here; there is no guarantee, nor 
should there be, that no two-letter language subtag will match any 
two-letter region subtag (modulo case).  And in fact, by my count there 
are 115 such matches:

'ae' = Avestan, 'AE' = United Arab Emirates
'af' = Afrikaans, 'AF' = Afgahinstan
'am' = Amharic, 'AM' = Armenia
etc.

Exactly the same situation applies to registered language subtags and 
variant subtags.  While it would be a huge mistake *semantically*, there 
is no *syntactic* reason why ietf-languages could not register a 
language subtag such as 'boont' or 'fonipa'.

Our primary purpose in creating and populating and maintaining the 
Registry is not to make it easy to convert the thing to XML using 
scripting languages.

>   There are only two exceptions in the 4646 registry,
>   yi-latn and zh-hakka, and both will be fixed in the
>   4645bis registry.

As luck would have it.

> b) For a script working with "real" (cases insensitive)
>   tags it's also simple, your af vs. AF and similar
>   cases are the only difficulty.  The script can note
>   the position of the subtag, 2*8ALPHA languages are
>   always at the begin of prefix tags.  Other subtags
>   including 2ALPHA can be noted as e.g. -AF, and then
>   "AF" != "-AF".

That'll work.  That's how I did it in my validator.  It's a shortcut 
that works.

But in earlier versions of my validator, I also took shortcuts that 
assumed that every variant would have a prefix, and that variants would 
have only simple prefixes consisting of one subtag.  There was never any 
guarantee that this would be the case forever, and when 'fonipa' and 
'biske' came along, I had to replace the shortcuts with longer, more 
conformant algorithms.

> But as soon as 4*8ALPHA language subtags are used, and
> simultaneously a 3ALPHA Macrolanguage can be either a
> language or an extlang, these simple solutions won't
> work anymore.

Then you'll have to resort to less-simple solutions.

>> There's no consensus yet that we will have a
>> macrolanguage field.
>
> It's in the last 4645bis proto-registry, from my POV
> it's fine.

We also have extlangs in the 4645bis proto-registry, and there's clearly 
no consensus that those will survive.  (We'll see what happens on the 
phone Wednesday.)

>> In any case, this is a question of conflict within
>> one implementation written against a draft, not a
>> question of ambiguity or confusion within the draft.
>
> No, it's a design issue exhibited by "running code":
>
> If you can decide what the type an isolated subtag is,
> either by noting its position (b) or by noting it in
> its case-sensitive "pretty" form (a), then that's an
> important feature of the design.

It's not either/or.  You need length, position, and content.

> Syntacticaly we'd be better off if we use i-abcdefgh
> instead of abcdefgh for "registerd language subtags".

Perhaps.  It might also have been cleaner given that we already have 
grandfathered i-tags.  We can certainly spare the singleton, since it 
will almost certainly never be needed for an extension.

> But let's
> please discuss the prohibition of "generic variants"
> like fon?pa in another thread.

What is there to discuss?  We discussed it at excruciating length some 
time ago, and then ietf-languages registered 'fonipa' and 'fonupa', and 
that precedent pretty much settles it.  We really need to stop 
revisiting decisions that have been resolved unless we can prove that 
something is seriously broken.

--
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru