ICU and the INTL_IDNA_VARIANT_2003 deprecation

  101626
January 19, 2018 18:11 narf@devilix.net (Andrey Andreev)
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
January 19, 2018 18:55 pollita@php.net (Sara Golemon)
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?)
  101628
January 19, 2018 19:09 narf@devilix.net (Andrey Andreev)
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.
  101629
January 19, 2018 19:30 me@kelunik.com (Niklas Keller)
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
  101631
January 19, 2018 22:03 narf@devilix.net (Andrey Andreev)
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.
  101639
January 20, 2018 14:03 cmbecker69@gmx.de ("Christoph M. Becker")
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