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

Simon Josefsson simon at
Mon Jun 18 12:49:37 CEST 2007

Martin Duerst <duerst at> writes:

> At 17:24 07/06/18, Simon Josefsson wrote:
>>Martin Duerst <duerst at> writes:
>>> The issues document should probably mention this, because it's
>>> an issue in the sense that it has to be duely considered and
>>> checked of, but for everybody who has looked even a bit into
>>> this issue will understand that it's a non-issue, in the sense
>>> that applications should just upgrade to the new, correct
>>> version of normalization without any problems.
>>Well, upgrading would violate the current IDNA specification, and libidn
>>will maintain its implementation of the IDNA documents, see:
>>If the new IDNA specification changes anything wrt pr29, that will break
>>backwards compatibility for a set of strings, and I expect there to be
>>discussion about what the strategy to resolve this incompatibility will
>>The strings doesn't occur in natural language, but may occur in
>>non-natural strings such as passwords, and my suggestion has been that
>>all the problematic strings should be rejected.  It only affects a small
>>number of strings.
> Your suggestion is one to consider. My personal opinion would be
> that because for passwords, prohibition is as bad as a change
> (in normalization), and a normalization change is easier to
> implement (change one character, in the case of your source)
> than a special prohibition, so I'd favor just changing things.

The problem is that you'll have to make sure the change has been made to
all components of a system.  Given the amount of deployed code that
follows the current RFC, it will take time until code is updated to
follow some future RFC that may change this.  It is conceivable that
having two components in a system that implement this differently will
lead to security problems.  It seems safer to prohibit these strings to

> On top of that, I'd note that even most passwords have some connections
> with natural language (at least by the fact that they are usually
> typed in on a keyboard), so the chance that a password contains
> such a string is still extremely, extremely low (essentially, we
> are still talking about an empty set).

Right, and that's why I argue that we should simply disallow those
strings, since the practical transition cost for users is zero or
extremely low.  The strings are easy to detect (see the implementation
in libidn), and it costs little to do this.


More information about the Idna-update mailing list