Add IDN support to existing net APIs

[Jonathan Lu]

Hi Michael,

I'm wondering how we could move this forward.

For the next step, is it just to draft a JEP for this change as a beginning?
or should I get supports and approvals from some other groups or leaders ?

- Cheers
Jonathan


On Fri, Feb 21, 2014 at 1:32 AM, Michael McMahon <
michael.x.mcmahon at oracle.com> wrote:

>  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> 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/20140325/91add527/attachment-0001.html>