Another round of IDNAv2, and thoughts on IDNA2008 goals

Simon Josefsson simon at
Wed Mar 4 22:48:55 CET 2009

Paul Hoffman <phoffman at> writes:

> I do not pretend that IDNAv2 is wonderful. It has all of the cut
> corners and compromises that we made in IDNAv1. I would not be
> surprised if the WG decided that fixing those in IDNA2008 is the
> better way to go, even if it means introducing new problems, but I
> would also not be surprised if the WG said "let's just go with IDNAv2
> now" and be willing to do IDNAv3 in a few years. If the WG goes with
> IDNAv2, I certainly don't think we should wait six years for IDNAv3;
> it should be much sooner than that.

I think IDNAv2 is a good idea, to resolve several important problems in
IDNAv1 in a guaranteed backwards compatible way, but I wouldn't want to
delay IDNA2008 significantly.  However, I don't think that is required.
IDNAv2 can be reviewed and deployed relatively quickly.

One question: do you think there are input strings that are not allowed
by IDNAv1 but will be allowed by your IDNAv2 that will be encoded
differently in IDNAv2 compared to IDNA2008?  I am aware that ezset may
be one example, but I'm looking for other examples.

If there are many examples of these strings, rather than the few
exceptions like ezset, I think we are better of discussing whether to
completely abandon either IDNAv2 or IDNA2008, since making
IDNAv1+IDNAv2+IDNA2008 work together will be a complex task.


More information about the Idna-update mailing list