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.mcma...@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.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 ? > > > 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 >> >> >> > >
