Subject: [Ltru] Prefix bug

From: "Mark Davis" <[email-masked]>
Date: Tue, 29 Aug 2006 18:16:00 -0700

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 30 Aug 2006 03:56:58 +0200

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

A solution is s/SHOULD/MUST/ in the variant registration rule.

If later something "generic" is desperately needed folks can
still create a "g-" extension registry. 

Frank

---

From: John Cowan <[email-masked]>
Date: Tue, 29 Aug 2006 22:06:55 -0400

Mark Davis scripsit:

> 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.

Construe, construe!

#4 does not say that the modification must broaden the set of *valid*
prefixes, simply the set of prefixes (i.e. the set of prefixes mentioned
in the record).

What *is* discrepant is that nothing in 3066bis prevents a tagger
from using a tag like "en-1901", even though that tag is not valid.
2.2.5 should be modified to prevent this.

-- 
John Cowan                                [email-masked]
At times of peril or dubitation,          http://www.ccil.org/~cowan
Perform swift circular ambulation,
With loud and high-pitched ululation.

---

From: Addison Phillips <[email-masked]>
Date: Tue, 29 Aug 2006 21:03:04 -0700

Prefixes for variants are NOT required (there is a strong SHOULD and 
multiple suggestions that a variant without a prefix is a Bad Idea). As 
Mark notes, once registered without a prefix, registering *any* prefix 
will break any and all (non-prefix-bearing) tags. However, the stability 
prohibition on narrowing the meaning would seem to be in force.

> 2.2.5 should be modified to prevent this.

Validators should not have been required to check variant prefixes, 
given what the working group's intentions were originally. However, I 
very much like firming the registration requirements for variants (from 
SHOULD to MUST on having at least one Prefix) and leaving the validation 
rules in place.

Notice that this would effectively forbid generic variants (the reason 
for the SHOULD in the first place).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.