Add IDN support to existing net APIs

[Michael McMahon]

On 20/02/14 03:15, Jonathan Lu wrote:
>
> Hi Michael,
>
> Thanks a lot for your comments.
>
> On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon 
> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at 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 ?

Right. As I said, it may just be a matter of checking RFC2396 (or its 
successor RFC 3986).
I think RFC 3986 references IDNs.

Michael

>     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
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140220/63da6522/attachment.html