JDK-4737170 : RFE: International Domain Names
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-08-27
  • Updated: 2017-05-16
  • Resolved: 2005-06-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b40Fixed
Related Reports
Relates :  
Description

Name: nl37777			Date: 08/26/2002

An IETF working group is defining a standard for
international domain names based on the full Unicode character set
(current domain names are limited to ASCII). Information on this
standard is available at http://ietf.org/html.charters/idn-charter.html
and http://www.i-d-n.net/.

The java.net classes that operate on domain names should be updated to
support international domain names when the standard becomes available.
======================================================================

###@###.### 2004-09-17

Now that the standards related to IDNs are available from IETF, we should support it in Mustang. Here is a list of the relevent RFCs:

RFC 3490 Internationalizing Doamin Names in Applications (IDNA)
RFC 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
RFC 3492 Punycode: A bootstring encoding of Unicode for Internationalized Domain          Names in Applications (IDNA)
RFC 3454 Preparation of Internationalized Strings ("stringprep")

Comments
EVALUATION There are various dependencies and implications for this RFE - these include changes to URI/URL to cope with IDNs encoded in URIs, OS dependencies as the default name service provider using the platform resolver, and changes to the DNS name service provider based on JNDI-DNS. ###@###.### 2002-09-02 The ccc request has been submitted. ###@###.### 2005-04-19 09:07:44 GMT The initial solution was to support IDN transparently, i.e. add Unicode <-> ACE conversion into InetAddress.getByName and InetAddress.getAllByName and don't let end user know the existence of such facility. It's regarded too risky, e.g. IDN suffers attacks like monograph attack. This is why we choose current solution for IDN. As Alan said in his comment, URI class also need to be changed to cope with IDN encode. This will be done in RFE 5085902. ###@###.### 2005-06-01 03:23:01 GMT
01-06-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
18-09-2004