Re: U-labels and draft-obispo-epp-idn-00
Patrik Fältström <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On 15 feb 2012, at 06:13, Andrew Sullivan wrote: > On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik Fältström wrote: >> >> In this case, what the client should send is _not_ a U-label. You know better than anyone else what an A-label and U-label is, and you give examples below on unicode strings that are passed around that are not U-labels. Remember that there is by definition a 1:1 mapping between A-labels and U-labels. > > The examples I gave are not U-labels, no. But they're Unicode forms > of IDNA2003-compliant systems that happen to generate Punycode forms > that are perfectly good A-labels. If I got a candidate U-label that > didn't match the A-label, I could detect this. If I just get the > A-label, I can't. Bingo! Sending U-labels in addition to A-labels does not make any sense. >>> In the case where the U-label contained "ß", the chances are at the >> >>> very least non-zero, at least today and for the near future: last I >>> checked (about 30 seconds ago) libidn2 isn't in the Debian stable >>> distribution, just for instance. Similarly with ZWNJ and ZWJ. >> >> So, the reason why we want to do this is to ensure there is no bug in the libraries used by various parties? > > There's no _bug_ in libidn when it maps ß to ss. That's what it's > supposed to do. Moreover, if the input string was (say) üß, then the > result would in fact be a Punycode-form IDNA2003 string that happened > also to be an IDNA2008 A-label. It just wouldn't be the right one, > because in IDNA2003 üß becomes üss before the Punycode > transformation. The point of requiring the U-label is to be able to > catch this sort of corner case. But then you do no longer talk about sending U-labels and A-labels! You send unicode strings and A-labels! Patrik _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg