Scripts in the current list of codepoints

Kenneth Whistler kenw at sybase.com
Fri Dec 15 20:22:23 CET 2006


Cary indicated:

> Quoting Michael Everson:
> 
> > Runic actually has more likelihood of being needed.
> 
> I am fully prepared to argue that there is such a need, at least in my
> neck of the woods (and suspect that Tina, Harald, and Patrik would agree).
> 
> Since this is not a matter of adding a few codepoints to the inevitable
> exception list, the discussion would certainly be eased simply by
> reverting to the list of scripts as Ken initially stated it.

Done.

See:

http://www.unicode.org/~whistler/SPInclusionList061215.txt

This restores the Runic code points, where they can be further
reviewed as needed.

Following Michael's suggestion about Osmanya, which I agree with,
I also removed the Osmanya code points.

Also, in private discussion with Michael, we agreed that the
historic Ogham script of Ireland is inappropriate for internet identifiers,
so I have also pulled the code points for that script from
the proposed inclusion list table.

That means that the above list now reflects a script restriction
rule:

5. If script(cp) in {Xsux, Ugar, Xpeo, Goth, Ital, Cprt, Linb, Phnx, Khar,
Phag, Glag, Shaw, Dsrt, Osma, Ogam}, remove cp

Note that removing Osmanya from the inclusion list has the
result that the proposed inclusion list now contains *zero*
code points from Plane 1. This is a good result, in my opinion,
and will help in general understanding of how the table is
constructed. It will also be welcomed by table implementers,
since the resulting table will be more compact.

It also raises the interesting question as to whether we should
simply propose that *all* of the Plane 2 Han characters (a huge
number, by the way) be dropped from the inclusion list. The
contents of Extension B on Plane 2 is almost entirely very low
usage historic characters. And the compatibility characters on
Plane 2 are all canonical singletons and would be filtered by
the NFKC rule, anyway. Going this route would make the focus
on the BMP even clearer, and would make table implementers
even happier. :-)

--Ken



More information about the Idna-update mailing list