Re: libidn2 extension for php
| From: | Gustavo Lopes | Date: | Fri, 18 Nov 2011 15:56:06 +0000 |
| Subject: | Re: libidn2 extension for php | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-8889@lists.php.net to get a copy of this message | ||
Em Fri, 18 Nov 2011 13:12:01 -0000, Pierre Joye <pierre.php@gmail.com> escreveu:
The current implementation uses IDNA2003 and you can't update to 2008 without breaking backwards compatibility. UTS #46 provides a transitional mechanism that eases the differences between IDNA2003 and IDNA2008, but still differences remain, see http://www.unicode.org/reports/tr46/#Table_IDNA_Comparisons So I think the only valid (=non BC breaking) option with something resembling the current API is to add an extra parameter to specify the version (IDNA2003, UTS #46 and IDNA2008) and have it default to IDNA2003. -- Gustavo LopesPossibly the best course of action would be to follow the ICU API and create a new class in the intl extension with labelToASCII (uidna_labelToASCII_UTF8), labelToUnicode (uidna_labelToUnicodeUTF8), nameToASCII (uidna_nameToASCII_UTF8) and nameToUnicode (uidna_nameToUnicodeUTF8).If it is actually correct to use the new API, then I would rather do it now and by updating the current implementation in INTL. There is no need to add new functions or classes for that, we should support 2008 per default using the current IDN functions. Another possible bug is the RTL support.However, I don't know receptive people are to add such a change to PHP 5.4 at this point. Another option would be to do it in trunk exclusively and sync PECL intl with it.It is more a bug fix, which can be related to security as well (spoofing attacks). If it is actually correct to use the new API and fully 2003-2008 compliant, then I will use the new API directly.