New version, draft-faltstrom-idnabis-tables-02.txt, available

Kenneth Whistler kenw at
Wed Jun 13 22:29:45 CEST 2007

Patrik Fältström wrote:

> I have got privately many many comments on all algorithmic  
> specifications posted (including mine, and yours Mark). I have also  
> got many suggested algorithmic specifications privately. I think I  
> have around 10 different ways of describing what we want to do --  
> calculate the value of the derived property value.

Well, I think this is one of the key issues with the document.

This *should* be a data specification, not an algorithmic specification.

It defines a table with data values in it.

For clarity, it should do so by specifying a series of criteria
for inclusion or exclusion in that table, and values specified
in that table. And then it should describe the data specification
in terms of set logic.

Mark's contribution shows how much cleaner, clearer, and *correct*
such a specification is.

Trying to turn this into an algorithmic specification is -- in
my opinion, of course -- just wrong.

It is true, of course, that generation of the table for the
document is done computationally, using the criteria and the
set logic -- and not as a manual accounting task, looking at
each character in turn and then hand editing a table with the
appropriate value based on those criteria. And implementing
a computational process *does* involve an algorithm.


The details of the algorithm to generate the table 
itself are *completely* uninteresting. There is no 
reason whatsoever why the data
specification for the table needs to be specifying algorithms
for the generation of the table, because nobody outside this
room, so to speak, needs to *re*implement such an algorithm
in code somewhere. The data is simply there in a table, for
use by *other* algorithms that we *do* need to specify --
namely the ones that determine whether a given Unicode
string is or is not a valid U-label and does or does not
match a particular DNS entry.

And lest you object that indeed someone will need to reimplement
the algorithm to regenerate the table when new characters
are added to Unicode, I will admit (see above) that they
will need to implement *some* algorithm to get a computer to
regenerate the table, but I don't *care* about the details.
What I care is that given the property-based criteria, and
the set logical definition of the table, they get the *right*
table. And chances are that I will implement my *own* algorithm
to verify that the table was extended correctly.

> I choose one that I feel I have most "votes" for. But I know I also  
> have people that dislike it.

I'm sorry, but I consider that not to be an effective way to
develop a technical specification for data.

> Mark, if I ask you differently: Do you see anything WRONG in my  way  
> of describing the calculation?

He did, and I concur with his assessment. Furthermore, as I
have just pointed out, describing the *calculation* (as an
algorithm) is uninteresting in the first place.

What I would prefer is a clear, set-logical data specification for
this table.

> As a different question than whether  
> you feel it is hard to follow or "not the most optimal way of  
> describing what we want to do".


>From RFC 2026:

"The goals of the Internet Standards Process are:
o  technical excellence;
o  prior implementation and testing;
o  clear, concise, and easily understood documentation;
o  openness and fairness;  and
o  timeliness."

It seems to me that this entire process to update IDNA is
in danger of failing on all 5 of those criteria.


More information about the Idna-update mailing list