United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4737170 RFE: International Domain Names
4737170 : RFE: International Domain Names

Details
Type:
Enhancement
Submit Date:
2002-08-27
Status:
Resolved
Updated Date:
2005-11-21
Project Name:
JDK
Resolved Date:
2005-06-08
Component:
core-libs
OS:
generic
Sub-Component:
java.net
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6

Related Reports
Relates:

Sub Tasks

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
                                     
2005-06-01
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-18



Hardware and Software, Engineered to Work Together