suppress-script values for fil, mi, pes, prs, qu members

Mark Davis ☕ mark at
Fri Oct 22 18:40:54 CEST 2010

I agree with the direction of the conversation, that we should add the SS
fields that Peter recommended.


For those interested, we have related data in Unicode. See the following (you
may have to "View Source" in some browsers)

In particular, these lines are relevant to Peter's request (and are in line
with it):

<likelySubtag from="fil" to="fil_Latn_PH"/> <!--{ Filipino; ?; ? } => {
Filipino; Latin; Philippines }-->
<likelySubtag from="mi" to="mi_Latn_NZ"/> <!--{ Maori; ?; ? } => { Maori;
Latin; New Zealand }-->
<likelySubtag from="qu" to="qu_Latn_PE"/> <!--{ Quechua; ?; ? } => {
Quechua; Latin; Peru }-->

The goal of this mapping is broader than SS, but related. The 'likelySubtag'
mapping says basically that if you get a request for resource data for "fil"
*(with **no** other information)*, the best practice is to assume
equivalence with "fil-Latn-PH" (Unicode treats "-" and "_" as equivalent),
and vice versa. That extends to the parts (unless they are otherwise
mentioned in the data table), so you end up with the following equivalence
class for resource matching:

{fil, fil-Latn, fil-PH, fil-Latn-PH, und_PH}

The "no other information" clause is important: if there is other
information available (like geolocation), that would be a reason for using a
different mapping.

The requirements are broader than SS. For SS, no data means either means
"there is more than one customary script", *or* "there isn't any data
available". In resource matching, even if there is more than one customary
script, we have to provide the one, the most likely one, such as in:

<likelySubtag from="zh" to="zh_Hans_CN"/> <!--{ Chinese; ?; ? } => {
Chinese; Simplified Han; China }-->
<likelySubtag from="zh_TW" to="zh_Hant_TW"/> <!--{ Chinese; ?; Taiwan } => {
Chinese; Traditional Han; Taiwan }-->

New information can be added via ticket (


*— Il meglio è l’inimico del bene —*

On Fri, Oct 22, 2010 at 07:34, Doug Ewell <doug at> wrote:

> John Cowan <cowan at mercury dot ccil dot org> wrote:
> > Michael Everson scripsit:
> >
> >>> Even if this is so, S-S is also mutable: we can add it to or remove
> >>> it from either the macrolanguage or the encompassed languages at
> >>> will, as new information comes to light.
> >>
> >> Isn't this a stability problem?
> >
> > Yes, but correctness trumps stability here.  We knew we would
> > occasionally make the wrong decision based on incomplete evidence, as
> > with Wolof.
> Not only that, but S-S — like Description — is only informative.
> Stability of informative fields is a much lesser concern than stability
> of normative fields.
> --
> Doug Ewell | Thornton, Colorado, USA |
> RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ietf-languages mailing list