Xuelei, This looks very good. Just a few minor comments:
- SNIServerName hexes could be UPPERCASE, since it is a constant. - Trivially, SNIHostName(String) calls IDN.toASCII(hostname) twice It is not clear to me from this constructor whether it should pass a hostname "as understood by the client", or an encoded hostname. The method description seems to be at odds with the implementation ( at least from me reading ). Maybe this could be a little clearer by saying "as understood by the client". - SNIHostName.hostname seems simply be a String version of the SNIServerName.encoding. Also, there is no way of returning the original hostname as passed in the constructor. - SNIHostName.equals, Is it possible to craft a concrete SNIServerName implementation that would be considered equal to a SNIHostName? It would seem that hostname may not be considered in the equality. - There is scope for null parameter checking in the implementation to use j.u.Objects.requireNonNull(Object,String) - Is it possible to change SNIStandardTypes to use an enum, similar to java.net.SocketOption & java.net.StandardSocketOptions, rather than an int. It would still be extendable, but more "Java like". -Chris. On 03/09/2012 03:05, Xuelei Fan wrote:
Hi, This is the spec review for JEP 114 [1]. webrev: http://cr.openjdk.java.net/~xuelei/7068321/webrev_spec.10/ Network team, per RFC 6066, the host_name in TLS SNI extension need to be encoded in ASCII. In SNIHostName, to get the ASCII-Compatible Encoding (ACE), java.net.IDN is used to convert from general String and UTF-8 encoded byte array to ASCII string. We need expertise in networking, would you please review the spec of SNIHostName? Thanks, Xuelei [1]: http://openjdk.java.net/jeps/114
