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

[Xuelei Fan]

On Aug 15, 2012, at 11:05 PM, Weijun Wang <weijun.wang at oracle.com> wrote:

>>> 
>>>> 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.
> 
We have to consider two things, the type and the encoding method of the value.  For oracle provider, we will not support unknown type in SSLParameters because we don't know the encoding method. We support unknown type in session but we require the value is encoded in utf-8.

I  do not prefer integer for the type because from the integer type I cannot tell whether the type is unknown or not, and then cannot make sure what is the proper encoding according. For example, the old application does not know "nick-name", so the type integer is 1 and the value encoded as UTF-8, but what if the encoding is not UTF-8 in the formal spec?  We will not be able to decode the value properly.

Xuelei

> Thanks
> Max
>