Re: [PEPr] Comment on Networking::Net_IDNA

PEPr wrote:

David Rech (http://pear.php.net/user/dr) has commented on the proposal for Networking::Net_IDNA. Comment: Hello Markus, Looks good so far. You may have noticed the effort of Stefan Neufeind and myself, of implementing IDNA for PEAR. Stefan however made a first version some months ago, after joining the discussion about my plans to contribute IDNA for PEAR.

Unfortunately I was not on the list yet, when I started writing the class, which is the base for our proposal.

Have a look on it at: http://pear.speedpartner.de/ I was a bit dissatisfied with his version, but unfortunately I did'nt find much time on completing my work on a final API for IDNA in PEAR.

Looks quite similar to what we did, excepting some basic differences in internal processing. But after all, your and our approach points to the same direction.

As my time seems quite to be very limited now, and for the next months, I would love to see you working on IDNA for PEAR together with Stefan. There is a need for a PHP4 version anyways.

This (although not PEARed yet) can be found here: http://idnaconv.phlymail.de/ Following some of the comments made on the list lately it might be sensible to have both Net_IDNA (PHP4) and Net_IDNA (PHP5) put inot PEAR.

It would be bad to have two different APIs for IDNA in PHP4 and PHP5. So here's a short summary of what I had to criticize/advise on both Stefan's and your work. 1) The package name IDNA may be Net related, but doesn't it be more related to Internatiolization at all? I18N_IDN may be a good choice here.

I disagree, since IDN(A) is just intended for domain names, not for general internationalisation or localisation purposes. So I think it is really placed best in the Net_ category.

(I explicitly use IDN here, IDNA means "Internationalized Domain Names in Applications", but as every script or product using IDNs is more or less an application, "IDN" would do it here. It's just about "Internationalized Domain Names"... that implies beeing used in "applications" for our purpose) I think "IDN" makes the context clear, so we don't need the "A" anymore. ;)

A question of definition. I am not bound to calling it IDNA :)

2) Punycode Punycode is a single standard. Even if it's only related to IDNA it should (IMHO) go into a single class.

Punycode is just one part of encoding / decoding IDNs. The whole story of StringPrep / NamePrep is part of it. So dividing the whole process of an IDN codec into the basic parts of Punycode conversion, Nameprep and so on doesn't make sense to me.

3) Input encodings I'd like to see support for many more input encodings than just the unicode-compatible ones. Especially "Multibyte string" (mbstring) ind "libiconv" (iconv) extension are interesting here. Also "recode" may need a quick look on.

I disagree. This should be part of the application using Net_IDNA. I also tend to remove the routines of snipping the input string into the domain name parts, protocol and query string again, since this approach seems to be to much overhead in the sense of IDN. IDN is specified for second level domains only, so extracting the second level domain from a complete link in the face of the fact, that there's various Unicode codepoints representing a dot is ugly and prone to fail. But this last comment is also open for discussion :) Besides the things pointed out above I consider the class being quite stable and complete. -- Matthias Sommerfeld phlyLabs mailto:mso@phlylabs.de http://phlylabs.de