referencing IDNA2008 (and IDNA2003?)

John C Klensin klensin at
Thu Oct 21 23:45:51 CEST 2010

--On Thursday, October 21, 2010 15:33 -0600 Peter Saint-Andre
<stpeter at> wrote:

> So, we might be able to do the following:
> 2. In Section 5.3, wherever we say this:
>       If the domain-attribute is identical to the canonicalized
>       request-host:
>    Change it to something like this:
>       If the domain-attribute and the request-host are
> identical       according to the domain comparison rules of
> the implementation,       including comparison of
> internationalized domain names (IDNs)       using either
> IDNA2003 or IDNA2008:


>    Similarly change this:
>       Set the cookie's domain to the canonicalized
> request-host.
>    To:
>       Set the cookie's domain to the request-host.
>    (I don't see a strong need to "canonicalize" it before
> storing it.)

Well... The existing text might be taken to say "the only form
in which IDNs are stored in cookies is as A-labels".  That
actually has a lot of advantages including the fact that almost
all of the IDNA2003 <-> IDNA2008 differences, including the
ZWJ/ZWNJ and FinalSigma/ Sharp-S, disappear (if those characters
are encoded in the A-labels, then they are "real" and have not
been mapped out, IDNA2008 will successfully construct the
correct U-labels if forced to do so and IDNA2003 implementations
probably will too (unless they make tests not specified by the

But this is likely one of those situations in which the practice
is whatever the practice is and I'd assume that there are native
character labels stored in cookies today.  If so, prohibiting,
or even discouraging, the practice would require some
explanation (much of which appears above if someone wants to go
that route).

> 3. Remove Section 6.3 entirely (and thus the FUD-like
> paragraph to which John objected).
> Is that going too far?

I don't think so.  I think that this, or any other application
using IDNs, can reasonably adopt one of two positions: 

	(1) The application knows something about IDNA, in which
	case we should stick close to saying "follow the rules".
	That is what the text you and Andrew have been
	suggesting does.  To go much further runs the risk of
	accidentally having contradictory text and as IDNA
	(2) The application insists that all IDNs, including
	especially what is stored in cookies, use A-labels and
	then behaves in a fashion that is as ignorant as
	possible as far as details & versions of IDNA are concerned.


More information about the Idna-update mailing list