I disagree with your characterization of canonicalization. It does not "eliminate ambiguity". What it does is eliminate otherwise-unimportant differences between two semantically equivalent values.
We allow many unwise tags. For example, "tlh-Cyrl-AQ-fonupa" is well-formed, valid, and canonical. It's also laughable, bringing to mind, as it does, freezing mythical Star Trek aliens typing on cast off Soviet typewriters.
Canonicalization says how to take a tag and make it consistent in terms of capitalization/format and in terms of modern subtag choice. However, as a process, it does not disturb or destroy the original meaning of the tag. We cannot know why the user chose a specific set of subtags---they may have meaning in her particular context.
In the post I was responding to, you suggested we add even more information about tag choice to the registry--in particular, you suggested that we expand Suppress-Script to other subtag types (which, please note, is NOT considered as part of canonicalization today). I can't really support doing this or adding some other mechanism such as a Disallow-Prefix or some-such. It adds to the overall edifice of what implementers must deal with---at a time when most implementations are of the "stick 2*8alpha subtags together with hyphens" variety. The more arcane we require software to implement, the fewer conforming applications we will have.
Given that variants are rare and tend to be very highly specialized, supplying lots of formal requirements for their use and implementation will make them even less appealing.
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of Martin Hosken
> Sent: Thursday, July 10, 2008 12:36 AM
> Cc: ltru at ietf.org
> Subject: Re: [Ltru] Latn and fonipa
>
> Dear Addison,
>
> > We have rule #1: Tag Content Wisely, complete with several pages
> of text saying this already. We could go on adding more registry
> cruft until the crack of doom. At some point, we have to let people
> tag stuff.
>
> The question is how do we turn 'tag wisely' into a set of
> canonicalisation rules. If we want wisdom in how canonical tags are
> made, then we have to codify that wisdom somehow. The point of
> canonicalisation is to take out as much ambiguity as we can. You
> say: -fonipa implies Latn so don't include it in your tag if you
> are being wise. What is the canonicalisation rule for that?
>
> Yours,
> Martin
>
> >
> > Addison
> >
> > Addison Phillips
> > Globalization Architect -- Lab126
> >
> > Internationalization is not a feature.
> > It is an architecture.
> >
> >
> > > -----Original Message-----
> > > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> > > Behalf Of Martin Hosken
> > > Sent: Wednesday, July 09, 2008 10:12 PM
> > > Cc: ltru at ietf.org
> > > Subject: Re: [Ltru] Latn and fonipa
> > >
> > > Dear Addison,
> > >
> > > > > Not really. The 15924 JAC decided that IPA is a subset of
> Latn.
> > > So
> > > > > saying bru-Thai-fonipa is semantically meaningless. fonipa
> only
> > > > > makes sense in conjunction with Latn and therefore can
> imply it.
> > > > >
> > > >
> > > > It doesn't necessarily make sense to REQUIRE a tag such as
> "en-
> > > Latn-fonipa", though. The 'Latn' subtag is superfluous and adds
> no
> > > additional semantic value. In fact, no language tag adds
> semantic
> > > value by including a script in the case of fonipa. For example,
> > > "zh-yue-Latn-HK-fonipa" is also unnecessarily long.
> > > >
> > > > There are other similar examples. 'baku1926' implies Latn too.
> > > 'monoton' implies 'Grek'.
> > >
> > > I agree entirely. But there is nothing in the registry or
> standard
> > > that says this. So I think we need a suppress script for these
> > > variants.
> > >
> > > Yours,
> > > Martin
> > > _______________________________________________
> > > Ltru mailing list
> > > Ltru at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ltru
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.