referencing IDNA2008 (and IDNA2003?)
Peter Saint-Andre
stpeter at stpeter.im
Thu Oct 21 23:33:18 CEST 2010
On 10/21/10 3:28 PM, John C Klensin wrote:
>
>
> --On Thursday, October 21, 2010 17:08 -0400 Andrew Sullivan
> <ajs at shinkuro.com> wrote:
>
>> Why not just say that you should use whatever IDNA rules the
>> application implements, following all the rules for domain
>> comparison in that implementation? (Note that IDNA2003 domain
>> name comparison turned out to be slightly troublesome, because
>> people sometimes compared what we came to call U-labels and
>> other times compared what we came to call A-labels. But like
>> someone else said up-thread, the implementation is already
>> relying on whatever it is relying on.)
>
> Wfm.
>
> And, fwiw, IDNA2003 is absolutely clear that the only valid
> comparisons are among what we now call A-labels. So an IDNA2003
> implementation trying to compare U-labels directly is simply
> non-conforming or, to use the more precise term, broken.
So, we might be able to do the following:
1. Expunge the concept of a "canonicalized host name" and thus Section
5.1.2 of https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/
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.)
Etc.
3. Remove Section 6.3 entirely (and thus the FUD-like paragraph to which
John objected).
Is that going too far?
Peter
--
Peter Saint-Andre
https://stpeter.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101021/b6af3d61/attachment.bin>
More information about the Idna-update
mailing list