(2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Weijun Wang]

>>
>>> 4. I just noticed that the type can be also "sni-<n>". What if someone
>>> call setServerName("sni-0", "...")? Is it the same as calling
>>> setServerName(SNI_HOST_NAME, "...")?
>>>
>> Unspecified behavior. Maybe not, because of the value encoding method.
>> We may throw exception in Oracle provider. Other providers may want to
>> support "sni-32" or "principal" for its private server name type.
>
> I'm not sure. Suppose tomorrow the type nick_name(1) is supported and a
> customer begins using "sni-1". The day after tomorrow, Java is updated
> and we have a string "nick_name" for it. I guess you will make "sni-1"
> and "nick_home" equivalent so that the customer's app will still work?
> If so, why not start doing it today for "sni-0" and "host_name"?

In fact, I don't quite understand how this is used. On the client side, 
when the developer knows nick_name(1) is not yet supported by the 
current JDK, he will use the "sni-1" type so that the SNI will be 
correctly encoded. Then, JDK is updated and the name type is now 
"nick_name", but I believe the old app should still work, so "sni-1" 
should be still accepted and be equivalent to "nick_name".

On the server side, the old JDK and new JDK would return different 
values for getServerNames(). It's likely that the user app will be 
broken if it cannot successfully predict the "nick_name" name and 
already support it.

Therefore, seriously, I suggest we change Map<String,String> to 
Map<Integer,String>. Since we already defined SSLParamters constant for 
the types, the user won't feel uncomfortable.

Thanks
Max