Newsgroups: gmane.ietf.idn                                         -*- mail -*-
Subject: Unicode NFKC bug has consequence for Stringprep stability?
From: Simon Josefsson <jas@extundo.com>
Date: Fri, 23 Apr 2004 01:01:20 +0200
Message-ID: <ilubrljy5vj.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hello.  I want people to look at:

http://www.unicode.org/review/pr-29.html

The proposal wants to modify the NFKC specification to fix a problem
in the earlier version, and I assume the earlier versions include the
3.2 version that Stringprep make a reference to.  The problem do seem
real, despite the claim that "we know of no realistic scenarios that
would present such problems" made on the page.  I have verified that
the NFKC implementation I use, which I believe follow the Unicode 3.2
NFKC specification (until proven otherwise), exhibit the problem.

The page claim one IDN implementation "needs change".  I'm leaning
towards _not_ making this change to my NFKC implementation, as doing
so appear to violate the Stringprep specifications which reference a
specific Unicode NFKC specification.  If we start to apply any random
changes the Unicode Consortium wants to apply to NFKC without updating
the Stringprep specification, we could just give up any hopes of
interoperability and security.

I'm interested in finding out what other developers think, and how
this will be handled by future revisions of the Stringprep documents.

I'm also curious why nobody has forwarded this apparently very
relevant piece of information to this list.  I appreciate pointers to
where this has been discussed in public before.

Thanks,
Simon