en-boont-scouse?

[Peter Constable]

> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Addison Phillips [wM]


> In authoring the spec, we didn't solve every possible tag formation
> problem in a normative manner. The tags you give in your email below
are
> preposterous, if "valid", but no more so than 'zh-CO' (well-formed and
> valid under RFC 3066) or 'en-Egyp-CH' (ditto for draft-langtags).
Writing
> a registry file format that would describe the valid ranges and
exclusions
> for registered variants can probably be done, but at the cost of
greater
> complexity (and further, unnecessary, delay)... 

There is a significant difference between Doug's examples and these:
these coincidentally don't refer to anything, but are not preposterous.
It is quite conceivable (however unlikely) that some day there may be a
variety of English used in Switzerland and written in Egyptian
hieroglyphs. A tag like de-1901-1996, however, is self-contradictory and
so truly preposterous.

Something that would be less complicated than providing a detailed
description of the valid ranges and exclusions would be to specify a
limited set of exclusions. For instance, 1901 and 1996, which are
incompatible, were registered at the same time, and it wouldn't have
been a big step at the time to specify "1901 is incompatible with 1996"
(however that might be formalized). BTW, note that an incompatibility
between ISO 639 IDs such as en and ar is reflected formally in that the
syntax simply does not allow you to have a tag such as "ar-en".

While something useful might be doable without too much complexity,
though, I think a much bigger priority is to get this thing finished.
Sure, nothing says that en-boont-scouse isn't valid, but as has been
pointed out the bigger issue that it isn't useful, just as en-Egyp-CH
isn't useful, and that we are expecting users to choose tags wisely.

Since we anticipate that we'll want to do some revision in the future
after ISO 639-3 is published, we might consider revisiting this question
at that time. For now, though, the cost of any further delay would be
much bigger than the small gain.


Peter Constable