Newsgroups: gmane.ietf.idn -*- mail -*- Subject: Unicode NFKC bug has consequence for Stringprep stability? From: Simon Josefsson Date: Fri, 23 Apr 2004 01:01:20 +0200 Message-ID: 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