referencing IDNA2008 (and IDNA2003?)

[Peter Saint-Andre]

On 10/22/10 12:38 PM, Adam Barth wrote:
> I'm not sure I quite understood everything that was mentioned during
> this thread. 

Don't worry, it takes a long time to grok i18n, let alone grok it in
fullness. I for one feel like I'm always standing at the foot of the
mountain and not making any progress toward the summit...

> Concretely, here's what cookies need to do:
> 
> 1) We receive a sequence of octets from the network, which we convert
> to lower case.  Let's call this X.
> 2) We have a URL that the user agent has used to generate an HTTP
> request.  Let's call the host name component of this URL Y.
> 3) X is a sequence of octets that's has all the crazy xn-- stuff.

Yep, it's an A-label.

Possible trap: is the domain-value provided by the HTTP server in the
Set-Cookie header really an A-label (if the domain is an IDN)?

> 4) We need to transform Y to the crazy xn-- form to see if it's in
> some relation to X.
> 5) For our sanity, we'd like to use octet-by-octet comparison, without
> reference to any kind of folding (e.g., case-folding, IDNA-folding,
> etc).

One conclusion from this thread is that it will come to you already
folded (lowercase, in simplified terms) because that's the way an
A-label is.

> As an added constraint, we don't feel its our place to mandate to user
> agents whether they ought to use IDNA2003 or IDNA2008.  User agents
> are free to make the decision independently of what the cookie spec
> says.  You should feel free to lobby them one way or another, but
> we're not going to impose that requirement on them in this document.

Right -- the user agent should use whatever IDNA technology it already
has, although we hope that they'll migrate to IDNA2008 (but that hope is
out of scope for the cookie spec = draft-ietf-httpstate-cookie).

> My understanding is that the text in the spec meets our requirements.
> If that's not the case, please let me know.

Here's where our understandings diverge. :)

My reading
<http://www.alvestrand.no/pipermail/idna-update/2010-October/006770.html> of
this thread is that in the cookie spec it would be best to proceed as
follows...

1. Expunge the concept of a "canonicalized host name" and thus Section
5.1.2.

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.

Adam, do you read this thread differently?

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/20101022/5b521708/attachment-0001.bin>