referencing IDNA2008 (and IDNA2003?)

[Peter Saint-Andre]

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>