Hi Michael, Thanks a lot for your comments.
On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > I think it's a good idea. Before changing anything though, > we would need to: > > 1. identify all APIs that could potentially be affected and figure out > what is > needed for each. For instance: > 1. InetAddress > 2. SocketPermission > 3. URLPermission > 4. HttpURLConnection > 5. URL/URI > 6. ... > > Right, I assume all APIs which accept string-represented host names would be affected. It that may not be a big change from point of view. > > 1. > 1. understand how it relates to URIs and IRIs. I haven't looked > into this much > but it seems that there might be potential for confusion given that > these entities > have their own encoding schemes already. I'm sure the issues are all > well thrashed out > already, but I'd like to see exactly how it will work in Java before > we start the work > > For the potential confusion, were you meaning a confusion between URI encoding (RFC-2396 [1]) and IDN ? > > > Maybe, the work is within the scope of a small JEP, if nothing else to > define the scope > of the work. > > Michael. > Copying core-libs-dev and security-dev to get more comments. Many thanks - Jonathan [1] http://www.ietf.org/rfc/rfc2396.txt > > > On 19/02/14 04:00, Jonathan Lu wrote: > > Hi net-dev, > > If a Java application tries to support International Domain Names (IDN) > [1], which was firstly brought in Java6, > it has to write additional code or wrap java.net.IDN API [2] to make the > conversion each time it tries to resolve > a non-ASCII domain name, and use the converted punycode to make > connections to remote host, like: > > java.net.IDN.toASCII("电脑.info <http://xn--wnyy6w.info>"); > > It is easier for newly writen applications, since a wrappers can be made > in early design stage, but if > it comes to existing Java applications and third-party libraries, IDN > support would involve much more effort > like modifying the existing code base, inspecting libraries > interfaces/implementations, or even > re-implement some of the functions. > > I'm wondering if it is possible to add IDN support into existing Java > APIs, like > java.net.InetAddress.getByName(), if JDK itself supports IDN, any existing > applications or libraries would > benefit from supporting IDN automatically without any source code > modifications. > > Of course there's security risks regarding IDN homograph attacks [1][2], > so it may not be a > good idea to change the default behavior right now. But it would still > work if a simple switch can be > added into current JDK. > For example, by defining following the property in command like options > like > > -Djava.net.AutoIDN=true > > Any existing Java applications who wishes to support IDN feature will be > able to support IDN > without any changes to its source code or re-compilation. > > What's your opinion on this ? any comment is welcome. > > Thank you > > - Jonathan Lu > > ----------- > > [1] http://en.wikipedia.org/wiki/Internationalized_domain_name > [2] http://download.java.net/jdk8/docs/api/java/net/IDN.html > [3] http://www.unicode.org/reports/tr36/ > [4] http://en.wikipedia.org/wiki/IDN_homograph_attack > > >
