referencing IDNA2008 (and IDNA2003?)

[Adam Barth]

It doesn't matter if X (described below) is a valid label.  If it's
not an octet-by-octet match for something that we know is well-formed,
we just ignore the whole cookie.

Adam


On Fri, Oct 22, 2010 at 12:21 PM, Vint Cerf <vint at google.com> wrote:
> be aware the IDNA2008 speaks to "labels" so you may receive a sequence
> of labels. I think we have agreed that before processing of the domain
> name, the separators need to have been rendered in ASCII 2E ("period")
> form.
>
> If the label is entirely ASCII in the range A-Z, a-z, 0-9 and "-" and
> does not begin with "xn--" or "XN--" you have what sounds like a
> standard form NR-LDH (non-reserved Letter/Digit/Hyphen) label.
> Comparison of list label with potential matches can be done with case
> insensitive DNS method.
>
> If the prefix is "xn--" (or even "XN--" ??), you may have an A-label
> but this needs to be checked for successful conversion to U-label (and
> back?).
>
> Is the process by which you receive input labels also subject to
> random Unicodes (in 8-bit, 16-bit or 32-bit forms)? If so, the process
> gets more complex because these strings should not be directly
> compared but, in my opinion anyway, converted into A-labels, if
> possible. If that fails, the object isn't a valid label.
>
> It's more complex than I have said, I think, depending on the form and
> context in which candidate labels appear.
>
> vint
>
>
>
>
>
>
> On Fri, Oct 22, 2010 at 2:59 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> 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/
>>
>>
>