I just realized that many people may not realize an implication of 3.4. Stability of IANA Registry Entries regarding Prefixes. This has implications for both the LTRU group and the ietf-languages group, so am sending to both.
<br><br>That is, that section says the following:<br><ul><li>3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process.
</li><li>4. Values in the field 'Prefix' MAY be modified, so long as the
modifications broaden the set of prefixes. That is, a prefix MAY be
replaced by one of its own prefixes. For example, the prefix &quot;en-US&quot;
could be replaced by &quot;en&quot;, but not by the prefixes &quot;en-Latn&quot;, &quot;fr&quot;, or
&quot;en-US-boont&quot;. If one of those prefixes were needed, a new Prefix
SHOULD be registered.
</li><li>5. Values in the field 'Prefix' MUST NOT be removed.
</li></ul>However, if you have no Prefix, that is equivalent to having Prefix: *; that is, <span style="font-style: italic;">any </span>prefix will work. Thus suppose that a variant FOOBAR is registered with no Prefix, it can be combined with anything:
<br><br>en-foobar<br>de-Cyrl-AU-1901-foobar<br>zh-foobar<br>...<br><br>Thus #4 (&quot;Values in the field 'Prefix' MAY be modified, so long as the
modifications broaden the set of prefixes.&quot;) implies that once a variant is registered *without* a prefix, it can *never* have a Prefix added, since that would limit the set of valid prefixes that it can be used with. Thus for the FOOBAR case above, once encoded we cannot later add a Prefix.
<br><br>Luckily this situation does not currently arise: all the current variants have Prefixes. For the future, the registration group should be aware of this implication.<br><ul><li>Variants with no prefixes are like region codes; they can, and forever will be able to, be combined with any prefix.
</li><li>Variants with at least one prefix are limited to all and only the registered prefixes.</li></ul>We should make this clearer in the next version, so that people don't trip up on it.<br><br>Mark<br><br>P.S. People designing validating parsers should also be aware of this. 
<br>