Requirements document (Re: New version, draft-faltstrom-idnabis-tables-02.txt, available)

[Simon Josefsson]

Harald Alvestrand <harald at alvestrand.no> writes:

> Simon Josefsson wrote:
>> I suggest that every change to the IDNA protocols is clearly discussed
>> and motivated in a requirements document that is developed in parallel
>> with the IDNAbis document.
>
> Simon, have you read, identified your issues with, and commented on,
> draft-klensin-idnabis-issues-01?

Yes, I posted my review in:

http://www.alvestrand.no/pipermail/idna-update/2006-November/000015.html

As far as I can tell, the -01 version still contains the flawed
description of how IDNA works today, it doesn't mention the PR-29
problem when changing from Unicode 3.2 to Unicode 5.0, and still uses
the problematic term 'Punycode string' to refer to A-label's (even
though a nice section acknowledging that the term is problematic have
been added!).

However, my concern is not about the idnabis-issues document per se.

My concern is that all of the other documents should contain explicit
references to sections in idnabis-issues (or some other document) that
preferably give example strings which behave unexpected under the
current IDNA rules, and needs to be fixed, or at least specific
discussion about why the particular algorithm needs to be changed.

Put simpler: don't make any changes unless you have documented a string
or set of strings that behaves unexpectedly or incorrectly under the
current rules.  Add a reference to discussion about that set of strings
whenever an algorithm is changed to address that particular situation.

Changing a part of the algorithms involved without justification makes
it impossible to review the document set, and judge the importance of
each change.  Even more so if documentation for why things changed is
not explicit and/or public.

/Simon