referencing IDNA2008 (and IDNA2003?)

[Adam Barth]

I'm not sure I quite understood everything that was mentioned during
this thread.  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.
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).

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.

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

Adam


On Fri, Oct 22, 2010 at 7:48 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Fri, Oct 22, 2010 at 10:29:19AM -0400, Vint Cerf wrote:
>> andrew,
>>
>> we were pretty explicit that the algorithm that produces A-labels
>> produces only lower case. check with John Klensin.
>
> I remember talking about it, and I remember this being an issue
> because Punycode does not actually require lower case.  But I can't
> put my fingers on the text where it says this right now.  I haven't
> looked that hard, however.
>
> The reason I haven't looked hard is that it doesn't matter.  There is
> absolutely no way we can enforce any restriction in the DNS that
> requires the label to remain lower case.  Though DNS is supposed to be
> ASCII-case-preserving but ASCII-case-insensitive, the plain fact is
> that not every implementation does this, or does it correctly.  (I
> recall quite clearly pointing this out during the WG discussions,
> because some implementations use compression pointers to the original
> query string and therefore get whatever was asked by an application.)
> Applications can put their LDH queries in _in any case at all_ and
> have them work.  An IDNA2008-unaware stack with an IDNA2008-aware
> application above might do anything, including converting everything
> in the label to upper case (try logging into an old-fashioned UNIX
> console with the caps lock on.  You'll do a lookup for XN--SOMETHING
> no matter what you intend).  If it does that, and happens to query
> through a caching name server, the upper case form will persist in the
> cache.  You still have to treat that label as matching the lower case
> U-label.  We couldn't do all this above the DNS if you didn't have to.
>
> The case-preserving, case-insensitive feature of DNS was, in my
> opinion, a grave error.  But it's an error we have to live with
> forever if we're going to continue using DNS.  You simply cannot build
> a case-sensitive layer atop the DNS if any of the US-ASCII code points
> in the labels you want to use are themselves to be case sensitive.  If
> you want to do something clever like Punycode, only for the entire
> Unicode range (i.e. including that which overlaps with US-ASCII) so
> that you never have a transparent map between the DNS name and the
> user-presented name, then you have the possibility of introducing case
> sensitivity to the naming system (but not the DNS).  Otherwise, you're
> out of luck.
>
> A
>
>
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
>