referencing IDNA2008 (and IDNA2003?)

[Vint Cerf]

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/
>
>