Table Derivation

Kenneth Whistler kenw at
Sat Dec 22 03:18:01 CET 2007

jfc said:

> I doubt the IETF has the available 
> expertise to check this document, so any RFC proposition including 
> this propositions will not survive the IETF LC razor (cf. RFC 3935).

I respectfully disagree.

First of all, for nearly all of the users of the IDNA
specification, they will simply be using a predefined
table in the context of the IDNAbis string preparation
step (defined in the other document). They aren't going
to need to be checking the detailed derivation of the
table itself in order to implement correct and conformant
checking of IDNs according to the future RFC.

What Patrik's document is about, and what Mark's and my
contribution is about, is really the instructions for
those who will be checking the derivation of the table
itself, before its publication.

And even if we turn to the checking of the table itself --
the expertise required is no more than parsing a few
values out of simply formattted, publicly available and stable
plain text data files, and then doing a few set addition and set
subtraction operations on the results.

As Mark and I have suggested for the table derivation, it
is not even necessary to have available a conformant
implementation of Unicode normalization or Unicode casefolding
to hand in order to derive the desired result: keeping characters
which are unstable under normalization or casefolding out of the
set used for IDNs. Those values also can simply be parsed
out of simply-formatted plain text files without having
to independently implement Unicode normalization or casefolding
for that step.

And as I just noted in the message re IDN_Always and IDN_Never,
I have posted the results of table derivations for all
versions of Unicode from Version 3.2 through Unicode 5.0
(and the yet-to-be-released Unicode 5.1). So anyone who wants
to independently check their parsing and set subtraction has
an easy way to compare results for any Unicode version. Such files
could, of course, be made permanently available once we
agree on all the details of what we want to be in or out of the
NEVER and ALWAYS classes.

This seems technically quite straightforward to me, and is
certainly well within the expertise of any number of IETF
participants, including those discussing this issue here.



More information about the Idna-update mailing list