Nameprep and NFKC

John C Klensin klensin at
Sun Oct 17 15:53:52 CEST 2010

--On Sunday, October 17, 2010 07:53 +0300 "Abdulrahman I.
ALGhadir" <aghadir at> 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.

Part of what is creating the confusion is that we tend to write
IETF standards, especially in the applications area, in a way
that a lot of the standards world would consider odd.  We rarely
say "if condition XYZ is not met, then you MUST return an error
message".  What we say is "to conform to the standard, these
conditions MUST be met".  There are lots of reasons for that,
but an important one is that we simply don't want to start
overspecifying error conditions -- in general (considering more
protocols than IDNA) there are too many possibilities and too
many odd cases.  That difference leaves behavior if the
constraints are not met up to the implementation.  

In this particular case, I can't imagine any reasonable behavior
other than to reject the string, presumably with an error
condition, but maybe my imagination isn't good enough this
morning.  For similar reasons, I'd think a clear rejection or
warning from a demonstration would be the only appropriate
design, but others may have different opinions.


More information about the Idna-update mailing list