Nameprep and NFKC

[J-F C. Morfin]

At 14:58 16/10/2010, Vint Cerf wrote:
>I think one has to view this from the perspective of trying to bring
>coherence and stability to an inherently ambiguous situation. Keep in
>mind that the essence of the DNS is matching of a registered string
>with an input string. Normalization removes some degree of ambiguity,
>making the matching process less computationally expensive. If I have
>understood your example correctly, the variation goes away if you
>first apply NFC to the various possible cases. IDNA2008 relies on the
>transformation of any candidate label into its NFC equivalent before
>conversion through punycoding for look up or registration. Failing to
>convert the two different strings through NFC before further
>processing is an error.

At 16:03 16/10/2010, John C Klensin wrote:
>Vint's answer is the correct one -- it is deliberate behavior of
>IDNA2008 and incorrect input into the demo.  I tried to say that
>in an earlier note.   I do think that it would be useful to
>alter the demo so that it makes a test for the input strings
>being in NFC form (as required in Sections 4.1 and 5.2 of RFC
>5891) and generates a clear error message if the test fails
>rather than continuing to process the string.  I think that is
>more a matter of taste rather than a "flaw" in the demo, but
>your experience suggests to me that the demo would be more
>useful if these strings were rejected with an explanation.

At 06:53 17/10/2010, Abdulrahman I. ALGhadir wrote:
>Well I got it now I guess the behavior of the demo was a bit confusing
>as you mentioned already so it supposed to rise an error or at least
>show a notice of wrong input rather than showing the punycode without a
>single notice.

At 14:59 18/10/2010, Andrew Sullivan wrote:
>(This is
>another reason why the RFC can read as it does: the _protocol_
>requires certain things, but it doesn't constrain how things outside
>the protocol layer behave.)

At 15:27 18/10/2010, John C Klensin wrote:
>Exactly.   I was referring to the behavior of the demo/test
>program only.

I am extremly glad to see that the IDNA2008 consensus does hold. And 
I hopefully look forewards for a quick IAB RFC also considering 
French Majuscules and further work on IDNs before committing 
ML-DNS/Inter Plus to community testing. Once this is done it might be 
difficult to come back to the pre-FAST TRACK/ICANN gTLD situation.
jfc