# ICU and the INTL_IDNA_VARIANT_2003 deprecation - Thread: https://externals.io/message/101626 - Original archive: https://news-web.php.net/php.internals/101626 - Started by Andrey Andreev on 2018-01-19T18:11:56+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101626 — Andrey Andreev — 2018-01-19T18:11:56+00:00 URL: https://externals.io/message/101626#101626 Hello, It seems that an important detail was missed in the RFC to deprecate INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only other option available - INTL_IDNA_VARIANT_UTS46 - may not be available at all, as PHP has ICU 4.0 as its minimum requirement, but support for UTS#46 was introduced by ICU 4.6 ... As a result, there may be systems where having a clean call to `idn_to_ascii()`, idn_to_utf() is impossible. I'm all for following deprecations by upstream, but I didn't find any mention of this scenario in the discussions. I'm assuming nobody has considered it and we're in a bit of a mess right now, so ... My immediate thought is to simply bump the ICU version requirement, but I have no idea what kind of an impact that would have. [1] RFC: https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003 [2] ICU 4.6 release: http://site.icu-project.org/download/46 Cheers, Andrey. --- ## #101627 — Sara Golemon — 2018-01-19T18:55:21+00:00 URL: https://externals.io/message/101626#101627 · In reply to: #101626 > My immediate thought is to simply bump the ICU version requirement, > but I have no idea what kind of an impact that would have. > According to that page, 46 is seven years old. I for one am 100% okay with making that the minimum, though not necessarily because of the IDNA issue. If someone on a system running 46 needs to use the idn functions with php 7.2, then they are motivated to bug their admin. (Seriously though, who's on php 7.2, but hasn't updated ICU for that long?) --- ## #101628 — Andrey Andreev — 2018-01-19T19:09:42+00:00 URL: https://externals.io/message/101626#101628 · In reply to: #101627 > (Seriously though, who's on php 7.2, but hasn't updated ICU for that > long?) Probably nobody yet. The issue was uncovered in code that assumed the constant was available on 5.4+, as noted in the manual, but it turned out there's people on 5.6, 7.0 who don't have it. --- ## #101629 — Niklas Keller — 2018-01-19T19:30:51+00:00 URL: https://externals.io/message/101626#101629 · In reply to: #101628 2018-01-19 20:09 GMT+01:00 Andrey Andreev : > > > […] > > Probably nobody yet. The issue was uncovered in code that assumed the > constant was available on 5.4+, as noted in the manual, but it turned > out there's people on 5.6, 7.0 who don't have it. Also PHP 7.1: https://github.com/zendframework/zend-validator/issues/193 We also had an issue report, but I can't find it currently, forgot to link it from the commit: https://github.com/amphp/uri/commit/2de94666447319d8695f2d11f3f005d5fee0876a I think we only have to bump the minimum version once 7.4 is out, because only 7.4 will change the default. You only get a deprecation notice now, which is totally fine. Regards, Niklas --- ## #101631 — Andrey Andreev — 2018-01-19T22:03:14+00:00 URL: https://externals.io/message/101626#101631 · In reply to: #101629 Hi again, > > I think we only have to bump the minimum version once 7.4 is out, because > only 7.4 will change the default. You only get a deprecation notice now, > which is totally fine. > I disagree that it's totally fine. I mean, it's technically fine (it still works), but in principle it's not ok to have no option of writing code that doesn't trigger warnings and notices. Certainly not for the possible entirety of 7.2 and 7.3 life-cycles. And yes, on one hand it's the server admins' fault, but all that does is delegating to framework/library authors the responsibility to explain the problem to clueless users. It's easy to explain that they can't use feature X because they don't have Intl (which you can point to on php.net), they should at least know what a PHP extension is. Not so easy to explain they'll always get an `E_DEPRECATED` notice because somebody set them up with a bad version of some acronym they've never even had to know of. Cheers, Andrey. --- ## #101639 — Christoph M. Becker — 2018-01-20T14:03:02+00:00 URL: https://externals.io/message/101626#101639 · In reply to: #101626 > It seems that an important detail was missed in the RFC to deprecate > INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only > other option available - INTL_IDNA_VARIANT_UTS46 - may not be > available at all, as PHP has ICU 4.0 as its minimum requirement, but > support for UTS#46 was introduced by ICU 4.6 ... > As a result, there may be systems where having a clean call to > `idn_to_ascii()`, idn_to_utf() is impossible. > > I'm all for following deprecations by upstream, but I didn't find any > mention of this scenario in the discussions. I'm assuming nobody has > considered it and we're in a bit of a mess right now, so ... Indeed, I had not considered this issue during the RFC process. Thanks for bringing it up. > My immediate thought is to simply bump the ICU version requirement, > but I have no idea what kind of an impact that would have. * ICU 4.0 has been released on 2008-07-02 * ICU 4.6 has been released on 2010-12-02 * ext/intl requires at least ICU 4.0 as of PHP 5.5.0 (released 2013-06-20) Considering these release dates, it appears to be okay to require at least ICU 4.6 as of PHP 7.2.2. -- Christoph M. Becker