draft-klensin-idnabis-protocol-04 section 4.5

Mark Davis mark.davis at icu-project.org
Thu Mar 27 17:03:19 CET 2008

On Thu, Mar 27, 2008 at 8:26 AM, Simon Josefsson <simon at josefsson.org>

> "Erik van der Poel" <erikv at google.com> writes:
> ...

> > So the bottom line is that the current four IDNA200X drafts only
> > specify what is allowed at the lowest level(s). The higher levels,
> > such as HTML, UI and so on, are to be specified in separate specs.
> Doesn't this approach lead to, for example, that the outcome of X.509
> certificate chain validation will depend on the locale in which the
> application is running in?

I think that locale-specific preprocessing would be a disaster for
compatibility. People will expect that what they type in an address bar in
one location will work in another, or can be pasted into email and work for
the recipient, and so on. They will get burned by it not working, or even
worse, that it works but points to somewhere unexpected.

Moreover, for compatibility in environments where IDNA2003 is now used, a
successful deployment of IDNA200x really also requires a standard,
locale-invariant, preprocessing specification -- one that maintains as much
compatibility with IDNA2003 mapping as possible. (Reasons discussed earlier
on this list.) I don't know if that applies in the case of X.509 or not.

A number of people feel that it is important to get the main IDNA200x spec
done (or at least well underway) before such a preprocessing specification
is developed, and that it should thus not be part of the charter. My fear is
that without such a standard specification being available at the same time
or shortly thereafter, every implementation will develop its preprocessing
-- something just a little different from others -- causing a compatibility

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080327/1d241359/attachment-0001.html

More information about the Idna-update mailing list