Re: Please make up your mind about IDN-implementation!

Dear Stefan,

Supporting various encodings was a strong wish from people on pear-dev when we did a first pre-propose-discussion on the list. And if you cleanly support character-conversions (I consider the ISO-to-UCS4-conversion a bit of "hack" *g*) you need to use one of the existing extensions for that job. And this makes it necessary to support libiconv, in case e.g. mbstring is not present on that host.

BTW: I will look into the topic of including direct support for UCS4 in string and array representation today. It shouldn't be that complicated. And it makes sense, definitely, especially when having a look over to: http://pear.php.net/pepr/pepr-proposal-show.php?id=131

Using libraries, if present, was also highly appreciated - regarding speed. So if libidn is present, it was expressed that our class should use it (which I can understand). So if you need bulk-conversion of domainnames, installing the extension you can speed up the whole process, but still have a common API. It's like with e.g. a DB-wrapper - if you use it, it doesn't matter which underlying system you use. And if some things are not supported (here: if there is no libidn), the functionality will be handled in PHP.

Net_IDNA is not a wrapper, it's an implementation. Although it might be "sexy" to have a transparent mapping of internal methods to the extension ones. But as stated once in the list a few days ago - the premise for that is, that both the PHP implementation and the extension (you are aware, that there's more than one?) offer - the same API - the same results whereas the latter should be assumed. I think, this topic is more of a general issue - include all possible, sensible functionality into the class turning it into a monster class (ACME - a class making everything), or put adapter classes around it for transparent handling of either Net_IDNA or ext/libidn. I assume, that people, who have any of the extensions installed, won't use Net_IDNA. I call for input from others here on the list about that.

That's not true. Some *ideas* were originally borrowed from the C source of JPNICs libidn. I ended up writing all the stuff by myself. Including the tables...

Ideas? Hmm, have a also had a look at the RFCs as well? Then maybe the copyright-statement at top of the source is a bit misleading - I thought you transfered the C-source to PHP (more or less strictly).

No, not at all. I crawled through the relevant RFCs (3490, 3491, 3492, 3454). It cost me a few days of understanding the principle and as well a few days more to manually transfer the mapping tables, since everything I had as source was unusable for the purpose. The copyright statement is obsolete, that's true.

and it's not designed following the RFCs. So I doubt that we can guarantee to really provide "support" for that implementation.

That's clearly said not true. The only difference you notice is, that I created replacement tables fitting the purpose: Replace by nothing just means: skip that char.

But the tables are quite long, split into several parts (imho unnecessary) and could be replaced by tables directly taken from the RFCs, which might make them a bit more fail-prove and allow cross-checking, imho.

Okay, they are long - but that's not my fault, see RFC3454 :). I decided to split the tables for the ease of processing them.

Will do. If that's the case, sorry about that. Searched in various functions as well as searched for "split" etc.

See line 2325, function _process(). I admit a weakness there. The RFC3454 defines a few more characters to be counted as dots. Regards, Matthias P.S.: Regarding the PHP4 implementation, please have a look here: http://idnaconv.phlymail.de