Issue1153

We currently lack idna, historically due to the fact that we lacked 
unicodedata and stringprep module also
We now have most of a unicodedata implementation but this doesn't help 
idna/stringprep due to it specifically relying on unicode 3.2
idna isn't used for many things but critical for correctly converting 
unicode/nonascii hostnames to ascii. I see 2 uses of it in the stdlib, 
in httplib and the socket module
We can likely leverage Java 6's java.net.IDN for this

I'm in the process of rewriting unicodedata so that it's in Java, using
constant initializers. Part of this means we will have support for the
3.2 database.
When this is all done, we shouldn't need to rely on Java 6 for either
idna or for unicodedata.normalize.

This is still an issue in the latest 2.5.2 RC, and it's a show stopper for httplib2 (and httplib I believe), along with other libraries. IF this issue persists it'll force Jython users (like me) into using Java's Http-Commons library, which just doesn't compare.
Any chance of squeezing this in for the soon to be released 2.5.2?

It will not make 2.5.2, but we could release it as a separate package on PyPI. It would require Java 6 for java.net.IDN. (The unicodedata rewrite I mention in msg3695 is dead, although we may try again for 2.6+.)

I have checked in partial support for Internationalized Domain Names at revision 7198.
This new support only works on Java 6, which includes native IDNA functionality.
However, there is also a workaround for Java 5.
I have documented the new support and the workarounds on the socket module wiki.
http://wiki.python.org/jython/NewSocketModule#InternationalizedDomainNamesupport 

This issue is specific to IDNs in the socket module, which has been addressed as much as possible.
1. It works fine on Java 6
2. There is a documented workaround for Java 5.
Resolving this issue as fixed.

I wouldn't consider this fixed until u'foo'.encode('idna') works (which doesn't last time I checked)

> I wouldn't consider this fixed until u'foo'.encode('idna') works 
> (which doesn't last time I checked)
+1
We're getting bit by this in http://aspen.io/. We can work around it with a Jython shim, though obviously the fewer of those we need, the better.

Fixed in 7137:a9283b590960
Will not be fixed in 2.5