Prefix bug

[Mark Davis]

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.

That is, that section says the following:

   - 3. Values in the field 'Prefix' MAY be added to records of type
   'variant' via the registration process.
   - 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 "en-US" could be
   replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont".
   If one of those prefixes were needed, a new Prefix SHOULD be registered.
   - 5. Values in the field 'Prefix' MUST NOT be removed.

However, if you have no Prefix, that is equivalent to having Prefix: *; that
is, any prefix will work. Thus suppose that a variant FOOBAR is registered
with no Prefix, it can be combined with anything:

en-foobar
de-Cyrl-AU-1901-foobar
zh-foobar
...

Thus #4 ("Values in the field 'Prefix' MAY be modified, so long as the
modifications broaden the set of prefixes.") 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.

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.

   - Variants with no prefixes are like region codes; they can, and
   forever will be able to, be combined with any prefix.
   - Variants with at least one prefix are limited to all and only the
   registered prefixes.

We should make this clearer in the next version, so that people don't trip
up on it.

Mark

P.S. People designing validating parsers should also be aware of this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20060829/5d48b944/attachment.html