<div dir="ltr"><br><div class="gmail_extra">Hi Michael,<br><br></div><div class="gmail_extra">Thanks a lot for your comments.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon <span dir="ltr"><<a href="mailto:michael.x.mcmahon@oracle.com" target="_blank">michael.x.mcmahon@oracle.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I think it's a good idea. Before
      changing anything though,<br>
      we would need to:<br>
      <ol>
        <li>identify all APIs that could potentially be affected and
          figure out what is<br>
          needed for each. For instance:<br>
        </li>
        <ol>
          <li>InetAddress</li>
          <li>SocketPermission</li>
          <li>URLPermission</li>
          <li>HttpURLConnection</li>
          <li>URL/URI<br>
          </li>
          <li>...<br></li></ol></ol></div></div></blockquote><div>Right, I assume all  APIs which accept string-represented host names would be affected.<br>It that may not be a big change from point of view.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000"><div><ol><ol><li>
            <br>
          </li>
        </ol>
        <li>understand how it relates to URIs and IRIs. I haven't looked
          into this much<br>
          but it seems that there might be potential for confusion given
          that these entities<br>
          have their own encoding schemes already. I'm sure the issues
          are all well thrashed out<br>
          already, but I'd like to see exactly how it will work in Java
          before we start the work</li></ol></div></div></blockquote><div>For the potential confusion, were you meaning a confusion between URI encoding (RFC-2396 [1]) and IDN ?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><ol>
      </ol>
      Maybe, the work is within the scope of a small JEP, if nothing
      else to define the scope<br>
      of the work.<span><font color="#888888"><br>
      <br>
      Michael.</font></span></div></div></blockquote><div><br></div><div>Copying core-libs-dev and security-dev to get more comments.<br><br></div><div>Many thanks<br><br></div><div>- Jonathan<br><br>[1] <a href="http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div>
<div><br>
      <br>
      On 19/02/14 04:00, Jonathan Lu wrote:<br>
    </div></div></div><div><div>
    <blockquote type="cite">
      <div dir="ltr">Hi net-dev,<br>
        <br>
        If a Java application tries to support International Domain
        Names (IDN) [1], which was firstly brought in Java6,<br>
         it has to write additional code or wrap java.net.IDN API [2] to
        make the conversion each time it tries to resolve<br>
        a non-ASCII domain name, and use the converted punycode to make
        connections to remote host, like:<br>
        <br>
            java.net.IDN.toASCII("<a href="http://xn--wnyy6w.info" target="_blank">电脑.info</a>");<br>
        <br>
        It is easier for newly writen applications, since a wrappers can
        be made in early design stage, but if<br>
        it comes to existing Java applications and third-party
        libraries, IDN support would involve much more effort<br>
        like modifying the existing code base, inspecting libraries
        interfaces/implementations, or even<br>
        re-implement some of the functions.<br>
        <br>
        I'm wondering if it is possible to add IDN support into existing
        Java APIs, like<br>
        java.net.InetAddress.getByName(), if JDK itself supports IDN,
        any existing applications or libraries would<br>
        benefit from supporting IDN automatically without any source
        code modifications.<br>
        <br>
        Of course there's security risks regarding IDN homograph attacks
        [1][2], so it may not be a<br>
        good idea to change the default behavior right now. But it would
        still work if a simple switch can be<br>
        added into current JDK.<br>
        For example, by defining following the property in command like
        options like <br>
        <br>
        -Djava.net.AutoIDN=true<br>
        <br>
        Any existing Java applications who wishes to support IDN feature
        will be able to support IDN<br>
        without any changes to its source code or re-compilation.<br>
        <br>
        What's your opinion on this ? any comment is welcome.<br>
        <br>
        Thank you<br>
        <br>
        - Jonathan Lu<br>
        <br>
        -----------<br>
        <br>
        [1] <a href="http://en.wikipedia.org/wiki/Internationalized_domain_name" target="_blank">http://en.wikipedia.org/wiki/Internationalized_domain_name</a><br>
        [2] <a href="http://download.java.net/jdk8/docs/api/java/net/IDN.html" target="_blank">http://download.java.net/jdk8/docs/api/java/net/IDN.html</a><br>
        [3] <a href="http://www.unicode.org/reports/tr36/" target="_blank">http://www.unicode.org/reports/tr36/</a><br>
        [4] <a href="http://en.wikipedia.org/wiki/IDN_homograph_attack" target="_blank">http://en.wikipedia.org/wiki/IDN_homograph_attack</a><br>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div></div>