Lookup & NFC

John C Klensin klensin at jck.com
Sat Mar 29 08:50:48 CET 2008

--On Friday, 28 March, 2008 21:57 -0700 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

>> But the bottom line, at least IMO, is that the protocol needs
>> to say "by the time the string gets here, it must be in NFC
>> form, because that is the only way comparisons will work".
>> The
>> ...  It can do that by knowing that something else
>> has already done it, or by checking that the string is in that
>> form, or by forcing the string into that form.
> On windows the IME's often put data into NFC form, but there
> are some exceptions.  Certainly its not difficult to build a
> keyboard that enters NFD data.  Windows doesn't do anything
> magical to enforce any data form, so anyone using IDN on
> windows would have to presume that their data would need to be
> normalized.  Certainly any link would be suspect.  I would
> expect that on other systems NFC might be common, but
> similarly couldn't be guaranteed.

It probably depends on the system.  I also suspect that, in the
very long term, Windows will discover that having that much
flexibility will be a liability.  But that belief does us little
good today, whether it is right or wrong.

> So anything saying "it must be in NFC form" should probably
> also say "if you don't know its in NFC, then you MUST
> normalize it to NFC".  Which is a little bit different than
> saying "it must be in NFC" because that would leave open the
> possibility that data not in NFC was somehow illegal and
> perhaps NFC normalization wasn't permitted.

I think we agree.  This is not a matter of the intent of the
protocol but of how we explain that intent.

It then becomes a matter of the language in the spec, for which
I am clearly open to suggestions.  Once we get this charter
nailed down, I'll try to fix Protocol accordingly.  The language
about mappings there probably needs similar adjustment, and
Rationale almost certainly needs tuning as well.


More information about the Idna-update mailing list