referencing IDNA2008 (and IDNA2003?)

[Adam Barth]

On Thu, Oct 21, 2010 at 1:08 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 10/21/10 1:25 PM, Adam Barth wrote:
>> On Thu, Oct 21, 2010 at 12:02 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> On 10/21/10 11:56 AM, John C Klensin wrote:
>>> I think part of the question here is: what will be source and format of
>>> the inputs to the canonicalization algorithm described in this I-D? And
>>> how will the outputs be used?
>
> Adam, could you perhaps shed some light on that topic? I *think* the
> input here is the name of the HTTP server to which the user agent sent
> its request and from which it receives a response containing a
> Set-Cookie header field.

That's correct.  It's the thing that gets serialized into the HTTP
host header (without the port business).

> The name could be an IPv4 or IPv6 address, a
> mere machine name (e.g., on a local network), a traditional domain name
> (containing only ASCII characters), or an internationalized domain name
> (IDN). For IDNs, the user agent (or the DNS library it uses) might
> support either IDNA2003 or IDNA2008, so the actual input to the c14n
> algorithm might be either an A-label or a U-label. However, the output
> of the algorithm is used only for internal comparison within the user
> agent, not communication to another entity, so as far as I can see
> (which, I admit, might not be very far!) the user agent only needs to
> process the inputs consistently -- it doesn't matter all that much
> whether it uses IDNA2003 (including the Nameprep profile of stringprep)
> to do that or whether it uses IDNA2008 (optionally including UTS-46 or
> RFC 5395 to map characters).

I believe you can detect how this processing works.  Although the
value is never sent to anyone, the value is compared against a value
received over the network.

IMHO, all of this is a tempest in a teapot.  User agents are going to
use whatever IDNA algorithm they're going to use.  They're not going
to use a different one for cookies.  Trying to have the cookie tail
wag the HTTP dog doesn't sound like a promising approach, hence the
text in the draft that acknowledges this reality.

Adam