Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » ICU and the INTL_IDNA_VARIANT_2003 deprecation »

ICU and the INTL_IDNA_VARIANT_2003 deprecation

php.internals

Andrey Andreev

8 years ago
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.

Sara Golemon

8 years ago
On Fri, Jan 19, 2018 at 1:11 PM, Andrey Andreev <narf@devilix.net> wrote:
> 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?)

Andrey Andreev

8 years ago
On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon <pollita@php.net> wrote:
> (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.

Niklas Keller

8 years ago
2018-01-19 20:09 GMT+01:00 Andrey Andreev <narf@devilix.net>:
> On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon <pollita@php.net> wrote: > > (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.
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

Andrey Andreev

8 years ago
Hi again, On Fri, Jan 19, 2018 at 9:30 PM, Niklas Keller <me@kelunik.com> wrote:
> > 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.

Christoph Becker

8 years ago
On 19.01.2018 at 19:11, Andrey Andreev wrote:
> 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