Spec review of JEP 114: TLS Server Name Indication (SNI) Extension

[Chris Hegarty]

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