Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.128.177 as permitted sender)
MIME-Version: 1.0
Date: Fri, 19 Jan 2018 20:11:56 +0200
Message-ID: <CAPhkiZxgErpa_DmKgTMkcg+DmKV0L-MFDrBDmx9GYwRV3a9Sjg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: ICU and the INTL_IDNA_VARIANT_2003 deprecation
From: 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.